> On the topic of caching, since SQLite is (intentionally or not) going to be setting an example with their docs and demos[0], I would suggest that SQLite should demonstrate the industry best practices with regards to caching as well. Static assets like WASM and JavaScript should be served with a very high cache duration
That can't work on the documentation site because the wasm file is being served from the Fossil SCM and fossil cannot cache resources which are fetched by name because a new version may be checked in at any given moment (they're currently updated very often: https://sqlite.org/wasm/finfo/jswasm/sqlite3.wasm). Fossil can hypothetically cache resources which are fetched by hash, but that's not a feasible way for us to maintain the documentation on that site.
> ... although these topics could still potentially be mentioned in the documentation.
They're not relevant to the wasm/js deliverables. They're an implementation detail of the server which happens to be serving the related documentation. If you have specific verbiage which you feel would improve the docs in this regard, please feel free to send it. i'm likely to miss most responses in HN, so please use email (stephan at sqlite dot org) or the sqlite forum: https://sqlite.org/forum.
That can't work on the documentation site because the wasm file is being served from the Fossil SCM and fossil cannot cache resources which are fetched by name because a new version may be checked in at any given moment (they're currently updated very often: https://sqlite.org/wasm/finfo/jswasm/sqlite3.wasm). Fossil can hypothetically cache resources which are fetched by hash, but that's not a feasible way for us to maintain the documentation on that site.