In this related opinion piece, I’d like to challenge that point of view:
While various shortcomings of the standard run-time library are the obvious, immediate reason for the creation of micro-packages, I’m going to argue that this point of view is actually obscuring a deeper, underlying problem.
As to opinions about the shortcomings of the language itself, or the standard run-times, it’s important to realize that every developer has a different background, different experience, different needs, temperament, values, and a slew of other cultural motivations and concerns — individual opinions will always be largely personal and, to some degree, non-technical in nature.
For me, the best answer to shortcomings of the language itself has been Typescript, but I understand that’s not everyone’s cup of tea. For one guy, it’s CoffeeScript, for another gal, it’s Dart, Scala, Go, Rust, and so on.
My point is this: the fundamental problem is neither shortcomings of the standard run-time library, nor is it any specific technical shortcoming of the language itself.
The real problem is our lacking willingness to embrace cultural diversity.
One Size Does Not Fit All
Initiatives such as ES6, while seemingly improving things, are actually a step in the wrong direction.
For instance, those who prefer classical inheritance may enjoy the addition of the class keyword, while others may reject it as conflicting with the idea of a prototypical inheritance model.
Again, this is all opinion-based, and due to the sheer number of developers who rely on this technology as their bread and butter, sub-communities and religiousness forms around patterns, anti-patterns, practices, de-facto standards, micro-packages, polyfills, frameworks, build-tools, etc.
Less Is More
The problem, in my opinion, isn’t technical in the first place — it’s cultural.
What we really need is not another iteration of the language or the run-times, but a liberation from the forced idea of a “universal” language and run-time.
In other words, we need to standardize things at a lower level. We need to figure out what we can agree upon, and steer clear of the personal and touchy-feely opinions about language details and run-time features.
We need to standardize the petri-dish and not the entire culture.
In my opinion, this means one of two things:
That leaves option one: reduce the scope of the problem. Simplify.
Ironically, what we’re doing today, is essentially the opposite: rather than reducing the scope of the problem, we continue to grow it, effectively increasing the number of details — and problems — for everyone.
Two Steps Forward, Three Steps Back
Despite initiatives like ES6 finally moving things “forward” for some (after far too many years at a virtual stand-still) the development of the language and run-times has actually moved “backwards” for others — and despite the immediate jolt of excitement that something is finally changing, the whole process pretty much remains at the same historical stalemate.
ES6 makes some developers a bit happier, and others a bit less happy.
But in the sense that it needs to be separated, by the umbilical cord, from the client and server platforms.
The elimination of what is arguably the biggest monoculture in the history of software development would mean that we, the community, could finally take charge of both languages and run-times, and start to iterate and grow these independently of browser/server platforms, vendors, and organizations, all pulling in different directions, struggling for control of standards, and (perhaps most importantly) freeing the entire community of developers from the group pressure of One Language To Rule Them All.
Our languages and run-times would be hosted and distributed by CDNs, rather than baked into our client and server environments, where they become risky and difficult to change — where every iteration takes years to agree upon, and additional painful years of polyfills and fallbacks while they propagate to browsers.
Attempting to please everyone, with one thing, always ends up being a trade-off that really doesn’t completely please anyone.
Standards: Good, Uniformity: Bad
Don’t get me wrong — standards are great. Uniformity is bad.
Anthropologically, we thrive because of our ability to adapt to different conditions and diversify ourselves. Our curiosity and eagerness to learn gives us perspective, and enriches us culturally. Developer culture, humbly, is part of that cultural wealth, and we need to embrace that.
Trying to force this one thing to work for everyone is the worst way to do that.
In conclusion, this was an opinion piece — and as such, of course, I welcome your opinion, and hope that this generates some thoughtful, constructive comments and not just flames ;-)
Using Redis with Node.js
By Ivaylo Gerchev,
Need fast data interactions in your Node app? Learn how Redis speeds caching, message brokering, sessions, analytics, streaming and more.
Build a Website with React and Tailwind CSS
By Shahed Nasser,
React and Tailwind CSS: a beautiful relationship! Learn how Tailwind frees you from writing CSS so you can focus on your React components.
React Fragments: A Simple Syntax to Improve Performance
By Antonello Zanini,
React fragments provide a simple syntax to group a list of HTML elements without adding unnecessary nodes to the DOM. Here's how.