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 a day ago | parent | next [-]

> 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 a day ago | parent | next [-]

    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 a day ago \| parent [-]
		Offline mode exists for SPAs. And TUIs aren't realistic because the nurses use Ipads.

▲ DANmode a day ago | parent | prev [-]

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 a day ago \| parent [-]
		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.

▲ a day ago | parent | prev | next [-]

[deleted]

▲ holoduke a day ago | parent | prev [-]

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

	▲	pjmlp a day ago \| parent \| next [-]
		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)
	▲	jorisw a day ago \| parent \| prev [-]
		Something being 'made with AI' in no way translates to the framework used becoming irrelevant.