This content originally appeared on DEV Community and was authored by Jared White
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.
The ecosystem of JavaScript frameworks is almost unbelievably unstable. Yes, even now in the year 2021.
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!
Some weeks I spend literally hours debugging and researching all kinds of weird, arcane bugs or conceptual hurdles related to performance, hosting, payload sizes, full-stack architectural gotchas, and the list goes on and on and on. And it's not just me. I'm on a team that is in a constant mode of struggle and churn due to dealing with largely obvious issues related to the most popular tools for backend & frontend JavaScript (at least according to their massive star counts on GitHub).
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 thing that bothers me is how awful of an experience this is for people with far less experience than me. I've been in this industry for over 20 years. However, other people are attempting to get into web development this year. And they're being told in order to do so they have to learn X, Y, and Z tools…all JavaScript of course. The problem is if they run into major issues—and they do, believe me, they do—they don't know enough to grasp just how buggy and incomplete the tooling is. Instead, they think they must have just made a mistake, or simply haven't learned enough yet. The cognitive load required is staggering.
Or perhaps they haven't run into too many issues yet. (Lucky!) That's possible, because the vast majority of tutorials and examples out there for the top JavaScript frameworks are laughably simplistic. If I see yet another example of how to use a GraphQL query to pull a blog post from a headless CMS to statically render an article using a component tree built with You-Know-What.js, I'm going to rip my hair out of my skull. This isn't where any real-world applications of any reasonable size get tripped up. The devil is always in the details. The problems typically arise well beyond the scope of clickbait-y "Build THIS in 10 minutes" articles.
How Do We Fix This?
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.
We all need to start being forthcoming about just how shockingly buggy and incomplete most of the JavaScript tooling is across the board. Compared to what, you might ask? Maybe this is just an artifact of web development, period. It's the nature of the beast.
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:
Start Telling the Truth
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.
Feel the Users' Pain
This all mainly boils down to something we learn in the world of UX (User Experience) design—you have to feel the pain your users go through when they use your software. In the case of developer tools, developers are the users! That's why the term DX (Developer Experience) gets thrown around a lot now. The thing is, good DX isn't just some whiz-bang ooo, that's cool reaction to a new blog post. It's "how well will this work for me and my team over the next several years??!" In that sense, the DX of the JavaScript ecosystem has a lot to answer for. Sometimes you even see it in GitHub issue and PR comments: rude, curt dismissals of genuine problems people are having in the real world. RTFM is never the correct response to DX issues.
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.
The result of all this is I sometimes look at the bugs or issues with I deal with when using JavaScript tooling and my initial reaction is: this would never fly in Ruby. Developers would simply laugh and quickly move on to a better tool. I'm not saying this to prop up Ruby. I'm saying this to convince you that you need to demand more of your JS tools.
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!)
Stop putting up with the nonsense. The excuses have run out. How long have we had Node? How long has ES6+ JavaScript been with us? How long have we had other, more stable ecosystems to be inspired by?
Conclusion
You might conclude, after such a rant, that I hate JavaScript and just want to leave. Actually, I don't! ? There are JS projects I love which offer great APIs in my opinion. LitElement for example is one of the best developer tools I've ever used in any language. Native ESM support in browsers and modern CDNs like SkyPack are wildly exciting. I've actually written a Webpack plugin and found the experience enjoyable. In fact, unlike some fellow Rails devs I know, I rather like configuring Webpack. (Now who's the crazy one?!) PostCSS is a nifty Node project I benefit from every day. Shoelace web components are the bees' knees.
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. ?
This content originally appeared on DEV Community and was authored by Jared White
Jared White | Sciencx (2021-03-16T01:45:53+00:00) The Shocking Immaturity of JavaScript. Retrieved from https://www.scien.cx/2021/03/16/the-shocking-immaturity-of-javascript/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.