Plus the data itself (encoded in load-db.js) at another 101KB.

Though given the first couple of links on the current front page that are local (Ask HN) so small because this site is tight, video content, etc, have payloads of 4.2MByte (a Washington Post article), 2.2MByte (something on the Economist), 4.5MByte (Wired), 4.7MByte (the-odin), ..., if that 780K+101K is doing something genuinely useful it perhaps isn't that big compared to the bad standard set elsewhere!

For a serious use, storing the DB engine and data in local resources rather than reloading each time which the devtools network profiler suggests is happening, would be a good idea (preferably only transferring a diff when there is an update).

It really depends on the use case.

The upfront network cost will always be larger in comparison to independent queries, however the benefit will be less total network use after some threshold of searches due to eliminating the overhead of independent searches over the network. The other benefit is vastly improved latency of all searches after the initial page load.

Whether or not this makes sense is entirely subjective, it depends on the DB size, frequency of changes to affected data and the expected user behaviour... i.e is it extremely likely they will be making multiple searches.

I've not tried SQLite in the browser yet, but have used effectively the same solution for an internal tool by downloading all of the metadata needed for any possible queries from an SQL database. This worked very well under a certain size, making lightning fast, low latency local searches in the browser... but did not scale due to the particulars of the DB and the user case... eventually the initial metadata payload was not tolerable as the DB grew and the changes were frequent, requiring a new payload on every load of the page (unlike the authors use case), and so I switched to backend queries, the latency for individual queries is worse, but the total experience is better since the initial load is the same.

A single high-quality image on, say, a vacation rental website could easily be this large, to say nothing of a gallery of images for just a single property. Unless you're explicitly designing for 4G mobile connectivity, a properly-cached and CDN-distributed 1MB payload is absolutely viable.

It's a good concern. It does seem like it's sent uncompressed, gzipping gets it down to 360KB. Still hefty, but not _crazy_.

My interest in it isn't with websites. Redpanda supports using wasm (https://redpanda.com/blog/wasm-architecture) so that with Sqlite can make for very fast streams enrichment. Similar for using DuckDB depending on your data.

As of 2022, the average webpage size is around 2.2 MB for desktop sites and 2 MB for mobile sites, according to HTTPArchive.

Provided the WASM binary is cached by the browser (is it?), that would be equal to an additional web page load on the first visit.

My first reaction was that you need to send all potential search results across the network in the DB, which would be ok for a small app.

So, I guess there's a goldilocks app size where this is a good solution.