-
The "performance angle" isn't really an angle. It gets bandied around by junior devs new to React, but it's not the primary selling point of React - in fact, it's not a selling point at all. Don't believe me? Just go to http://react.dev and look - no where on the site does it say that React is a hyper-performant library. It's not! If you need blazing performance, you're best off using something much more minimal, or even vanilla JS.
What React is good at is forcing you to write code in a clear, comprehensible way. Having every engineer on your team obey F(props) = state is a strict improvement over virtually any other paradigm. (Yes, you can still make a tangle of components if you try hard enough, but the complexity of the tangle is capped significantly lower than the complexity of a tangle of JS without any framework attached.)
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
I also made a UI library based on the idea of jsx template expressions that produce real DOM nodes. It also binds model objects to attributes, eliminating some of the imperative event handler boiler-plate. I think it's a great idea, but of course I would.
https://github.com/tomtheisen/mutraction
It lets you do stuff like this.
const model = track({ clicks: 0});
-
-
Imba is what anyone interested in this sort of thing should look at. I have no idea why it is not more popular. Maybe because JS devs falls for Faang marketing easily.
https://imba.io/
-
van
π¦ VanJS: World's smallest reactive UI framework. Incredibly Powerful, Insanely Small - Everyone can build a useful UI app in an hour.
VanJS deserves a mention here! https://vanjs.org/
Another interesting thing is that other JSX libraries like Solid.JS also return DOM nodes, and I love that this idea is gaining traction
The closer we get to the platform we're using, the better. Being removed by layers of abstractions CAN be useful, but in practice, I haven't found a use for abstracting away the platform. (yet.)
Maybe huge projects like Facebook benefit from this tho (which I haven't worked on)
-
> E4X had the unfortunate downside of returning actual DOM instances, which needed to be updated imperatively
Firefox never shipped the optional E4X DOM APIs. I wrote a polyfill for them at the time.[1]
1. https://github.com/eligrey/e4x.js/blob/master/e4x.js
-
Not exactly JSX, but I came across a package django-cotton[https://github.com/wrabit/django-cotton], that is html syntax first components.
-
My framework (imlib[1]) is actually more of a framework akin to Astro than what's showcased on vanillajsx.com, which itself is built with imlib.
It just runs your code in a node.js process, and translates your JSX expressions into jsx() calls. On the node.js side[2], jsx() returns a string from its tag/attrs/children. On the browser side[3], jsx() returns DOM elements.
Combined with a little bit of architecture, it becomes something extremely well suited to creating static sites. I guess SSG is an outdated term now, maybe it's a framework? Or a platform?
In any case, it seems to do something similar to Astro, but in a significantly simpler way. The only "bundle" it needs in the browser is /@imlib/jsx-browser.js [4] which in itself is just jsx-dom.ts (its impl is overridable by the "framework" user). And on the node.js side, it's implemented as a very small "vm" of sorts [5].
I'm not against Astro, I just get all the same benefit people here are saying Astro has, but with orders of magnitude more simplicity imo.
[1] https://github.com/sdegutis/imlib
[2] https://github.com/sdegutis/imlib/blob/main/src/jsx-strings....
[3] https://github.com/sdegutis/imlib/blob/main/src/jsx-dom.ts
[4] https://vanillajsx.com/@imlib/jsx-browser.js
[5] https://github.com/sdegutis/imlib/blob/main/src/runtime.ts
-
You might find this project[0] interesting if you havenβt given it a look.
It was attempting to do something along the same lines as you first suggest
[0]: https://github.com/jridgewell/jsx2
-
For anyone who can live without <> syntax I made DOM Maker, no compilation step, no injection vulnerability footguns, just make a bunch of function calls in a tree structure, and you get DOM with the same tree structure, complete with non-string event handlers.
Mostly I just do Vanilla.js, but the vanilla DOM creation functions turn really verbose, I got tired of that and created this to cut back on code size and increase readability.
There are other libraries that do something similar, but in my own very biased opinion this is one of the better.
https://github.com/NoHatCoder/DOM_Maker
-
Stop the madness. Its stupendously simple.
As the user, not you the author of some code, make changes to the UI it will be via events. In the respective event handlers just update a big state object with the identity of the node and how it is changed. Then the page loads simply read from that state object to recreate the respective node exactly how they were when the user modified them. That's it. Nothing more.
Its how I wrote a full OS gui for the browser. It does far more than SPA framework, does it substantially faster, and requires only a tiny fraction of the code.
Yes, yes, here come all the excuses, like: I can't code or it wont work in a team, because other people cant code. Stop with the foolishness. Provide some governance, preferably fully automated, around event handling and you have complete obsoleted your giant nightmare framework.
I describe it here: https://github.com/prettydiff/wisdom/blob/master/state_manag...
Related posts
-
7 Most Popular JavaScript Front-End Frameworks in 2024 Visualized with Graphs ππ
-
Littlefoot β a jQuery-free fork of Bigfoot.js popup footnotes JavaScript library
-
Introducing ArrowJS β’ Reactivity without the framework
-
Build a Container Package for your React App with Docker and GitHub Actions
-
Svelte + Manifest = Giving Svelte a proper backend with 7 lines of code π§‘π¦