[HN Gopher] Libsearch: Simple index-free full-text search for Ja...
___________________________________________________________________
Libsearch: Simple index-free full-text search for JavaScript
Author : thesephist
Score : 75 points
Date : 2024-12-29 05:04 UTC (17 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| gabrieledarrigo wrote:
| Small and simple! I love these types of programs.
| swyx wrote:
| this is 115 lines of TS, which is pretty lightweight, but some
| other impt table stakes might be missing that you should be aware
| of.
|
| see all the JS alternatives with their sizes and feature sets and
| perf: https://github.com/leeoniya/uFuzzy (scroll to bottom)
|
| i went down this path a few yrs ago and ended up picking ufuzzy:
| https://swyxkit.netlify.app/ufuzzy-search
| leeoniya wrote:
| thanks, glad you like it.
|
| you might be interested in doing a follow-up/update to your
| post, to use the .search() api, which does more stuff out of
| the box, such as outOfOrder, quoted, and negatives
|
| Libsearch looks similar to uFuzzy (indexless regexp builder)
| but more simplistic. the other one i've seen that does this is
| sifter.js (predates uFuzzy, but i didnt discover it until
| researching libs to compare afterwards)
| jitl wrote:
| With FlexSearch or lunr or similar, building an index is so fast
| for "thousands of items" that it's fine to do it when the user
| opens a search interface and forget it once they're done.
| andai wrote:
| For thousands of items, do you even need one?
| jitl wrote:
| For typo resistance and stemming it's useful. Mostly it
| depends if your search matching logic needs to do allocation
| per document, like if you need to concatenate 10 strings
| together to get the complete search text and then split that
| into some kind of stem array, doing that O(thousands) of
| times per keystroke can be laggy in JS especially on memory
| constrained devices because GC pressure. Better to do it once
| up front. Then voila, you've got an index.
| leeoniya wrote:
| depending on the options you need (like typo tolerance),
| building the index can be quite slow and use a lot of memory
| bhl wrote:
| Any non in-memory search indices? Was hoping to find one that
| used indexeddb to implement fuzzy search. Maybe that's just not
| as performant which is why I haven't found a popular library
| yet.
| olivernn wrote:
| Many years ago, when I was building Lunr, it was initially
| based on IndexedDB, but it was _much_ slower and the datasets
| I had in mind easily fit in memory so I didn't pursue it. No
| idea if that has changed since though.
| maelito wrote:
| I'm often using Fuse in my JS apps. So many in-app searchs cannot
| handle typing errors, it's frustrating.
| Alifatisk wrote:
| What's the benefit of index-free?
| leeoniya wrote:
| much lower memory use, and instant startup time
| Alifatisk wrote:
| Oh
| no_wizard wrote:
| I never realized search like this was this easy to build in a
| way.
|
| It's a very clever RegEx engine, essentially. Though it's unclear
| to me right now how will this library handles fuzzy search (e.g.
| Califnia instead of California) but it's really cool to reason
| about its implementation
| revskill wrote:
| Look like grep.
___________________________________________________________________
(page generated 2024-12-29 23:01 UTC)