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.
95% of apps people develop actually develop are really just CRUD and could easily get by without JavaScript on the front end at all. They certainly don't justify the layers of complicated state maintenance React and similar systems entail.
> 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 think the author is saying a potential issue of a vanilla implementation of immediate mode. The following text explains that there is already many optimizations for this
> I think the author is saying a potential issue of a vanilla implementation of immediate mode.
And you (pedro_movai) == the author? So you are saying that potential issue? Sorry, technically you are right that the author is saying that but I got confused with you referring to yourself in third person. Nothing wrong with it. Just want to confirm if you're the author.
That's called an "abomination". The advantage of immediate mode is not storing a DOM. If you write immediate-mode code but it stores a DOM anyway then it's the worst of both worlds.
I think the high quality of the author's website is more relevant than theoretical concerns about performance.
Loading performance on the s website is quite good, and it appears to be using the JS library described in the blog post. I also saw that pages were loading around 20kb or JavaScript or less.
Also, from looking at the author's GitHub profile, it appears that they do not make significant use of LLMs and actually took the effort to write the code by themselves.
Regarding small pages - there's a certain size threshold (that I don't remember - a few kB) where the entire HTTP response is sent back in the first TCP window for most client OSes, which allows minimum round-trips.
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.
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.
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
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!"
I do understand that's what they have in mind. But that's not what immediate mode means. Function application is not the only criteria.
We are talking about rendering into a browser by twiddling DOM APIs. That's definitely retained mode rendering and repeatedly claiming it's immediate mode doesn't make it true
You're showing your ignorance here. Different frameworks have different ways of working that can lead to better or worse performance on client devices, no matter what Fable spits out for you. You owe it to your users to care.
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 kind of agree but also
> what about X feature
To which I argue unequivocally YAGNI
95% of apps people develop actually develop are really just CRUD and could easily get by without JavaScript on the front end at all. They certainly don't justify the layers of complicated state maintenance React and similar systems entail.
> 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!)
> The only potential issue with immediate mode is performance, since we need to re-render the entire UI on every state change.
How this made it to HN front page?
I think the author is saying a potential issue of a vanilla implementation of immediate mode. The following text explains that there is already many optimizations for this
> I think the author is saying a potential issue of a vanilla implementation of immediate mode.
And you (pedro_movai) == the author? So you are saying that potential issue? Sorry, technically you are right that the author is saying that but I got confused with you referring to yourself in third person. Nothing wrong with it. Just want to confirm if you're the author.
"I think the author is saying" - Wait, are you not the author? This seems dishonest.
Nothing in HTML is immediate mode. Any framework with a DOM is retained mode, by definition.
But the api is trying to simulate immediate mode using DOM
That's called an "abomination". The advantage of immediate mode is not storing a DOM. If you write immediate-mode code but it stores a DOM anyway then it's the worst of both worlds.
How would you do layouting without a tree structure in place? Not really sure what you're getting at here
You have discovered one advantage of retained-mode designs.
I think the high quality of the author's website is more relevant than theoretical concerns about performance.
Loading performance on the s website is quite good, and it appears to be using the JS library described in the blog post. I also saw that pages were loading around 20kb or JavaScript or less.
Also, from looking at the author's GitHub profile, it appears that they do not make significant use of LLMs and actually took the effort to write the code by themselves.
Even this is more complex than many websites need to be. A few months ago I wrote about why I often create pages in pure html and css.
https://joeldare.com/why-im-writing-pure-html-and-css-in-202...
Regarding small pages - there's a certain size threshold (that I don't remember - a few kB) where the entire HTTP response is sent back in the first TCP window for most client OSes, which allows minimum round-trips.
Yes. You might be talking about the 14Kb problem.
https://joeldare.com/the-14kb-problem
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.
Link: https://starter.bryanhogan.com/
GitHub repository: https://starter.bryanhogan.com/
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.
Minimal UI library results in maximal App code, which makes it a good usecase for why you're better of with React/Vue
I looked at the author's website, and a typical page downloaded 20kb or less of JavaScript.
here is one that uses the fact that the raf loop will slow down when the tab is out of sync. makes state handling much easier. similar to dearimgui
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
Who knew the largest community in Web tech had it wrong all this time?
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
Nice! positive comment
After looking at the code in the tic tac toe example I am now 100% convinced that I need React.
React and systemd feel the same way to me: both really sensible ideas at the core, surrounded in layers of bullshit.
Maybe it’s not needed. But why not just use React anyway?
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!"
I read the blog post, and your framework looks great.
I think React is overused, and I'm happy to see people support alternatives.
> immediate mode
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.
I think the author is referring to immediate mode because of
UI=f(state)
I do understand that's what they have in mind. But that's not what immediate mode means. Function application is not the only criteria.
We are talking about rendering into a browser by twiddling DOM APIs. That's definitely retained mode rendering and repeatedly claiming it's immediate mode doesn't make it true
Discussing language preferences at all sounds very pre-Fable era
Tell me, mister Bofadeez Nutz, why does every non-AI post have to have these dumb "hurr durr just use AI" comments?
Framework, not language. And framework choice still matters.
So do programming languages, fwiw. The argument of "we have Fable, X doesn't matter anymore" is a severe case of delusion.
I would have agreed before I used Fable. It's not even vibe coding anymore. It's just coding.
E.g. Just always use Rust instead of Python.
Tomato tomato. English is my favorite new programming language.
You're showing your ignorance here. Different frameworks have different ways of working that can lead to better or worse performance on client devices, no matter what Fable spits out for you. You owe it to your users to care.