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).
A 700kb dependency isn't too bad in a modern browser + connection. Depending on how much else is loaded and how it is loaded.
Developers often have an out-of-date perspective on what is big these days and the realistic performance impacts. Especially with HTTP2 and multiple assets loading async.
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.
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.
I have seen this technique (send all the indexed search terms) a few times in the wild. Racket (a scheme derivative specifically made for teaching) has a search page where everything public is indexed [1] (see plt-index.js) and it works really well.
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).