uix VS searchkit

> But Reagent supports functional components as well, with hooks and all.

I addressed this already: while reagent is able to emit function components, there is a performance penalty to this.[1]

> I also very much like Hiccup, and so do many of us, because code is data and data is code, and Helix has decided not to support that.

Hiccup is convenient to write, but it is a constant run-time cost and a significant storage cost given that you have to store long series of constructors to cljs.core.PersistentVector in your bundle, have the JS runtime actually construct the vector, then pass it through a Hiccup interpreter to finally produce DOM nodes and throw away the persistent vector, only to repeat this entire process again on re-render.[2]

> Helix has decided not to support that.

That is simply not true. From the Helix documentation[2],

> If you want to use libraries like sablono, hicada or even hx hiccup parser, you can easily add that by creating a custom macro.

These are all Hiccup interpreters you can readily use.

IME there is very little difference between using the $ macro in Helix and writing Hiccup. I do not really miss Hiccup when I use Helix, and you still have data as code ;)

While this is from an unrelated project, there are benchmarks[3] done against Reagent that demonstrate the sheer overhead it has. In practice it is not a big problem if you rarely trigger a re-render, but otherwise it is a non-trivial cost, and if you want to use modern React features (like Suspense), there is a lot of r/as-element mingling going on, converting cases, etc. that simply make Reagent feel more tedious to use than Helix.

Also, the newer UIx2, which largely borrows from Helix, is "3.2x faster than Reagent" according to one of the contributors.[4]

I think it'd be worthwhile to benchmark all of these libraries against each other and record the data in one place. Maybe I'll get around to doing it this weekend :)

---

[1] https://github.com/reagent-project/reagent/blob/master/doc/R...

[2] https://github.com/lilactown/helix/blob/master/docs/faq.md#w...

[3] https://github.com/roman01la/uix#benchmarks

[4] https://github.com/pitch-io/uix/pull/12

https://github.com/searchkit/searchkit is an instantsearch adapter for elasticsearch / opensearch

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.

I think you are probably spending too much of your time on software and too little time on marketing.

When I look at an open-source project, I ask myself three things:

1) What does it do exactly?

2) Is this easy to get started with?

3) Does it have any documentation?

For example, I have a use case for wanting to use graphql to communicate with elasticsearch. I google "graphql + elasticsearch" and somewhere a link to https://www.searchkit.co/ comes up. I look at it and I find my answers within 60 seconds:

1) Top of the page I see "Searchkit is an open source library which helps you build a great search experience with Elasticsearch. Powered by Apollo GraphQL." This makes me think that yeah, it's probably looking to solve a similar problem to me. In case I had any doubts, there's a demo.

2) Yes, easy to get started. There's a big "get started" button at the top of the page. And a get-started-video link at the bottom of the homepage.

3) At a glance, yes, it has decent documentation.

Given that I quickly got answers to these 3 questions, yes, I might consider using this project, or at least trying it out.

When I go to your page, I see:

1) River DB is a Rust connection pool and middleware proxy... ok... why do i need that? What problem is this solving? There's a long paragraph I can read after that, but when i'm browsing the web i don't usually read long paragraphs, so you've lost me already.

2) I have no idea how to get started

3) Doesn't look like there's any docs

Given the above, why would I use your software?

Note that the above has nothing to do with your software quality. But people only care about your code if things are breaking. Marketing material is what gets them in the door. For example, I use React all the time. I have NO IDEA if the underlying code is any good. And I don't really care. What I care about is that it's easy to use.

Anyway, long story short... if you want to build a software business, coding is maybe 30-40% of the job. Marketing, sales, documentation and all that jazz is probably the majority of the work. If you don't want to do that and you just want to code, then great, get a job. People will pay you good money for that.