This is going to come across as a rant, so I'll do my best to refrain from blaming any one project or source and just make a generalized statement.
From backend ORMs and headless APIs to frontend site generators, package managers, and build tools—it's a miracle any of it actually works properly in production!
Now the reason this really grinds my gears isn't just related to my particular project. In a purely cynical sense, what do I care? I'm getting paid the same whether I'm writing code or debugging it.
The path to correcting any sort of systemic problem is to first acknowledge it and then to define its scope with honest and sober reflection.
Wrong. You can hop the fence over to other programming languages, frameworks, and ecosystems, and discover that the tooling there is far more stable and usable over the long haul. I don't wish to turn this into a pitch for Ruby, but let's just say in my many years of extensive engagement with the Rails framework and related projects, I've never encountered the sheer volume of bugs, glitches, gotchas, and limitations which I encounter on a regular basis in JS land. And it's not just me…I'm in chat rooms and Twitter threads all the time where other folks are losing their minds over some latest craziness. All we can do is shake our heads and go take a walk or something to relieve the pressure.
So how do we fix this? Here's one suggestion:
Get off the off-the-charts hype machine, stat. Enough with hyperbolic statements like "this is the modern way to build the web" or "this gives you the best developer experience with all the features you need for production" or "write high quality, loosely coupled, scalable, maintainable applications the most productive way". (These are all real quotes, BTW.) The constant marketing is not only exhausting, it also feeds newbies a bunch of malarkey.
Start by being honest about what doesn't work as much as what does work. Warn people about building battle-hardened, production-level code on top of your buggy and incomplete foundations. Steer people towards other, better solutions—even other languages and frameworks—if you know your tool-du-jour isn't quite up to snuff yet. Slow down your progress on shiny new features and fix the features you've already shipped.
Label releases and techniques properly. It's perfectly serviceable to have something in alpha or beta state for quite some time, or to say a particular technique is probably only suitable for the stout-hearted with time to kill. Also, stop with the "old-school code" shaming. The world isn't going to end if you write something in a manner that's been proven to work for several years by now, rather than the "flavor-of-the-month" according to some code-school blog. We snicker at one person's
var or another person's
$.get to fix the fire extinguisher and meanwhile the house is on fire.
Again, I come from the world of Ruby—not perfect by any means. But we have a saying, MINASWAN, which stands for Matz-is-nice-and-so-we-are-nice. In other words, the creator of Ruby (known as Matz) is in most respects a pretty genteel fellow. So let's also be nice and help out our fellow developers, particularly the newbies. That doesn't just mean in terms of sharing ideas or providing education. It means the tools we build should themselves be pretty nice! Crappy code smell and lousy DX often gets called out in the Ruby community because we've been handed a high bar. Name your variables well. Reduce boilerplate. Use a small surface area for your API whenever possible. Cultivate well-organized codebases. Convention over configuration. Maximize programmer happiness. And so on and so forth.
Demand more stability.
Demand more clarity.
Demand more honesty and less marketing fluff.
Demand higher standards. (Heck, demand standards at all! The ecosystem churn around ES modules right now is driving even the top authors of frontend bundlers absolutely nuts!)
So I don't hate JS. I don't hate frontend engineering, and I don't hate Node. What I hate is developer tools with awful DX due to hacks upon hacks upon endless modules of widely-varying quality as a result of constant churn in "best practices" and what's compatible with what, where, when. I simply no longer have the patience to deal.
Thus I'm begging you—imploring you—if you build or maintain any tool in the JS ecosystem, pause for a moment and consider how you can reorient yourself around upping the long-term quality level of the tools you produce. And if you are a newbie, DEMAND your tools give you the quality you deserve. And if you do work on a tool that's actually pretty stable, fun to work with, and hasn't tried to take over the world with ridiculous claims—kudos to you! You're breathing rarified air. 😜