I've been looking for a simple incremental client-side search for my personal wiki (https://beepb00p.xyz/exobrain), but didn't find anything immediately suitable sadly. Basically I wanted the indexing & search to be as simple as possible:
- take in the raw HTML files (so it's agnostic to the site generator)
- indexing should be respectful of `id=` anchors, so you can jump directly to the occurence in the document text (instead of just the HTML). I looked at Stork, but it didn't look like it was processing these. Do you think it would be a good idea?
- embed a simple search, lazily, so the index is only fetched when you focus the search field
- ideally, <mark> the matches in HTML, in a similarly generator-agnostic way (although it might be trickier)
I ended up implementing my own via a relatively script + lunr.js, but I think if someone nailed such setup and made it really simple. It's a shame it's so tedious to add incremental search to a static blog/wiki.
P.S. demo on https://stork-search.net/ doesn't work for me now, I'm getting CORS error on fetching https://files.stork-search.net/federalist.st
While the `(made for static sites)` is probably meant as selling point, I'm afraid it can be a limiting factor.
E.g. Stork can be used on your WordPress, Drupal or whatever site, quite well I presume; I don't see why not. It would require hacks and some tradeoffs, sure.
Many OOTB CMSes come with "search", but that search is poor, the performance problematic and the results are awfull (searching is hard; searching dynamic generic content even more so). I've helped many a Drupal and Wordpress site implement ElasticSearch or SOLR/Lucene back in the days. For the vast long-tail of websites such setups are not an option. Meilisearch is the first that gets closer to a viable option for those.
Stork could get even closer. And (unfortunately) the amount of WordPress blogs that would need Stork (alike) for search is vastly bigger than static sites.