Echo JS 0.11.0

Relatively thin article, mostly on how to use ServiceWorker for caching/offline use... other things to look into as a followup are online/offline detection and local-remote data sources.  May also want to look into pouchdb and other options for data syncing.

Aside: haven't looked into it... but have wanted to try to get a couchdb setup or proxy where there are read-only data sources that cache locally, and read/write data sources that sync per-user via couch/pouch.  Of course there's also other potential issues depending on use case.

#4 favor async/await and Promises in any modern codebase, this has been in Node for a while without a flag.

#5 is express specific... aside: if your API is meant explicitly for your front end, I would reverse proxy a slice for `/api` from your front end host if you can.  This does mean you won't be expressly static-only for the front end, but you do avoid a class of headaches and can do other stuff such as SSR, donut rendering and other caching or output customizations.

Still more of a fan of dokku on Digital Ocean, Linode or similar for smaller/personal projects.

Using a $15/mo droplet on DO, with a 100GB volume and backups ($28/mo) and it handles half a dozen personal projects with room for more.

No mention of BigInt[1]

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt

Really nice to see this... would also be nice to see a shim library that isn't too big that takes care of the abstraction for you... this way if you're on a desktop browser without the sharing API, you can present the common social media sharing buttons if the API isn't available.

Nice to see Preact catching up on some features in React proper... I stopped even trying to target Preact a little over a year ago for a couple reasons.  First is missing features in React that are very useful, this is a large bridge.  The second is that React has *REALLY* helpful tooling in terms of diagnostic messages in the console as well as browser extensions themselves.

Beyond this, the extra 60k or so that React has in payload over Preact + compat isn't that much in relation to an application's payload, and the performance difference is negligible in most real world cases (in my experience), so I've favored the better tooling and diagnostics.

That said, I do love to see smaller frameworks as they are an incredible option for bandwidth and resource limited devices or when using a progressive enhancement.

Please, don't use HMAC via shared secrets for JWT if you can avoid it at all... prefer RSA signed keys, this way only the public key is shared and the private key only needs to be secured in one place.

Here's a more relevant article with actual code examples.

https://link.medium.com/0W35cJtseZ

Though I would go with a 4092 bit key and use RSA 384 for the signing.  The article mentions generating keys in Chrome... unless you have a real use case for this, then go for the stronger options on the server.

Nice writeup... not a fan of using Classes outside of contextual needs, and even then often not needed.

One bit of warning, do *NOT* use deep inheritance chains if you are dealing with large arrays of objects and inherited properties, the lookup against the prototype chain is relatively expensive.  Often, you are better off with composition if you need more than 1 layers of inheritance.

More info on CSP[1] and a JS library for this[2]

* [1] https://en.wikipedia.org/wiki/Communicating_sequential_processes
* [2] https://github.com/js-csp/js-csp

I do agree... and the number 100 devs is probably a bit over the top.  It's only that a lot of people will try approaches like this on a very small scale and will run into serious problems of orchestration at a small scale that tends to outweigh the advantages.  I've worked on similar approaches in the past and see both sides.

My advice is simply caution and YAGNI to an extent.  Much like most Enterprisey patterns in general, many lead to more friction than they're worth.