Hacker News Reader

Comment by afavour | Hacker News Reader

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.

View on HN

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.

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.

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.

95% of the frontend apps can easily be made with AI. Doesn't matter in which framework.

Something being 'made with AI' in no way translates to the framework used becoming irrelevant.

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.

- https://macharchitecture.com/

- https://www.sanity.io/studio (a possible example)

> 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.

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.

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.

    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).

Offline mode exists for SPAs. And TUIs aren't realistic because the nurses use Ipads.

> 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.

> 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.

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.

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.

> 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.

> 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.

> 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.

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?

> 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.

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.

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.)

[0] https://endtimes.dev/why-your-website-should-be-under-14kb-i...

It’s always such basic reactivity that their little script provides… completely misses the point of react, and honestly applies to almost no projects.

Reply on news.ycombinator.com