[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.