5 ms·

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 g

by afavour 2mo 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 2mo 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.
- deleted 2mo ago
  [deleted]
- holoduke 2mo ago
  95% of the frontend apps can easily be made with AI. Doesn't matter in which framework.
  - jorisw 2mo ago
    Something being 'made with AI' in no way translates to the framework used becoming irrelevant.
  - pjmlp 2mo 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. - https://macharchitecture.com/ https://macharchitecture.com/ - https://www.sanity.io/studio https://www.sanity.io/studio (a possible example)
- mexicocitinluez 2mo 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.
  - DANmode 2mo 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 2mo 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.
  - AlotOfReading 2mo 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).
deleted 2mo ago
[deleted]
matsemann 2mo 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 2mo 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.) [0] https://endtimes.dev/why-your-website-should-be-under-14kb-in-size/ https://endtimes.dev/why-your-website-should-be-under-14kb-i...
soco 2mo ago
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 2mo 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.
godwinson__4-8 2mo 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 2mo 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 2mo 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.
kccqzy 2mo 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 2mo 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.
duxup 2mo ago
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 afavour 2mo ago

donatj 2mo 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.

deleted 2mo ago
[deleted]
holoduke 2mo ago
95% of the frontend apps can easily be made with AI. Doesn't matter in which framework.
- jorisw 2mo ago
  Something being 'made with AI' in no way translates to the framework used becoming irrelevant.
- pjmlp 2mo 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. - https://macharchitecture.com/ https://macharchitecture.com/ - https://www.sanity.io/studio https://www.sanity.io/studio (a possible example)
mexicocitinluez 2mo 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.
- DANmode 2mo 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 2mo 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.
- AlotOfReading 2mo 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).

deleted 2mo ago

[deleted]

matsemann 2mo 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 2mo 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.) [0] https://endtimes.dev/why-your-website-should-be-under-14kb-in-size/ https://endtimes.dev/why-your-website-should-be-under-14kb-i...

soco 2mo ago

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

godwinson__4-8 2mo 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 2mo 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 2mo 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.

kccqzy 2mo 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 2mo 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.

duxup 2mo ago

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