Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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.by karol
- React isn't immediate mode. The dependency array, amongst other things determine what redraws and what doesn't. Yes, you can make React look like it's running in immediate mode, fully redrawing on every frame. But if you do that then you're probably in the wrong line of work. Maybe try management.
This post is impressively bad. It's been AI generated and the AI doesn't even know what immediate mode is. Did you use Grok?
by satnhak - 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.by fg137
- 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/
by bryanhogan - 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.
by fidotron - 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...
by codazoda - Regarding small pages - there's a certain size threshold where the entire HTTP response is sent back in the first TCP window for most client OSes, which allows minimum round-trips.by inigyou
- I ran a web dev company for decades. There are two web sites we created I would bet money you have visited so we weren't a small, one-off shop. We had never seen the need or desire to use React. We couldn't understand why anyone else would use it either. It was too big and too complicated versus just using the fundamental elements of programming for the web. So there.
- Counterpoint: I'm currently employed building many apps for an enterprise you'll never visit. React+Typescript rewrite of our legacy "lean" Javascript has measurably improved the productivity of the team and the maintainability of code.
I can't imagine going back to learning bespoke libraries written by (especially!) hotshot cowboy coders. React makes everybody on the team better, and literally no customer has ever complained about the extra 200ms load time.
by FeloniousHam - > 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?
by Oras - 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 60kb 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.
by gulugawa - 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 thisby pedro_movai
- 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.
by killerstorm - For me, what the browser needs it's a good DX to build components, I kind of like Svelte and Vue in that regard, where your CSS, HTML and JS lives all together.
Writing a CSS file with the time will start growing and at some point will be very hard to know what to keep and what to delete, I think this is the reason why tailwind became popular, because it keep only the used rules, now the downside is that now your html elements has ton of classes.
by norman784 - The problem is really folks trying to one-size-fits-all web projects. React basically exists to give a “good enough” GUI toolkit functionality in the browser. On the other hand, the web was built to publish content as in articles and information. Everything kind of sits somewhere on the continuum between static content and the interactive app experience. At the extreme it can be interactive “art” piece.
It is important to consider digital media (as in art medium) best to convey an idea. And folks should start with HTML/CSS. Minimally, JS can be used for client-side validation. But that’s not necessary since the server needs to validate anyway.
by gorgoyel - > 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!)
by jakelazaroff - The whole idea of SPAs is just unfortunate most of the time. If you look at the list of the most popular websites:
https://en.wikipedia.org/wiki/List_of_most-visited_websites
Basically all of them can be decomposed to:
- List of comments/recommendations/pictures (sometimes in a tree), virtualized and lazy loaded
- A video
- A comment box
The irony is that this is super easy to represent in HTML semantically (HTML was literally made for this).
The 'virtualized and lazy loaded' part should've been a HTML standard (or more generally, partial page updates, like when you submit a comment) and then we'd have basically very little reason to do Javascript at all.
The irony of React is that what it does is make a mess of HTML, and allows you to ship your own semantic model in JSON/JS which will then get unpacked on the client into some display HTML.
This is accentuated by the fact that React's support for virtualization is really quite poor, as it assumes that you have the 'state' in RAM, and you have to go out of way to use third party libs that can handle both partial state and partial display.
Edit:
Apparently I'm not the only one who thinks this, and Chrome/W3C seems to experimenting with something similar:
https://developer.chrome.com/blog/declarative-partial-update...
But this should've been a W3C standard in like 1999.
by torginus - As usual this discussion is people talking past each other because some people work on web sites and others on web applications.
React is great for applications, perhaps not as much for sites. I wouldn't know though.
by Scarblac - 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.
by afavour - It’s always such basic reactivity that their little script provides… completely misses the point of react, and honestly applies to almost no projects.by duxup
- Same, at least for smaller projects where I want some kinds of interactivity, but also a good static rendered page first and just the ease of writing, Astro+preact has been very nice.by matsemann
- Every time I see this kind of pet project I see whether they are addressing any actual issue of React or whether they don’t like React merely because it is popular. I especially look at whether they do state management or VDOM diffing differently from React. I find that if a project had done that, it is likely something the author was very proud of and was front-and-center. And there have been some interesting ideas in pet projects like using languages with macros so the build tool does part of the diffing. This one replaced VDOM with… nothing at all?by kccqzy
- > You will inevitably have some piece of functionality that's complex (say, a contact form)
And this is why it pays to just learn React. It's never been easier. A contact form is not that complex. React won. The LLM can author it pretty well at this point, probably better (and cheaper) than at least 50% of FE devs. Treating a "contact form" as a potential fork in the road in 2026 is just sad.
- I kind of agree but also
> what about X feature
To which I argue unequivocally YAGNI
95% of apps people 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.
by donatj - Why should a contact form mean complex functionality? You can do it in plain HTML, even - is that complex already? Because validation? Like that (Google, it's you) address checking unable to place my house in the right village? Like phone number validation forcing you to add a 0 where no 0 is required to call me? And don't start me on streets and all that, or middle names, or dates or or or. Validations of form inputs are almost always a stupid yak shaving exercise, yet here we are.by soco