Comment by seanwilson
6 days ago
I've used https://lunrjs.com/guides/getting_started.html briefly and it has lots of options for things like different fields, complex queries, fuzzy searching and wildcards. Didn't notice anything specific about dates but you could always add date as a field then filter out a date range manually at the end. I'm sure there's better libraries now as well.
We've gone from SSGs for ease, speed and reduced resources, to talking about implementing search with multiple megabyte client side indexes and hundereds of thousands of prerendered search result pages.
When does this become 1 step forward with the SSG and 2 steps back with search solutions like this?
You don't pre-render the search pages. You generate some search index files on the build step (something like a map of keywords to matching post URLs), and then client side JavaScript requests the search index files it needs on demand and generates the search results on the page. For a modest blog, I think the compressed index can be a few 100K. A single large image can be bigger than that.
Nothing is perfect, but the above is really simple to host, is low maintenance, and easy to secure.
This is just server side search with more steps, since the index needs to be selectively split and returned, and then search results page generated from the index.
Sorry, I don't mean to come across as disagreeable. You're right, nothing is perfect, and this is obviously a workable and usable solution. My issue is if we analyse it beyond "it looks like it works", it starts to look like a slightly worse solution than what we already had.
Nothing wrong with moving backwards in some direction, as long as we can clearly point to some benefit we're getting elsewhere. My issues with SSGs is most of the benefits they offer end up undermined if you want any interactivity. This is a good example of that, as you end up compromising on build time and page load time compared to an SSR search solution.
7 replies →
Interesting attempt at bad faith discourse.
Assuming 500 bytes of metadata + URL per blog post, a one megabyte index is enough for 2000 blog posts.
As already mentioned, you don't generate search result pages, because client side Javascript has been a thing for several decades already.
Your suggestion of converting markdown on every request also provides near zero value.
Writing a minimal server backend is also way easier if you separate it from the presentation part of the stack.
Based on https://news.ycombinator.com/item?id=46489563, it also seems like you fundamentally misunderstand the point. Interactivity is not the point. SSGs are used for publishing writing the same way PDF is used. Nobody sane thinks that they need a comment section in their PDFs.
I'm sorry, I find your post insulting. I wasn't engaging in bad faith discourse intentionally, but your assumption that I am - ironically - doesn't feel like appropriate etiquette here either. Despite that, I'll try answer sincerely.
Your 1 megabyte index file has just added over 2 seconds to your page load time in 30 different countries based on average internet speeds in 2024. Chuck in some pictures, an external comment library and your other SSG hacks, and you've just made your website practically unresponsive to a quarter of the planet and a bunch of other low powered devices.
Value is relative. The benefit of rendering markdown on every request is it makes it easier to make it dynamic, so you don't need to do SSG compromises like rebuild and reupload multiple pages when a single link changes.
You're replying in my thread here, to my original points. My original points were that SSGs don't make sense for sites with interaction, which is why were were discussing the limitations of SSG search approaches.
> SSGs are used for publishing writing the same way PDF is used. Nobody sane thinks that they need a comment section in their PDFs.
Thank you! We're in agreement, it doesn't make sense to use SSGs for sites that require interaction. When you do, it forces the rest of your site to do the compromising search stuff like we're discussing here.
1 reply →