[ttfkam]

Well, React certainly has succeeded in increasing the client-side complexity, that's for sure. They seem to be making good inroads on increasing server-side complexity as well. Kudos to their contributions to excess CO2 emissions!

I have yet to see a React project with more than five contributors fail to turn into a big ball of mud within 18-24 months, requiring either a periodic rewrite or resigned acceptance of trudging through large volumes of mud to get anything done.

[satvikpendem]

> I have yet to see a React project with more than five contributors fail to turn into a big ball of mud within 18-24 months, requiring either a periodic rewrite or resigned acceptance of trudging through large volumes of mud to get anything done.

Not my experience at all, and I've been working with React for years. I've seen companies successfully transition to functional components from class components, all while maintaining years-long functionality. Just because you dislike React doesn't mean it's not successful.

[ttfkam]

I never said it wasn't successful; I said it had successfully increased complexity.

I am glad you are an experienced React developer. React needs more of you, because the vast majority aren't.

That said, I have little doubt your and your team's experience could implement with most other frameworks as well—frameworks with a shallower learning curve, just as much power, greater performance before reaching for useMemo(…) equivalents, and far far less boilerplate code.

But 100% correct: I dislike React.

[satvikpendem]

True, it does take more experience, but there are footguns in any language. Personally, having used Knockout, I see that signals are not the future, because I guarantee in 5 years, just as with Knockout and RxJS, there will be articles out on how signals create a spaghetti mess of code. So I'd rather take React verbosity if only because I know where the alternatives lead.

Now if there were a performant version of the core React philosophy like Preact is (or React with their upcoming Forget compiler) I'll gladly take it, but it seems that frontend libraries these days are trending in the wrong direction.

[solardev]

Well, I've yet to see any web project of that scale survive more than 2 years. What do you think would be a better stack with similar frontend interactivity?

(Genuine question, not being snarky)

[DigitalSea]

I have Aurelia 1 apps that have been in production since 2015. They don't need to be really touched. But, when they do, they're really easy to modify. I am currently using Aurelia 2 and will have similar scalable apps that will be in production for years to come too.

[solardev]

Hadn't heard of this one, and checked it out just now. Seems interesting. Thanks for sharing!

[ttfkam]

I have seen Angular projects last pretty long avoiding code entropy. Angular is opinionated, rigid, and verbose, but goddamn if that structure and predictability don't pay off in the long term.

[solardev]

I'd love to investigate that, honestly. I loved Angular v1 (Angular.js now, I think?) and even that was way cleaner and more opinionated than React.

I haven't tried modern Angular in a while. But Next.js reminds me of a lot of the things I loved about early Angular and disliked about raw React (which always was more of a UI lib than a proper framework). Have you tried comparing them in particular?

[ttfkam]

My most recent use of Angular on a project is using v13 at the moment. I've been doing more infrastructure work lately, and Angular's build times—and bundle sizes—have been a persistent sore spot for me. I keep eyeing v16 jealously since it uses signals, builds A LOT faster, and removes some more boilerplate code in components, and the output assets are pleasantly smaller.

I haven't tried Next.js myself though a coworker was playing with it recently. The amount of components available for React, especially the for-pay libraries, can really decrease time to release. But it's still React. Builds a little slower than Angular 16 at this point, but it's fairly close. You still need to keep a firm hand on the codebase when working on a team to prevent code enmuddification, though less so than plain React. React's (what I consider) extreme amounts of boilerplate for doing anything of consequence is still there though. I also personally prefer Angular's service injection patterns over Reacts explicit imports everywhere.

I'd give them both up in a heartbeat for SvelteKit if I could make a business case for either rewrites or new projects. As it stands, Angular is really good enough and fights code entropy well enough that there isn't a business case there yet.

[solardev]

Cool. Thanks for the endorsement! Maybe it's time to build a hello world in modern Angular and SvelteKit and compare both to Next.

[ttfkam]

Would love to hear about your experience!