LinLog

The other week, somebody posted this article by Jared White in one of the chats at work.  It decries the "shocking immaturity" of the ecosystem around JavaScript and Node.JS.

I mean...yeah.  But it's not like this is news.  The Node ecosystem has been messed up for years.  Remember the left-pad debacle?  That was five years ago.  It's pretty clear that the ecosystem was messed up then.  So I guess this article just tells us that not much has changed.

To be fair, a lot of the stuff Jared complains about isn't really specific to the JavaScript ecosystem.  I've also been in the industry for 20 years and I can say from experience that bugs and hype are endemic to most of the industry and have been for quite some time.  For example, in the early days of Rails, I remember seeing a million variations on the "build your own blog in 10 minutes with Ruby on Rails" tutorials.  And yes, that's fine, you can make a simple demo app in 10 minutes.  Whoop-de-doo.  In reality, what that usually means is that on a two-month project you've saved yourself...maybe a day or two at most.  There are lots of tools and framework in lots of language ecosystems that are grossly over-hyped - it's almost standard practice in the industry.

As for bugs, I can't speak to Jared's experience.  In any software ecosystem, bugs are obviously common and not mentioning them is almost de rigueur.  I mean, if you're developing a framework or library, of course you're not going to advertise the bugs and limitations of your tool.  You want people to use it, not be scared away.  But I'm willing to accept Jared's assertion that the JavaScript world is uniquely bad.  I know my experience of client-side JS libraries is...not fantastic in terms of reliability or documentation.  So while I'm not sure he's right, I wouldn't be surprised if he was.

I do think his point about the learning curve is interesting and valid, though I don't know that it relates specifically to bugs.  I haven't gotten deep into many of the fancy new JavaScript frameworks, but they do seem to be staggeringly complex.  I started working with JavaScript way back in 2005, when all you needed to do what save your code in a text file, open that file up in a browser, and see what it did.  It was extremely simple and the bar to entry was ridiculously low.  Then, a few years ago, I decided to try out React, since that's the big new thing.   Just to do "Hello, World!", I had to get my head around their weird template syntax, install a transpiler, and run some kind of server process (I don't even remember - maybe that's changed by now).  And when I saw that work, I quit because I had actual work to do.  It's hard for me to remember what it was like to be a beginner, but I can imagine that this kind of an on-ramp would be pretty daunting, even with the dumbed-down tutorials.  Heck, it seemed like kind of a lot to me, and I'm an experienced professional!

Honestly, I kind of wonder how much of the problems Jared is seeing stem from the "youth" of the JavaScript ecosystem.  I'm not talking about the language, of course.  I'm thinking more of the historical and cultural part of the ecosystem.  Consider:

1. While JavaScript has been around for a 25 years, it was widely considered a "toy" language for the first 10 years or so.  Remember - JavaScript came out in 1995, but jQuery didn't come along until 2005.  And these days, building your site on jQuery is the equivalent of building your house out of mud and sticks.
2. In the roughly 15 years of JavaScript's non-toy lifespan, there's been a lot of churn in the web space.  And during much of that time, it was considered important for many businesses to support legacy web browsers.  I remember many times having to stop myself from using "new" features of JavaScript because, well, we still have to support old versions of Internet Explorer.  Yeah, nobody cares about that anymore (thank God), but it wasn't all that long ago that they did.  Heck, I remember getting yelled at in 2015 because I forgot to test something in IE9, which was released in 2010!
3. From 1 and 2 above, it's clear that, in terms of the evolution of the ecosystem, the 25 year history of JavaScript is really a lot less than 25 years.  In fact, it's probably only within the last five years or so that we've managed to shake off most of the legacy cruft and get adoption of modern stuff beyond the handful of early-adopters.
4. On the cultural front, it's been my experience that a lot of young people these days get into coding through web development.  This is not a bad thing - everybody has to start somewhere and the web is a relatively accessible and popular medium.  But it's also my experience that a lot of the people who create open-source tools and libraries are younger, because they're less likely to have families and other obligations and hence more likely to have the free time.  Again, this is not bad, but it means that the people writing the tools are disproportionately likely to be less experienced.
5. So while there are plenty of things in the JavaScript world that are old enough that they should be mature, we can see from 3 and 4 that this might not necessarily be the case.  When a tool is developed by relatively inexperienced coders and hasn't been widely used outside a relatively small circle for very long, it shouldn't come as a surprise when they have some issues.

Of course, I'm just spit-balling here - I could be completely wrong.  But the point is that developing a stable ecosystem takes time, and the JavaScript ecosystem hasn't actually had as much real time to develop as the calendar suggests.  I mean, there's still a hot new framework coming out every other week, so it doesn't seem like the ecosystem has even finished stabilizing yet.  Maybe in a few years things will settle down more and quality will improve.

Or maybe not.  We'll see.  In the mean time, we just have to make do with what we have.