instantsearch VS instant-search-widget

Thanks! Here's a GH Issue about it that I follow: https://github.com/algolia/instantsearch/discussions/5413#di...

One example of this pattern is Searchkit [0] which performs most of its logic inside a singleton Searchkit class which is instantiated and passed as a prop to the root React component. A bonus is that it's easier to implement bindings for Angular, Svelte, etc. since they can rely mostly on the class. For example, it looks like Searchkit now suggests using InstantSearch (react-instantsearch-dom) [1] from Algolia, i.e. an entirely different maintainer, and it creates the bindings with a `Client(new SearchKit(...))` adapter [2] around the class (see the code on the home page at [0]).

[0] https://www.searchkit.co/

[1] https://github.com/algolia/instantsearch

[2] https://github.com/searchkit/searchkit/blob/main/packages/se...

We will use React, Next.JS, Instantsearch and Searchkit to build a search UI.

Algolia suggest to use InstantSearch.js library to build your search interface and perform search queries directly from the end-user browser without going through your server.

Like the speed of our search, but want your own implementation? We got you covered! Internally, our widget uses our Instant Search Client to handle all the requests and functionality. With this client you can build your own solution or connect it to for example instantsearch.js or react-instantsearch-dom. With these packages, you can create your own UI that is connected to Afosto Instant Search. Take a look at the demo on our website, or use the CodePen below as an example.

No UI specified but they do have tutorials for InstantSearch

But it also makes it easy to be integrated within existing applications by using the InstantSearch.js library through the Typesense-InstantSearch-Adapter.

We are curious about what you think of our search widget. Feel free to leave a comment or check out our GitHub for more information or to report an issue.