A few years ago, I came across a thought provoking article on the nature of the Javascript ecosystem, though it is unfortunately no longer available online.

The author discussed at length the idea that newer Javascript specifications — such then state of the art ES6 — made utility libraries such Lodash or Underscore into vanilla Javascript unnecessary and obsolete by introducing their key features, e.g. map, filter, and each type functions. He largely rejected the claim, and made some interesting observations along the way.

The article was thorough, and even included a Twitter poll asking respondents if they still used Underscore or Lodash; nearly three quarters of respondents answered that they used one of the two libraries frequently.

This shouldn't be surprising; libraries like this offer a standardized implementation of commonly needed features, rather than worrying about the vagaries of browser compatibility or the peculiarities of a particular Javascript engine. Moreover, many of the methods from these libraries have not been added natively to Javascript, and even when they have, the native JS versions often do less than their counterparts in Underscore or Lodash. For example, Underscore’s array methods (each, map, reduce, etc..) can operate on objects, while their vanilla counterparts cannot.

Bailey then raises a very intriguing point, which alone makes his article worth reading — citing a talk given about Coffeescript, he argues that libraries like Underscore or Lodash exist in relationship to Javascript, as a source for new ideas, improvements, and innovations:

*This presentation, for me, was the moment that CoffeeScript changed from something I would suffer through, to a language that I would respect for showing JavaScript the way forward.

And it’s in that same spirit that I now see Lodash and underscore.*

To me, this point cuts to one of the core strengths of Javascript and its ecosystem — its wealth of technologies and frameworks. Beyond simply offering more choice, these technologies cross-pollinate; there's the example of Lodash and Underscore influencing the development of vanilla JS, while frameworks like Vuejs incorporate features from React and Angular. The downside of this diversity is increased complexity, a greater number of parts and packages that have to be connected, and simple framework fatigue.

At the time I first read the article, I was just starting out in tech, and Javascript — particularly the Node ecosystem — was the main technological area I worked with. These days, I primarily use Go (Golang), which as a language is much more specialized in backend development, particularly in cloud environments.

The two languages differ in some key aspects. Javascript's core specifications are developed collaboratively, while Go's development is more tightly controlled. Unlike Javascript — with it emphasis on a diverse developer ecosystem — Go seeks to standardize and simplify developer behavior. As such, Go ships with a more robust standard library, with more functionality out of the box; the phrase "Just use the standard library" is the conventional wisdom within the Go community.

And yet I'm not sure how true that turns out to be in practice. While Javascript's ecosystem is massive and diverse, in a few key areas, you do see dominant players emerge: Nodejs is unchallenged for powering backend development, while Express is similarly dominant as a middleware package. For frontend frameworks, React, Vue, and Angular are the main choices. For storage, Node supports all major flavors of SQL, with knexjs as the ORM of choice, while MongoDB and Mongoose are your main options for non-relational databases. You don't have to use these technologies, and you have a lot of other options, but there is a fair degree of standardization.

By contrast, Go does not entirely meets its ideal of standardization in practice; several popular frameworks have emerged. It appears that many people need functionality that the standard library does not provide, and a firm consensus has yet to emerge. While Gin seems to be the most popular, it does not enjoy anything like the dominance of Node or Express.

It appears that Go's approach of actively promoting simplicity has partially produced a contrary result. Perhaps when a language is sufficiently widespread, there will always emerge a critical mass of users who want more than what comes in the box. Perhaps it also inevitable — or very common — that these users will want different, or want the same things implemented differently. And perhaps it's necessary, or simply very helpful, to allow these differences to play out, and let ideas compete, in order for a winner to emerge.

This is all speculation, of course, and I still love Go. Despite what I've written here, I think the language meets its core philosophy of simplifying the developer experience. I particularly appreciate how well thought out the language is, and how it's made to really fit its intended use cases. Still, I think these are are interesting issues to think about, and it's important to qualify or challenge your own points of view.