Show HN: A JavaScript UI library for imperative JSX

It's cool to see a novel idea like this get prototyped and then opened up for discussion.

As others have hinted at, this feels like jQuery with different syntax and more limitations. In its current form, I can't imagine choosing this over jQuery (in part because I already know jQuery, and in part because the limited reach of your selectors feels like it would be a roadblock very quickly).

Perhaps you could reshape this to be an extension of jQuery, where this alternative jsx syntax is available if you want it, but the full power of jQuery's selectors is also available (without having to mix two libraries with overlapping purpose)?

That aside, I can't imagine abandoning React for this. That would feel like a step backwards to me. IMO, the most valuable thing React brought to the ecosystem is a simple way to make reusable components. Much of React's convenience is because of its functional nature: each component instance has an isolated scope/context, making it easy to reason over the behavior of a small widget without worrying about external effects from the larger application.

From what I can see in your examples, you're relying on things like global identifiers/keys, which I think leads to a mess in a large application. Take your counter example: what if my application needs 5 such counters? Can I do this without significant code duplication? I could probably wrap it in a function, but I'd likely need to pass in some unique id to distinguish between the 5 usages. This is a huge part of what React does for you, just keeping track of which component instances go where in the DOM (without needing DOM `id`s everywhere).

It could be that I'm missing something. It'd be great to see some larger examples of a more complex application with widget reuse, to see how that feels.

> If we accept the fact that the web is inherently imperative, then I believe we can resolve most if not all of the above problems. We don't need to throw the baby out with the bathwater though, because JSX is fantastic.

Also look into SolidJS for dropping the "functional" component model while still retaining JSX - it looks similar to React but works more like Vue, running components as setup functions only on initial render and doing state updates with mutations via signals.

That's the worst idea for framework I've seen recently

JSX without React is also kind of fun: https://medium.com/@victor.dramba/can-you-do-jsx-without-rea... and it's working example at: https://github.com/dvictor/jsx-no-react/blob/master/index.ts...

Thanks for sharing, neat. This makes me curious about the psychology of declarative vs imperative, and why some people gravitate towards one or the other (at least with UI code).

Back in the jQuery days, a lot of my hatred towards "JavaScript" was actually imperative UI code in hindsight. In the years since, I now enjoy declarative UI more but see some developers bang their head against declarative UI frameworks. It's an interesting contrast.

If you want to use JSX without React see this 500-line lib: https://github.com/wisercoder/uibuilder

And here's an app built using this lib: https://github.com/wisercoder/eureka/tree/master/webapp/Clie...

Can you talk a little about the pain points you encountered, which this presumably solves?

This reminds me of google’s incremental dom (https://google.github.io/incremental-dom/ ) it surely made some things (like making sure an element has focus) a lot easier to do and in general felt a bit more like something that works with the browser instead of against it.

Hmm, interesting. What advantages do you see of using JSX for querying over the old jQuery-style $("#id").append(...)? Did you consider doing something more like that, but allowing JSX instead of HTML strings like it was done in jQuery?

Mithril seems like it can do something pretty similar: https://mithril.js.org/jsx.html

(Not trying to discourage you, just linking it)

I would never want to write it the same element in multiple places like this.

That's one of the main points of templating in the first place: to write the code for a piece of output once, with all of the bindings that can affect it.

What happens here if you update the JSX for an element in one place and forget to do so in the others?

> The structure of your application state ends up being shaped by the UI, when it should be the other way around

I don’t understand this premise at all. Are you saying your UI should be shaped by your application state? That doesn’t make any sense to me, surely the application state exists to implement a desired UI?

This is jQuery-like. Just syntax sugar above the imperative DOM API. Looks like the younger generation didn't know the pain of years of imperative UI "frameworks" and needs to learn this the painful way. Enjoy!

Why not use template literals and a css like syntax for selecting and update?

setContent(css`p[key=counter]{ content: 'The count is ${count}'}; }`);

React, the good parts