If your element has an id, you can just reference it from the window scope

This is brittle, as defining a global variable with the same name (or the browser adding a API with the same name) will override it. This functionality was only kept for backwards compatibility with sites designed for Internet Explorer. The spec says to use getElementById instead.

One of SQLite’s recommended use cases is as an alternate to proprietary binary formats: https://sqlite.org/appfileformat.html. Programs often store data in binary files for performance, but you get a lot of the same functionality included with SQLite (fast random access, concurrent usage, atomicity, updates that don’t need to rewrite the whole file, etc) without having to implement a file format yourself.

I’m not sure if this is still the case, but Facebook’a HHVM used to store the compiled bytecode for the whole site in a single SQLite database: https://docs.hhvm.com/docs/hhvm/advanced-usage/repo-authoritative/. Every pageload loaded the bytecode for all required files from the DB.

SQLite is underrated. I’ve used it for high traffic systems with no issues. If your system has a large number of readers and a small number of writers, it performs very well. It’s not as good for high-concurrency write-heavy use cases, but that’s not common (most apps read far more than they write).

My use case was a DB that was created during the build process, then read on every page load.

This is one of the reasons they’re reducing the validity - to try and convince people to automate the renewal process.

That and there’s issues with the current revocation process (for incorrectly issued certificates, or certificates where the private key was leaked or stored insecurely), and the most effective way to reduce the risk is to reduce how long any one certificate can be valid for.

A leaked key is far less useful if it’s only valid or 47 days from issuance, compared to three years. (note that the max duration was reduced from 3 years to 398 days earlier this year).

From https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days:

In the ballot, Apple makes many arguments in favor of the moves, one of which is most worth calling out. They state that the CA/B Forum has been telling the world for years, by steadily shortening maximum lifetimes, that automation is essentially mandatory for effective certificate lifecycle management.

The ballot argues that shorter lifetimes are necessary for many reasons, the most prominent being this: The information in certificates is becoming steadily less trustworthy over time, a problem that can only be mitigated by frequently revalidating the information.

The ballot also argues that the revocation system using CRLs and OCSP is unreliable. Indeed, browsers often ignore these features. The ballot has a long section on the failings of the certificate revocation system. Shorter lifetimes mitigate the effects of using potentially revoked certificates. In 2023, CA/B Forum took this philosophy to another level by approving short-lived certificates, which expire within 7 days, and which do not require CRL or OCSP support.