Rendered at 22:19:17 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
afavour 12 hours ago [-]
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.
donatj 12 hours ago [-]
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.
mexicocitinluez 10 hours ago [-]
> 95% of apps people actually develop are really just CRUD and could easily get by without JavaScript on the front end at all.
Nearly every app has some version of CRUD, but you're conflating the persistence model with the interaction layer. Just because an app is CRUD doesn't mean it doesn't require complex, client-side interactions.
I'm building an EMR and there is a large portion that is CRUD, but that doesn't mean I don't rely on enormous forms or don't need client-side validation.
And not only, but "you could get by" is true of a lot of things. I could get by with full-page refreshes every time a form is saved or a chart is pulled, but that doesn't mean it's the best option or that the users won't notice it.
This argument has big "I seldom build web apps but have a lot of opinions on them" energy. Like, the idea that I, myself, have seen enough of the different projects and use cases for the web that I can unequivocally state something like "95% of apps don't need a front-end framework" reeks of ego. You just flat out haven't. The field is enormous.
AlotOfReading 4 hours ago [-]
I'm building an EMR and there is a large portion that is CRUD, but that doesn't mean I don't rely on enormous forms or don't need client-side validation.
Another way to interpret the parent is that the site should degrade gracefully in the absence of client side scripting. Client-side input validation is valuable for an EMR, but best practice when I was involved in that field a decade ago was to avoid free form input entirely to minimize input errors.
My personal suspicion is that most providers would ultimately prefer a well-designed TUI from 1995 to a fancy SPA that stops working whenever the Wi-Fi is slow (i.e. most days).
mexicocitinluez 55 minutes ago [-]
Offline mode exists for SPAs. And TUIs aren't realistic because the nurses use Ipads.
DANmode 6 hours ago [-]
Maybe share a better example of a feature needing React than long, input-validated forms.
That’s not selling it. Just feels like what you’re used to doing.
mexicocitinluez 45 minutes ago [-]
I mean, when the bulk of your app is forms it pretty much justifies itself.
OP said:
> JavaScript on the front end at all
Nurses in my app have to complete 200+ question forms, on a tablet, in someone's home. The level of network chatter I'd need to have to pull this off would be too much. And I get a realistic offline mode.
And because I need accessible controls, something like React Aria becomes invaluable.
11 hours ago [-]
holoduke 11 hours ago [-]
95% of the frontend apps can easily be made with AI. Doesn't matter in which framework.
pjmlp 10 hours ago [-]
It matters when you use an headless CMS from the MACH architecture enterprise culture, and they only support a specific SDK, which is mostly Next.js/React.
Something being 'made with AI' in no way translates to the framework used becoming irrelevant.
kccqzy 10 hours ago [-]
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?
afavour 9 hours ago [-]
> Every time I see this kind of pet project I see whether they are addressing any actual issue of React
Then I think you're looking at those projects from the wrong angle. The point the author is making is that React is often used in situations where VDOM or complex state management aren't actually necessary. If all you're doing is e.g. validating a few form fields then neither is needed. But people use it anyway because React has become the default for frontend engineering no matter what.
godwinson__4-8 10 hours ago [-]
> 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.
afavour 9 hours ago [-]
> And this is why it pays to just learn React.
It pays you, the developer, yes. It does not benefit the user.
> A contact form is not that complex.
Correct, my example was not a great one, just the first one that came to mind. Using a giant JS framework to do something as simple as a contact form should be seen as a failure of development culture.
> Treating a "contact form" as a potential fork in the road in 2026 is just sad.
Choosing React as a one size fits all because it suits you as the developer, with little to no consideration about what suits the user... that's what is sad in 2026. But it's where web development culture is. There should be no "React won". There is no need for there to be one winner. As developers we ought to be able to tailor solutions instead of be lazy.
godwinson__4-8 9 hours ago [-]
SSG is solved for in React. The user is going to cope with a few extra KB of JavaScript just fine. Just like they cope when they watch Youtube or stream or w/e all day long. It's 2026. Data is cheap. The user really doesn't care until they hit your contact form that sucks because you tried to reinvent the wheel instead of just using React. Or when you need to branch out should your site ever do something actually interesting and this problem then gets even worse.
It's not hard anymore to get over the React learning curve. For a content heavy static site just use a good enough LLM and the right starter template and you'll never have to code, SSG and bundle size will just work, lighthouse will be all green. Your users do not care about the tech. The idea that React is the enemy of users sounds like a skill issue on your part. Good thing LLMs exist now, so you don't have to fret about the alleged perverse incentives. For a static site in 2026 a FE dev should be largely irrelevant. What could be more user friendly? Seems like big bad React has redemocratized the web right under your nose.
afavour 9 hours ago [-]
Data is cheap and fast, CPU time still isn't. I've profiled numerous web sites on slow Android devices and they absolutely crawl when parsing JS and giant JSON blobs required to hydrate a page that's one big React app for no real reason.
> It's not hard anymore to get over the React learning curve.
> The idea that React is the enemy of users sounds like a skill issue on your part.
You're contradicting yourself here. Is React incredibly simply to learn or is optimizing it for speed a "skill issue"? I'm not talking about myself here, I'm talking about the state of the industry. The web is full of slow-as-shit web sites that are held back by JS and JSON parsing. You don't need to convince me they aren't because I've seen it with my own eyes time and time again. As an industry it's become far more important to fart out basic functionality and move on than take any kind of pride in your output. It's sad and I'm not going to apologise for caring.
godwinson__4-8 9 hours ago [-]
> You're contradicting yourself here.
>> Good thing LLMs exist now
It's not a contradiction. You were/are unskilled. But it doesn't matter anymore. Just wanted to help you understand this is not a contradiction. You sound like someone who made your mind up about "the state of the industry" a long time ago. While this replay of debates settled a decade ago has been a nice, I must wish you a good day now. I don't mean to be too harsh. Ultimately you can use whatever tool you like, obviously. If it works for you then it works for you. Often that is what matters most.
Thanks for the trip down memory lane.
afavour 9 hours ago [-]
> You were/are unskilled.
You're being ridiculous and trying to bring personal insult into a conversation. I have, numerous times, asserted that I am discussing the state of the industry as a whole. I don't understand why you've repeatedly tried to misinterpret this, it's in extremely bad faith.
DANmode 6 hours ago [-]
> You sound like someone who made your mind up about "the state of the industry" a long time ago.
pfft: you wrote “React won” above.
matsemann 11 hours ago [-]
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.
lkbm 10 hours ago [-]
I switched my small personal projects to preact in a (temporarily successful effort) to get one under 14kb after re-reading [0] a year or two back. So far haven't run into any limitations.
If you need React, then go ahead and use React, but I'd encourage people to try a simple s/react/preact/g on their websites. (Okay, not quite as simple as that, but even if you don't like vibe coding, this is something an LLM can be trusted with.)
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.
jarek83 5 hours ago [-]
I triggered me as well. I keep seeing that for the front-end frameworks the native HTML regular stuff is usually like something out of this world.
11 hours ago [-]
torginus 9 hours ago [-]
The whole idea of SPAs is just unfortunate most of the time. If you look at the list of the most popular websites:
- 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:
But this should've been a W3C standard in like 1999.
Scarblac 4 hours ago [-]
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.
jakelazaroff 12 hours ago [-]
> 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!)
draw_down 11 hours ago [-]
[dead]
killerstorm 11 hours ago [-]
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.
gorgoyel 11 hours ago [-]
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.
killerstorm 10 hours ago [-]
I think main reason people choose React now is "nobody was fired for choosing React". (That used to be a saying about IBM as a vendor.) People can build their career around React.
And it is better "job security" than pure HTML+JS: React apps need constant maintenance
pjmlp 10 hours ago [-]
Another reason are SaaS and iPaaS SDKs having it as favoured stack, which kind of builds on your assertion.
DANmode 6 hours ago [-]
> React basically exists to give a “good enough” GUI toolkit functionality in the browser.
and it’s sole usage for so many apps is one of the top-five reasons, following 2010s SPA frameworks, that people believe web apps inherently suck.
norman784 10 hours ago [-]
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.
assimpleaspossi 9 hours ago [-]
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.
FeloniousHam 9 hours ago [-]
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.
Oras 12 hours ago [-]
> 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?
pedro_movai 12 hours ago [-]
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
blenderob 12 hours ago [-]
> 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.
12 hours ago [-]
inigyou 12 hours ago [-]
Nothing in HTML is immediate mode. Any framework with a DOM is retained mode, by definition.
pedro_movai 12 hours ago [-]
But the api is trying to simulate immediate mode using DOM
inigyou 12 hours ago [-]
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.
sroerick 10 hours ago [-]
Isn't that literally React? I find it so immeasurably funny that in his effort to simplify code and invent immediate mode UI, Casey Muratori accidentally invented React
Warwolt 12 hours ago [-]
How would you do layouting without a tree structure in place? Not really sure what you're getting at here
inigyou 12 hours ago [-]
You have discovered one advantage of retained-mode designs.
mollerhoj 12 hours ago [-]
"I think the author is saying"
- Wait, are you not the author? This seems dishonest.
gulugawa 12 hours ago [-]
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.
codazoda 12 hours ago [-]
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.
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.
It's not worth chasing except for personal curiosity and some truly extreme cases.
inigyou 10 hours ago [-]
The response needs to be. The response can span several packets, up to the maximum receive window chosen by the client's OS.
fidotron 10 hours ago [-]
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.
bryanhogan 12 hours ago [-]
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.
Scarblac 4 hours ago [-]
I feel the killer feature of doing everything in JS is components. I just want to import something from a library and use it.
Web pages have their code split between HTML, CSS and JS. There is no common story that works for all three except for using JS.
karol 11 hours ago [-]
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.
avsn 8 hours ago [-]
Re-creating minimal framework API is not that difficult. What is difficult is what frameworks are doing under the hood. To support ui=f(state) in the browser/dom you beed something more complex than pub/sub. The problems are 1. We need to calculate what part if UI depends on changed state 2.apply this to a dom efficiently. What author describes is a simple push-only reactivity which does not scale well because all updates are propagated to all subscribers. Libraries Solid and Vue (very simplified) are doing push-pull (push-pull-push) reactivity which involves traversing the dependencies for peace of the state, marking it as dirty and then recomputing the value of that peace of state. Another issue is DOM performance. When changing many parts of the state we want to apply changes to the DOM nodes in predictable and uniform fashion, avoid many writes/repaints, which usually involves some kind of scheduler. Another problem on top of that is measuring DOM before or after changes were applied (getBoundingClientRect can force synchronous layout/reflow, ResiseObserver is a more modern approach) and reacting to that.
Having said that I’m all for using solutions appropriate for the problem, but what many of such tutorials miss is a better problem statement. Yes frameworks are heavy, yes we may not need them. But problems with doing complex DOM manipulations are still there.
netdur 12 hours ago [-]
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
pedro_movai 12 hours ago [-]
Nice! positive comment
satnhak 9 hours ago [-]
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?
davexunit 9 hours ago [-]
Posts like this remind me how much JavaScript could benefit from something like Lisp's quasiquote. JSX is a terrible creation but templating in JS is pretty unpleasant without quotation operators. That said, I think Mithril's 'm' function did it the best of all libraries I have seen.
specialist 3 hours ago [-]
Yup. The Correct Answer™ was and remains Scheme. Acknowledged by all parties involved (and us baffled bystanders).
The negative consequences of JavaScript rival both \0x00 terminated strings and NULL.
I've never forgiven Brendan Eich or Marc Andreessen.
More positively, Marc did name the HTML's image tag IMG. Maybe by some cosmic measure, his contributions balance out.
Jaygles 6 hours ago [-]
If your job is to write UI frameworks, by all means do that
Otherwise, yes, you do need React (or something like it). Don't waste time re-solving the problems these frameworks were created to address. Spend your time creating value for your users. Building bespoke state management systems is not needed.
ChiperSoft 8 hours ago [-]
That useState hook doesn't work the way you think it does. It's going to reset state every time the hook is invoked on rerender. It also isn't triggering a render, which is the entire point of the hook.
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.
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
hsn915 12 hours ago [-]
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!"
gulugawa 11 hours ago [-]
The blog post page, which appears to use the author's library only loaded 58.6 kB of JavaScript, which is quite low.
vitaflo 10 hours ago [-]
Preact is 3kb. The size argument doesn’t hold weight.
onesandofgrain 11 hours ago [-]
React is popular because it's pushed by Meta.
crab_galaxy 10 hours ago [-]
React is popular because it mainstreamed components as a concept to modularize and reuse UI.
wild_egg 12 hours ago [-]
> 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.
pedro_movai 12 hours ago [-]
I think the author is referring to immediate mode because of
UI=f(state)
wild_egg 12 hours ago [-]
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
magicalhippo 10 hours ago [-]
If you compare the code using the presented framework to code using say immediate mode library like ImGui[1][2] for example, the presented framework does indeed seem to be exposing a retained mode API.
With that argument, every UI is retained mode because everything gets saved in the GPU's scan out buffer.
sroerick 10 hours ago [-]
Isn't React specifically an attempt to build an immediate mode UI on top of the DOM?
imafish 12 hours ago [-]
Maybe it’s not needed. But why not just use React anyway?
gulugawa 12 hours ago [-]
I read the blog post, and your framework looks great.
I think React is overused, and I'm happy to see people support alternatives.
Flavius 12 hours ago [-]
After looking at the code in the tic tac toe example I am now 100% convinced that I need React.
inigyou 12 hours ago [-]
React and systemd feel the same way to me: both really sensible ideas at the core, surrounded in layers of bullshit.
dbbk 11 hours ago [-]
What is the point of this?
huflungdung 13 hours ago [-]
[dead]
cyanregiment 10 hours ago [-]
You don’t need React until you do.
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
bofadeez 12 hours ago [-]
Discussing language preferences at all sounds very pre-Fable era
inigyou 12 hours ago [-]
Tell me, mister Bofadeez Nutz, why does every non-AI post have to have these dumb "hurr durr just use AI" comments?
jvidalv 11 hours ago [-]
I “agree” with your “sentiment”.
But I can’t shake the feeling that discussing this stuff is indeed void on the AI era. I considered my self a JS/TS/React expert dev, derivate, state duplication, url as a source of truth…
All of these points feel void now, I have not checked/cared how my React code looks like in months now. I only care about more high level stuff like schema definition and overall wiring.
bofadeez 11 hours ago [-]
You sound like me before I tried Fable.
phoghed 10 hours ago [-]
You sound like most people I know that only have a Claude subscription. GPT-5.6 is so much better bang for the buck.
inigyou 9 hours ago [-]
You sound like me after I tried Cocaine.
bofadeez 9 hours ago [-]
How many times have you abused cocaine?
inigyou 9 hours ago [-]
How many times have you abused fable?
bofadeez 7 hours ago [-]
You're saying you have abused cocaine as much a vibe coder enters prompts? I.e. you're just an ordinary drug addict who leaves 100s of comments a day and is not worth dignifying? Why would you want to advertise that and intentionally discredit yourself as a human being?
afavour 12 hours ago [-]
Framework, not language. And framework choice still matters.
orphea 12 hours ago [-]
So do programming languages, fwiw. The argument of "we have Fable, X doesn't matter anymore" is a severe case of delusion.
bofadeez 12 hours ago [-]
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.
bofadeez 12 hours ago [-]
Tomato tomato. English is my favorite new programming language.
afavour 12 hours ago [-]
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.
bofadeez 11 hours ago [-]
Have you tired using several billion Fable tokens in production? It will do whatever you want.
So you can still have your opinions on what works best. But it doesn't matter much, it's not 2025 anymore.
E.g. always use Rust instead of Python
inigyou 9 hours ago [-]
Ah. I see. A troll account.
That explains the 7.5 year account age and only 2 karma.
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.
> 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.
Nearly every app has some version of CRUD, but you're conflating the persistence model with the interaction layer. Just because an app is CRUD doesn't mean it doesn't require complex, client-side interactions.
I'm building an EMR and there is a large portion that is CRUD, but that doesn't mean I don't rely on enormous forms or don't need client-side validation.
And not only, but "you could get by" is true of a lot of things. I could get by with full-page refreshes every time a form is saved or a chart is pulled, but that doesn't mean it's the best option or that the users won't notice it.
This argument has big "I seldom build web apps but have a lot of opinions on them" energy. Like, the idea that I, myself, have seen enough of the different projects and use cases for the web that I can unequivocally state something like "95% of apps don't need a front-end framework" reeks of ego. You just flat out haven't. The field is enormous.
My personal suspicion is that most providers would ultimately prefer a well-designed TUI from 1995 to a fancy SPA that stops working whenever the Wi-Fi is slow (i.e. most days).
That’s not selling it. Just feels like what you’re used to doing.
OP said:
> JavaScript on the front end at all
Nurses in my app have to complete 200+ question forms, on a tablet, in someone's home. The level of network chatter I'd need to have to pull this off would be too much. And I get a realistic offline mode.
And because I need accessible controls, something like React Aria becomes invaluable.
- https://macharchitecture.com/
- https://www.sanity.io/studio (a possible example)
Then I think you're looking at those projects from the wrong angle. The point the author is making is that React is often used in situations where VDOM or complex state management aren't actually necessary. If all you're doing is e.g. validating a few form fields then neither is needed. But people use it anyway because React has become the default for frontend engineering no matter what.
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.
It pays you, the developer, yes. It does not benefit the user.
> A contact form is not that complex.
Correct, my example was not a great one, just the first one that came to mind. Using a giant JS framework to do something as simple as a contact form should be seen as a failure of development culture.
> Treating a "contact form" as a potential fork in the road in 2026 is just sad.
Choosing React as a one size fits all because it suits you as the developer, with little to no consideration about what suits the user... that's what is sad in 2026. But it's where web development culture is. There should be no "React won". There is no need for there to be one winner. As developers we ought to be able to tailor solutions instead of be lazy.
It's not hard anymore to get over the React learning curve. For a content heavy static site just use a good enough LLM and the right starter template and you'll never have to code, SSG and bundle size will just work, lighthouse will be all green. Your users do not care about the tech. The idea that React is the enemy of users sounds like a skill issue on your part. Good thing LLMs exist now, so you don't have to fret about the alleged perverse incentives. For a static site in 2026 a FE dev should be largely irrelevant. What could be more user friendly? Seems like big bad React has redemocratized the web right under your nose.
> It's not hard anymore to get over the React learning curve.
> The idea that React is the enemy of users sounds like a skill issue on your part.
You're contradicting yourself here. Is React incredibly simply to learn or is optimizing it for speed a "skill issue"? I'm not talking about myself here, I'm talking about the state of the industry. The web is full of slow-as-shit web sites that are held back by JS and JSON parsing. You don't need to convince me they aren't because I've seen it with my own eyes time and time again. As an industry it's become far more important to fart out basic functionality and move on than take any kind of pride in your output. It's sad and I'm not going to apologise for caring.
>> Good thing LLMs exist now
It's not a contradiction. You were/are unskilled. But it doesn't matter anymore. Just wanted to help you understand this is not a contradiction. You sound like someone who made your mind up about "the state of the industry" a long time ago. While this replay of debates settled a decade ago has been a nice, I must wish you a good day now. I don't mean to be too harsh. Ultimately you can use whatever tool you like, obviously. If it works for you then it works for you. Often that is what matters most.
Thanks for the trip down memory lane.
You're being ridiculous and trying to bring personal insult into a conversation. I have, numerous times, asserted that I am discussing the state of the industry as a whole. I don't understand why you've repeatedly tried to misinterpret this, it's in extremely bad faith.
pfft: you wrote “React won” above.
If you need React, then go ahead and use React, but I'd encourage people to try a simple s/react/preact/g on their websites. (Okay, not quite as simple as that, but even if you don't like vibe coding, this is something an LLM can be trusted with.)
[0] https://endtimes.dev/why-your-website-should-be-under-14kb-i...
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.
React is great for applications, perhaps not as much for sites. I wouldn't know though.
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!)
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.
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.
And it is better "job security" than pure HTML+JS: React apps need constant maintenance
and it’s sole usage for so many apps is one of the top-five reasons, following 2010s SPA frameworks, that people believe web apps inherently suck.
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.
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.
How this made it to HN front page?
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.
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.
https://joeldare.com/why-im-writing-pure-html-and-css-in-202...
https://joeldare.com/the-14kb-problem
It's not worth chasing except for personal curiosity and some truly extreme cases.
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.
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/
Web pages have their code split between HTML, CSS and JS. There is no common story that works for all three except for using JS.
Having said that I’m all for using solutions appropriate for the problem, but what many of such tutorials miss is a better problem statement. Yes frameworks are heavy, yes we may not need them. But problems with doing complex DOM manipulations are still there.
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?
The negative consequences of JavaScript rival both \0x00 terminated strings and NULL.
I've never forgiven Brendan Eich or Marc Andreessen.
More positively, Marc did name the HTML's image tag IMG. Maybe by some cosmic measure, his contributions balance out.
Otherwise, yes, you do need React (or something like it). Don't waste time re-solving the problems these frameworks were created to address. Spend your time creating value for your users. Building bespoke state management systems is not needed.
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
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
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.
UI=f(state)
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
[1]: https://pthom.github.io/imgui_explorer/
[2]: https://github.com/ocornut/imgui
I think React is overused, and I'm happy to see people support alternatives.
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
But I can’t shake the feeling that discussing this stuff is indeed void on the AI era. I considered my self a JS/TS/React expert dev, derivate, state duplication, url as a source of truth…
All of these points feel void now, I have not checked/cared how my React code looks like in months now. I only care about more high level stuff like schema definition and overall wiring.
E.g. Just always use Rust instead of Python.
So you can still have your opinions on what works best. But it doesn't matter much, it's not 2025 anymore.
E.g. always use Rust instead of Python
That explains the 7.5 year account age and only 2 karma.