I am overjoyed for the Node community
The Node community has hit a huge moment in its growth, and I couldn't be more excited for it as an outsider looking in. It's certainly dark times for Node devs as many of them sort through the issues arising in their own applications after one prolific developer rage-quit and pulled all of his code from the Node Package Manager after a spat with the Kik product team. Many Node developers relied on those packages being part of the NPM infrastructure, and the lack of a tested, readily available alternative that offers the same ease of use makes this abrupt change harder to bear.
Developer pundits, of which I am sometimes one, have jumped on the question: have we forgotten how to program? David Haney writes:
I can’t help but be amazed by the fact that developers are taking on dependencies for single line functions that they should be able to write with their eyes closed. In my opinion, if you cannot write a left-pad, is-positive-integer, or isArray function in 5 minutes flat (including the time you spend Googling), then you don’t actually know how to code. Hell, any of these would make a great code screening interview question to determine whether or not a candidate can code.
It's a totally valid question, and it got me thinking about the growth of the JavaScript community in the years I've been coding.
Most of the young engineers I know who have started coding in the past five years or so started with JavaScript. Codecademy opened the door for folks who wanted to take a crack at code without much experience, Khan Academy offers its basic algorithm classes in JavaScript, and designers everywhere have begun dabbling in JavaScript to start adding basic functionality into their prototypes. For the longest time, though, JavaScript was just a weird language of dubious syntactic choices that lived in everyone's browsers but nowhere else. Then Node.js changed the game. You could start your career tinkering in the browser with JavaScript, but once someone told you that you needed to do something "on the server," Node was right there! And there was even a helper library to do all of the server-side web work for you! The world of JavaScript began to take over the Internet, and laws were even coined that indicated that everything would one day be written in this quirky browser language.
When a technology becomes that huge that quickly without a lot of experienced oversight, it's tough to figure out what the best practices are supposed to be. It's not a JavaScript developer problem; this same heavy reliance on a set of core dependencies hit the Ruby startup community a few years back. Thousands of sites were suddenly exposed and vulnerable and patched almost instantaneously. How did the Rails community know how to develop a patch and roll it out as quickly as they did? It wasn't something innate that they were born with. The Rails community had many of the same youthful problems that the JavaScript community is now struggling through. But they had learned how to sustain and endure after suffering through another embarrassing bug when Egor Homakov hacked GitHub the year before. They had learned that things could go horribly wrong, and they had learned how to respond when they did.
I look at the history of the Rails community and see so many parallels to the Node community. I look at the response to the Azer/NPM mess and think that the community is taking the right kind of look at its own problems and quickly devising ways to solve them. That's got me all sorts of excited because there truly is nothing like the JavaScript pipeline for introducing new engineers to code on both sides of the client/server divide. These war stories will help new developers learn best practices that are rarely codified - things like dependency management, over-reliance on dependencies for simple tasks, and that a single failure point can ruin your entire application even when you did nothing wrong but follow instructions.
Thanks to Andrew McGill for reading this and providing feedback.