TFA uses Contentful, a commercial service. Which is against the rules, strictly speaking, but the content in the article is useful, so I added a [PAID SERVICE] tag in the title instead of outright deleting the post.
Additional reading "The 12 factor app" https://12factor.net/ part 3.
Beyond this, TFA fails to mention you should have `.env` in your .gitignore file and *NOT* check this into source control. Generally speaking, I will create defaults that will work without a .env file locally if possible. I will, however, create `.env.template.env` and `.env.dev.env` files.. the prefix is to keep them together, the suffix is for my editor's plugins. The template version, I have setup for string replacement for CI/CD integration in a non-container environment... the dev version is for local development, with non-secure resources/passwords etc that are only for local dev.
Here's some boilerplate that I am using.
https://gist.github.com/tracker1/7fd48e818f3b80c8266f04029e989f59
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.
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.