Client-side search update

support
1

I put this in the support category, but it’s for general discussion.

In terms of search libraries, of course server side is king, and then technologies like blevesearch, which comes with apparently a robust selection of query options, start to look pretty good. And then there’s of course Algolia and Elastisearch (with the correct spelling, respectfully).

But client-side isn’t bad, and Lunr does a pretty good job if you do a bit juggling with the search term, in my opinion.

Having said that, I don’t want to miss out on something better if it’s there.

Does anyone have an opinion on pageFind vs Lunr, or any opinions on other libraries, like Fuse.js, vs Lunr?

I’m not talking about pre-indexing, which matters but not as much as what happens in the JavaScript runtime.

How much difference can there be between pageFind and Lunr in terms of JavaScript operational efficiency and upfront loading time?

You load the data, you parse it, … … , that’s it.

Is one of those two libraries better than the other on the JavaScript side?

Has anyone tested more than one?

Are there any links to new information I should know about?

2

From my own tests/experience with PageFind and Fuse JS…

  1. JS size is negligible with gzip/brotli compression.
  2. With Fuse JS, the JSON search index file size is what you should look into. If you include full content, then the file size grows larger.
  3. Fuse JS was ‘more accurate’ than Pagefind in linking search terms to pages.
  4. Pagefind works out of the box for multilingual sites. With Fuse JS, you will need to configure that in your code.
  5. I needed to configure my website to show different results per section that were related to that section, using the same search box, when a user navigated to a particular section. It was easier to do that with Fuse JS.
  6. I would recommend Pagefind though if you only need the same search results for the whole site. I went with this implementation of Fuse JS as a base and expanded upon it.
1 Like
3

+1 for pagefind. It’s fast, and you can create sections, which is a cool way to separate different sections/versions/products of a site.

2 Likes
4

As a theme author, anything other than hugo server to generate a working search is unexceptable because it is uncomfortable for the user.

In the past I’ve used Lunr. It served the project well, but it is not activley maintained for the last years and search technology went ahead.

So I’ve looked for replacements and have validated the common suspects like PageFind, BleveSearch, FuseJs and a few other.

So far Orama (formerly Lyra) seems to be good fit, although I’ve experienced some WTF moments with the new 3.0 version.

1 Like
5

Nice, how ORMy/Prisma-ish :+1:, looks worth exploring, especially if you can build and store the db file then access it with a fetch call, or the request/response framework friendly db call they specify in the docs await readFile(resolve(ROOT_LOCATION, ${id}.json), "utf-8"). That would be scaleable.

6

I read through the docs quickly. I saw prebuilt results functionality, but no example that parses the response object, so each data point can be written to the page with JavaScript in any way desired. Presumably that would be obvious once one starts working with the library. Marking components and crawling HTML also offers separation from the Hugo build step, in that you don’t need to generate json output every time, like you do with Lunr (though that’s not really a problem in my case).

7

Agreed! I remember doing hugo --gc also cleared the Pagefind files and I had to run their command again and again after cleaning the public folder.