[Udik]

In general, these posts sound a bit like this: I tried jQuery, and after a while it all became a mess; took up a Backbone project, and was good for a while, but eventually it became too complex; then I worked on Angular and that seemed a big improvement, but then... and finally with React my architectures are clean.

While the reality is more like this: I had 6 months of programming experience and used jQuery and made a disaster; with 1.5 years of experience I used Backbone and I fared better; with 3 years of experience I tried Angular and I was able to build a decent size application but ultimately shot myself in the foot; and now that I have 6 years of experience my software quality has improved a lot, it must be react!

[tom_walters]

Pretty much. It's similar to discovering the power of salt and pepper in cooking. When you first use it everything tastes better. But the next step is not to increase the amounts you use in every dish, it's to explore the much wider world of cooking with herbs/spices/etc.

If your mindset is persistently "this framework/tool will solve all our problems" you're always going to have a bad time. Understanding the pros/cons of each element is essential to becoming a good developer.

[AtlasBarfed]

It's almost like all "modern JS" are written by new programmers hired on the cheap by companies to work on their new hip UI frontends.

IMO UI is generally something new programmers like because of the visual/visceral "I built that", but once you get exposed to the sheer annoyance of UIs, programmers will migrate to backend.

So the most experienced people don't want to be constantly undercut in price by the incoming "talent", realize that WebUIs get chucked every 3-5 years anyway due to browser tech churn, and move to data monopolization.

[jokethrowaway]

This can be generalised to all software that is perceived to be revolutionary. Sooner or later a big company that wants to retain and attract engineering talents will arrive, with a horde or junior engineers led by an engineer looking to justify a promotion or to embellish a CV.

API generators had the same thing. Strongloop was a decent frameworks before they started throwing 10'000 juniors to fix issues and made a mess of the codebase. If you look at the jungle the React codebase is and you compare it with Preact (it's smart, concise and performant) you'll understand why code quality matters. And I'm not talking about stupid metrics.

[collyw]

The JavaScript world changes so fast that no one is ever going to be very experienced in the the they are using. I imagine that is partially to blame for all the crap we see in the front end.

[AtlasBarfed]

I agree, the JS ecosystem is reflective of constant new programmers redoing the UI every couple years, although I need to grit my teeth and admit that React did at least standardize/structure the ecosystem for the last few years.

[corytheboyd]

I’d just like to expand on this, as I think it’s a great comparison!

Carefully picking tools is important, but also, don’t adopt more tools than you need to.

One common example I have seen is pulling in a CSS-in-JS library to do something that SASS can easily do... when SASS is already incorporated into the build process.

SASS offers a fairly complex set of features if you care to learn about them, and the module system (in development) is going to solve @import global scoping issues very elegantly.

[toastal]

If you need something much less complex than Sass, but has a similar syntax to Sass (not SCSS), PostCSS + SugarSS has been nice for me. I really prefer indented syntax, and ever since CSS variables became readily available on my project support requirements, there's not been much reason to reach for Sass. A lot of people seem to point to the color functions, but I don't think a lot of people noticed Sass and Less don't do color mixing/darkening properly (they don't square the gamma before doing operations) so I wouldn't advise using these built-ins anyhow.

[mgkimsal]

I would change it a bit and suggest that after angular, they did react, and after 18 months of that it was too convoluted, but 'hooks' solved everything, and then 12-18 months after that, things are just way too complex, and they're now investigating svelte or something else.

I rarely see any decent architecture survive growth and real world use beyond a couple years. It's usually either 1) "no one could possibly have foreseen this new use case/requirement" (from less experienced folks) or 2) "YAGNI!" when trying to build in some abstraction levels to handle use cases you know will happen down the road.

[nkozyra]

In reality these often become the scapegoat for a need to refactor. I know refactor is a four letter word to some, but the truth is we grow as developers and architects and learn from our mistakes.

There's a tendency to blame the tools. You can build a big, high quality app in almost any language and framework.

[dangoor]

I disagree with the reality you present. There are a lot of people, myself included, with a considerable amount of experience who found that maintaining jQuery/Backbone code to be complex and error-prone and React presented a solution to this problem with a programming model that looks more like an immediate mode GUI (even though it ultimately paints to a retained mode DOM).

I don't think it's worthwhile to minimize the actual, useful impact React has had for web apps.