Echo JS 0.11.0

Only mentioned at the end, but definitely favor the work on Intl and related bits over libraries where available.

I think actually running tests would be more appropriate than simply making declarations.  SQLite's locking mechanism will synchronize a lot of activity anyway.

What you probably should do, if there's lots of other things going on, if you're using SQLite with Node.js, is segment your database requests into a separate worker.  This is going to be regardless of the SQL library you choose.

Beyond this, I'm not a fan of ORMs in scripted languages anyway.  It adds a lot of overhead for almost no real value.

Been playing with this for a while.  I setup a github project that will build via Lume and publish to Cloudfare Pages in about an hour.  The setup is relatively easy, I'd say it's a bit nicer than Jekyll and others I've tried.

Cool... Was considering ways to handle image positioning for my own blog setup.  Started playing with Lume a couple months ago, but didn't get much further than setting up some test entries and the generate/publish scripts.

I'm using Lume and publishing to a cloudflare pages site, which works pretty well.  Client-side search is interesting, inherited from the template I started with.  Will probably add MDX support for an Image component I can use for image positioning...

    <Image type={(left|right|full|expanded)} src={...} />

...type of thing.. basically want to handle either left/right or full, or expanded beyond text region.

Looks like I should be able to do this.

I'm really torn on removing this... it's OT (Python not JS based), but really interesting.  Thoughts?

When yarn started, it really was a performance improvement over npm at the time... but npm has gotten (much) better... I think it's just best to generally stick with npm, though the past couple jobs I've been at they were using yarn.

The debounce answer isn't quite right... the timeout should be from the first call, it should hold a map against the callback method, and expressly not reset the timer... the debounce should (generally) be from the first call, not the most recent call.  Although there are times you may want that kind of debounce, that's not how most libraries implement it.

The following question often tells me how well a developer actually understands JavaScript as a language.

What specific values are falsy in JavaScript?

Although that isn't the only question, most of the questions in TFA are really generic and most devs with any formal training can answer them.

I took a very similar approach when I made my first Node API over a decade ago.  In the end, it got complicated pretty quickly.  I actually really like the Koa/Oak approach myself.

When you get to the point of even several dozen routes, I can imagine the registration methods in TFA to become overly cumbersome to say the least.

Just my own $.02 on this.

Worth noting, that adding a month the naive way won't always get you what you should expect... for example:

    let dtm = new Date(2020,0,31); // Fri Jan 31 2020...
    dtm.setMonth(dtm.getMonth() + 1);
    console.log(dtm);
    // Mon Mar 02 2020...

That's not what you should expect, I would expect the last day of February.

    function addMonths(dtm, months = 1) {
      const month = dtm.getMonth() + ~~months;
      const ret = new Date(dtm); // clone date - don't mutate
      ret.setMonth(month);
      if (ret.getMonth() > month) {
        ret.setDate(0); // go to end of previous month
      }
      return ret;
    }

This way you can add to the date, without mutation and get the expected result.

    let dtmIn = new Date(2020,0,31);
    let dtmOut = addMonths(new Date(2020,0,31));
    console.log(dtmOut);
    // Sat Feb 29 2020...