> React is the worst JS framework except for all the others we've tried.

> React has its tradeoffs, but we got here after a long slog of other things that don't work.

I strongly believe it's because of trying to achieve the wrong goal with the wrong tool. So many websites could just be bare html pages and forms with just a sprinkle of JS for some interactivity, but they want to add JS for whatever reason.

If you can have a complete repo browser without JS (cgit), most web applications can survive without it too.

▲

hajile 5 hours ago | parent | next [-]

There are four culprits here and neither is due to JS.

First is the pursuit of polish. Each extra 1% in polish adds tons and tons of lines of code. If you want that level of polish on a non-SPA, you'll still have to add all that code then reload it one page at a time. I see a lot of these "bare HTML pages" and they are lacking important stuff like i18n/a11y/WCAG compliance. Try adding all that back in and you'll see your website bloat right up.

Second is bloated do-everything libraries. Ant, MUI, Mantine, or whatever else is aimed to be a superset of all possible website needs which means that the components you adopt have tons of features and bloat you don't need that slow down loading, parsing, and execution. Simply replacing that <Paper> component with a <div> and a few lines of CSS will get you the same thing you want, but will save you layers of unnecessary React components and sometimes a layer or two of unneeded DOM nodes as well that were added because the <Paper> component had weird interactions with some other component.

Third is manpower/experience. Many/most JS devs today (sad to say) don't actually know how to make that simple <Paper> component on their own. Those that do often skip it because they've got too much to do already. I've lost count of the number of teams I've seen where a bog-standard backend has 25 people working on stuff while the frontend team has 3x as many total lines of code (which are often times handling human-computer interaction issues the backend couldn't even imagin), but only 3-4 people to maintain it all.

Fourth is of course management. Designs on the backend change at a trickle while changes to the frontend arrive in a torrent. Understaffed frontend teams can't keep up with all the things shoved on their plate, so they usually can't optimize things even if they know how (eg, only a small percentage of SPA actually know/take the time to lazy load various parts of their apps to improve load time).

Fix these things and the SPA performance will improve drastically and almost certainly exceed BE templates with some jQuery spaghetti.

▲

bryanrasmussen 5 hours ago | parent [-]

>I see a lot of these "bare HTML pages" and they are lacking important stuff like i18n/a11y/WCAG compliance. Try adding all that back in and you'll see your website bloat right up.

having lots of JavaScript tends to make more WCAG problems, because you do interactive stuff that needs to be described. Having bare HTML and the accessibility that is required for that is not tending to bloat in my experience.

▲

hajile 4 hours ago | parent [-]

Users need interactive stuff. If your site isn't interactive and your competitor's site IS interactive, customers almost certainly will prefer your competitor.

When you try to chain that stuff across multiple backend-rendered pages, you get a whole other list of problems. If you need to track all the otherwise transient UI stuff on the BE, you have now created a whole mess of stateful APIs and turned horizontal scaling into a much bigger issue than it needed to be.

	▲	skydhash 2 hours ago \| parent [-]
		Users wants something that will help with whatever they want done. And the quicker, the better. Interactivity is nice, but I never seen anyone complains about multipages applications. > If you need to track all the otherwise transient UI stuff on the BE So don’t add transient stuff? You send a page or a form according to the URL, the user does whatever it wants and either request a new page or submit the form. Each page is standalone like activities in an Android app. Anything transient is taken care of on the client side.

▲

fishtoaster 6 hours ago | parent | prev | next [-]

Sounds like your argument is with SPAs, not React in particular?

▲

lambdaone 6 hours ago | parent [-]

SPAs are a monster that grew and grew; an idea that at first seemed like a clever optimization has generated huge and complex systems that are a nightmare to work with, and are bloated, slow and insecure.

Web components are the next big idea. I hope they have a chance to work.

▲

buzzerbetrayed 5 hours ago | parent | next [-]

> Web components are the next big idea. I hope they have a chance to work.

This comment could work equally well in any of the past 15 years. And for all we know, any of the next 15.

	▲	pjmlp 3 hours ago \| parent [-]
		Angular supports web components as first class, as do frameworks like Blazor. It is mostly the React crowd that dislikes them.

▲

onemoresoop 6 hours ago | parent | prev [-]

I hate spas everywhere too but if you needed to build one for valid reasons React is probably a good bet due to large ecosystem and adoption. I personally avoided React as much as I could and luckily I won’t have to have to work with it.

▲

pjmlp 3 hours ago | parent | prev [-]

Exactly, for most websites out there classical webserver rendering does the job pretty well. Even fancy animations can be taken care by pure CSS.