ZH version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
60% Positive
Analyzed from 2336 words in the discussion.
Trending Topics
#react#mode#need#author#html#don#https#immediate#framework#doesn
Discussion (73 Comments)Read Original on HackerNews
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.
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.
> 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.
- https://macharchitecture.com/
- https://www.sanity.io/studio (a possible example)
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...
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
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.
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!)
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.
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.
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 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/
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.
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.