If you are going to advocate against something, the alternative you propose needs to be better in some important area, other than "not that thing".
What is the thing you hate about react, and what is the thing you require in an alternative?
I hate bloat and require lightness, so I use Preact.
I also hate complexity and difficult to read stuff, so when I look at the proposal here, I don't see anything appealing, other than "look! it's not react!"
> The only potential issue with immediate mode is performance, since we need to re-render the entire UI on every state change.
Notice that in the task list example, if you leave some text in the input and check off a task, your text will be erased.
If we could truly treat the DOM as an immediate-mode UI, there would be no need for React/Preact/ Svelte/Solid/etc. But it turns out there are a fair number of quirks like this that preclude such simple replacements from working correctly.
(That said: I am all for experiments like this for learning, or for fun, or to try out unexplored framework design space!)
I agree that React gets overused for many websites, but I'm not sure about this project over something like Astro.
I built an Astro Starter that uses just CSS in a scalable way for simple websites. Content is written in Markdown / MDX files. Design tokens are set in var.css. Other stuff is defined in one config.ts file.
Global styling is set though a few CSS files (Global, Reset, Var, Util, Markdown), components are scoped in styling but utilise the tokens.
unlike many of the commenters, I found this pretty nice and educational, there are full stack developers who cannot write anything outside React and do not even understand why React was created in the first place
I think React is way overused but every time you see a blog post with "replace it with this pet mini project instead" I groan because you know the reaction is going to be "what about X feature", and of course the mini framework doesn't do it.
I've found the perfect balance to be Astro with Preact. You will inevitably have some piece of functionality that's complex (say, a contact form) and you can lean into Preact for that. But for the vast majority of a content-heavy site you can just use Astro and skip the client-side bulk entirely.
STANDARD DISCLAIMER ANY TIME I COMMENT ON FRONT END DEV: your project may be different. A blog or a shopping site and have extremely different requirements to a full Gmail-style web app. There does not need to be a one size fits all answer.
I wish that before someone writes yet another article on "You don't need React" they can do a Google search to look up all the 1000 articles already written with the same arguments and the discussions around that.
on the backend this obviously runs only once. the main issue with backend frameworks is, that the request and other context data has to be passed through the business logic + VIEWS. leads to tight coupling of all the components as it is downstream from the data structure + presentation
this is resolved by resolving the html template strings at the end and allowing functions (that also produce html template snippets) to be passed into the template strings.
Actually browsers already come with a minimal UI library. It's called HTML + CSS + JS.
There's actually no need to make any wrappers - you describe what you want in HTML and make it look good with CSS.
You only need to make UI using JS only for complex components.
Case study: I tried porting an old strategy game from pygame to web using codex. Codex decided that it doesn't need any library and raw-dogged HTML. It was able to match look and feel of an old UI with a very simple, maintenable code. Doing that with just CSS sounds kinda tedious to me, but it can be done, and honestly it looks more maintenable than any UI library.
A 50-100 LOC library that provides 80% of what React does is very easy to create.
I created one of those 14 years ago before React, to replace things like mustache and similar templating languages. That doesn't take away from your effort. It's a good idea for anyone to recreate their favourite lib to understand the principles.
And that’s fine. It’s easy to replatform later with LLMs.
With vanilla you typically do class based components for organization (which can be quite clean in type=“module” with import/export) and you end up writing a complex View type class that does all the DOM manipulation.
You gotta hide the framework somewhere or you’ll repeat yourself a lot
Bonus points at scale you invent a templating solution. Maybe you use JSX
A major feature of React (like Java) is the ability to reduce the blast radius of errant colleagues through much stricter boundaries.
In the AI/vibe coding world this becomes even more valuable, on top of the fact LLMs are well versed in React already and don't need to eat context to understand it.
The problems are people then assume that because you're using React you must use next.js, vite etc. Then you're in trouble.
40 comments
[ 1.9 ms ] story [ 47.2 ms ] threadHow this made it to HN front page?
What is the thing you hate about react, and what is the thing you require in an alternative?
I hate bloat and require lightness, so I use Preact.
I also hate complexity and difficult to read stuff, so when I look at the proposal here, I don't see anything appealing, other than "look! it's not react!"
You keep using that word. I do not think it means what you think it means.
React most definitely falls under what would be called a "retained mode" of some sort. And the UI library described here is also.
Notice that in the task list example, if you leave some text in the input and check off a task, your text will be erased.
If we could truly treat the DOM as an immediate-mode UI, there would be no need for React/Preact/ Svelte/Solid/etc. But it turns out there are a fair number of quirks like this that preclude such simple replacements from working correctly.
(That said: I am all for experiments like this for learning, or for fun, or to try out unexplored framework design space!)
I built an Astro Starter that uses just CSS in a scalable way for simple websites. Content is written in Markdown / MDX files. Design tokens are set in var.css. Other stuff is defined in one config.ts file.
Global styling is set though a few CSS files (Global, Reset, Var, Util, Markdown), components are scoped in styling but utilise the tokens.
Link: https://starter.bryanhogan.com/
GitHub repository: https://starter.bryanhogan.com/
I've found the perfect balance to be Astro with Preact. You will inevitably have some piece of functionality that's complex (say, a contact form) and you can lean into Preact for that. But for the vast majority of a content-heavy site you can just use Astro and skip the client-side bulk entirely.
STANDARD DISCLAIMER ANY TIME I COMMENT ON FRONT END DEV: your project may be different. A blog or a shopping site and have extremely different requirements to a full Gmail-style web app. There does not need to be a one size fits all answer.
https://joeldare.com/why-im-writing-pure-html-and-css-in-202...
I think React is overused, and I'm happy to see people support alternatives.
frontend example https://github.com/spirobel/counter/blob/master/frontend/cou...
on the backend this obviously runs only once. the main issue with backend frameworks is, that the request and other context data has to be passed through the business logic + VIEWS. leads to tight coupling of all the components as it is downstream from the data structure + presentation
this is resolved by resolving the html template strings at the end and allowing functions (that also produce html template snippets) to be passed into the template strings.
this decouples views, business logic and data
https://github.com/spirobel/mininext/blob/master/docs/archit...
worked on this for the last few years. But it is still only a few hundred lines of code that you can understand in a few hours
There's actually no need to make any wrappers - you describe what you want in HTML and make it look good with CSS.
You only need to make UI using JS only for complex components.
Case study: I tried porting an old strategy game from pygame to web using codex. Codex decided that it doesn't need any library and raw-dogged HTML. It was able to match look and feel of an old UI with a very simple, maintenable code. Doing that with just CSS sounds kinda tedious to me, but it can be done, and honestly it looks more maintenable than any UI library.
And that’s fine. It’s easy to replatform later with LLMs.
With vanilla you typically do class based components for organization (which can be quite clean in type=“module” with import/export) and you end up writing a complex View type class that does all the DOM manipulation.
You gotta hide the framework somewhere or you’ll repeat yourself a lot
Bonus points at scale you invent a templating solution. Maybe you use JSX
I think this is an underrated perspective in these discussions.
FYI this exists https://github.com/developit/htm which couples well with preact browser only (no npm/node compilation)
In the AI/vibe coding world this becomes even more valuable, on top of the fact LLMs are well versed in React already and don't need to eat context to understand it.
The problems are people then assume that because you're using React you must use next.js, vite etc. Then you're in trouble.
use query selectors and manually do fine grained updates
i don't think it works for everything, but a few years back i started doing it for side projects and never really missed any of the frameworks