Avoiding a JavaScript Monoculture

JavaScript, as a language, has some fundamental shortcomings -- I think the majority of us agree on that much. But everyone has a different opinion on what precisely the shortcomings are.

Christoffer Petterson recently wrote that "JavaScript just needs to become a better language" -- about the shortcomings of the JavaScript standard run-time, and how this creates a culture of micro-packages and polyfills.

In this related opinion piece, I'd like to challenge that point of view:

Shortcomings of the JavaScript language and run-times are not the fundamental reason we have micro-packages or polyfills.

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

It seems there's a thriving mass delusion that we can somehow make JavaScript the ideal language for everyone and every thing.

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.

Continue reading %Avoiding a JavaScript Monoculture%

by Rasmus Schultz via SitePoint