The "static page" is referring to https://localfirstweb.dev/. TinyBase, the tool with embedded SQLite and React support (among other things) is for reactive (non-static) web applications. Native JavaScript language feature like maps are not an adequate replacement for the functionality offered by TinyBase.

What I said. Local embedded SQLite and React is not tiny, it's huge. And slow.

And native JS only is adequate for tiny first web. Clients do care about ms vs 5s load-times.

I agree on React, but not necessarily on SQLite. It's made for use cases like this and it can handle quite a lot of data with a humble footprint.

Ironically, if you use something browser native indexeddb plus JS instead, you are also likely indirectly using SQLite as far as I know.

The react module for TinyBase is optional, and if you're just using their store module you only add 5.3kb gzipped to your final bundle, hence the name TinyBase.

I also don't think you understand the complexity of the features that TinyBase is offering. It's possible you don't personally need these features, but critiquing the software for not being totally minimalistic is a bit silly.

how do you say, implement full-text search in a local first manner? How about vector search? (don't even know if it's a thing yet, sounds possible these days). Imagine saving a local copy of a docs site (a sizable set of pages) and have search and stuff working perfectly

Build the index as a static file and query it using js? This has been my approach so far — admittedly, this isn't with millions of pages, but I'll continue to use it for as long as it works. When hosted on the internet, the search is still blazingly fast, way better than most other sites I come across.

For a very similar scenario I'm currently looking to use PGlite: https://pglite.dev/ which is a 3MB WASM build of Postgres which also includes pgvector.

stuff like https://lunrjs.com/ works

Can it index images by semantic, that is what vector search can do