By Rasmus Schultz

Avoiding a JavaScript Monoculture

By Rasmus Schultz

This article was peer reviewed by Tom Greco, Dan Prince and Mallory van Achterberg. Thanks to all of SitePoint’s peer reviewers for making SitePoint content the best it can be!

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.

Less Is More

JavaScript, by now, is ubiquitous enough to affect literally every programmer in the software industry — a software industry that isn’t historically famous for its ability to quickly and unanimously agree on, well, anything.

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:

  1. We standardize on a finite subset of JS (such as asm.js) — and avoid the endless struggle through future iterations of the JavaScript language, competing super-sets and transpilers, or
  2. We adjust our point of view, and agree to accept JavaScript for what it is, but start to think of it as a kind of VM for other languages.

The latter has already been explored, in some ways, for some years now — but at nowhere near the scale necessary to eliminate JavaScript as the language you must learn to live with, whether it suits you or not.

Despite a growing variety of languages that compile to JavaScript, the language itself remains the dominant language in both client-side and server-side eco-systems for web development. The idea of replacing JavaScript with languages that compile to JavaScript, has been explored, and for whatever reasons, it hasn’t really liberated anyone from JavaScript.

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.

In my opinion, a subset of JavaScript (asm.js or something like it) needs to happen at a much larger scale, and needs to become much more accessible and ubiquitous.

In my own somewhat radical opinion, in order for that to happen, the JavaScript language and run-time needs to be “deprecated”.

Of course, not in the sense that JavaScript needs to go away. I’m not insane.

But in the sense that it needs to be separated, by the umbilical cord, from the client and server platforms.

JavaScript needs to fly from its comfy nest, and learn to survive on its own, on equal terms with other languages and run-times. It’s time to grow up, kid.

If JavaScript were detached from the client and server platforms, the pressure of being a monoculture would be lifted — the next iteration of the JavaScript language or run-time would no longer have to please every developer in the world, but instead could focus on pleasing a much smaller audience of developers who love JavaScript and thrive with it, while enabling others to move to alternative languages or run-times.

This would better for JavaScript, and for every other language.

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.

Imagine a world where you can upgrade your application to the next version of JavaScript the same day it gets released.

Imagine a JavaScript that evolves to the needs of those who actually want the language — rather than becoming the lowest common denominator of opinions including those held by people who really would rather be using a different language.

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 ;-)

  • Andre Morgan

    Earlier on in the article I was admittedly taken back, but as I read on and put on a more objective thinking cap I have to say this is healthy discussion. Understanding that it’s way more strategically complicated than it sounds, the idea of CDN distributed languages and run-times is especially interesting.

    “Imagine a world where you can upgrade your application to the next version of JavaScript the same day it gets released.”

    To the quote above I say YES PLEASE!!

    Apart from the possibility of browsers being able to understand languages other than JS, the idea of browsers being able to adopt language updates in a more consolidated way is very pleasant thing to think about. Getting mainstream browser companies to ease up the fight for a competitive edge in areas like handling JS would be tough but there’re definitely some clear benefits to changing the current state of affairs.

    Thanks for the great against the grain post!

    • Rasmus Schultz

      Thanks for your comment – you make me wish I had dwelled more on the subject of CDN distributed languages, but your comment elaborates very nicely on that!

      • Thanks! You’ve got grounds for an interesting future post on that topic!

    • Dan Prince

      “Imagine a world where you can upgrade your application to the next version of JavaScript the same day it gets released.”

      But we already have this. The stability of JavaScript specification means we can use old versions of JavaScript as compile time targets for new versions. That’s exactly what Babel is!

      There’s no world in which you’d be able to upgrade to the newest version of your language without a compilation step, because the runtime is either going to be WebAssembly, or the minimized ASM style subset, mentioned in the article.

      Browsers wouldn’t be able to understand a languages that aren’t JS either. The compilers would be responsible for doing that. Sure, in theory you can distribute a Python compiler written in JS over a CDN, then evaluate Python in the browser, but in practice, get ready for megabytes of code, bloating your applications.

      • Rasmus Schultz

        > There’s no world in which you’d be able to upgrade to the newest version of your language without a compilation step

        Of course there is – a world in which compilation happens in your browser. You seem to be forgetting that’s already how Javascript works? What we’re talking about, is replacing the platform-specific, baked-in Javascript interpreter with one written in WebAssembly.

        And yes, Babel lets you roll out code written in the next version of Javascript – which I used as an example. So imagine being able to roll out any version of any language – that’s what I’m talking about.

        > in practice, get ready for megabytes of code, bloating your applications

        In practice, browsers would cache language implementations after downloading a gzipped WebAssembly binary once, from a CDN – so in practice, for sites that deploy and run Javascript using a WebAssembly implementation of the Javascript interpreter, there is no bloat.

        In fact, there is now less bloat, since we will no longer need to roll out entire browser upgrades just to roll out a minor change to Javascript.

        You could argue that there’s a theoretical risk of turning the web into a language zoo – that you could end up running six different versions of JS and Python and C# on the same page, at the same time, leading to megabytes of bytecode downloads for visitors that don’t have the binaries cached yet.

        In practice, I think you would see most sites electing the version of Javascript they need, and possibly one other language. Likely most sites would choose a stable version of a major language, whatever is best suited for their project and team, and visiting those sites, your browser would need to download a WebAssembly binary on the first visit.

        Some sites might choose a more exotic language, or might even just deploy native WebAssembly rather than source code in another language – in which case the net footprint of downloading a bytecode compiled application requires a lot less bandwidth than downloading the same application compiled to Javascript source-code.

        In practice, fetching a new binary won’t be something that happens for most users, on most sites, on most days – likely the update frequency would be the same or less than the upgrade frequency of browsers today; the upgrade frequency of browsers, in turn, would then be lower.

        I think the bandwidth argument is moot. In practice, the bandwidth situation might be the same overall, maybe slightly better, maybe slightly worse.

        • Dan Prince

          Yes, compilation happens in the browser, but JIT compilation for a heavily optimized C++ engine is really, really fast. Downloading a JS blob/WASM binary from a CDN that will then compile and run your arbitrary language code on the fly is always going to be significantly slower, both in terms of network latency and in CPU cycles.

          Application code would need to be compiled/interpreted after it had loaded, adding an additional delay and this would need to happen every time the page was loaded by a user. The other alternative is to write the code, compile to WASM with an open standards compiler, then deploy the compiled binary. Compilation only happens once and the code is ready for immediate execution when the page loads. You can upgrade to a new version of the compiler whenever you want and users never need to download anything other than the source.

          This concept of writing and deploying the interpreter with applications is already a reality and you can see it in things like Babel’s in-browser mode. There’s a reason this practice is regarded as a development-only. Damaging the user experience to improve the developer experience is never a good idea.

          WebAssembly and community-lead (pre-deployment) compilers solve this problem and they do it without sacrificing the user’s experience.

        • NZ

          After reading the article I really had no idea what you were talking about. It was all very upbeat and progressive sounding but I couldn’t catch any specific things. You wrote in such an abstract way.
          Now this comment clears some of that fog up, only to frighten me.
          I hope you know how preposterous it all sounds.

          – making the user download language (!) runtimes (bandwidth says hello)
          – caching binaries and running them on host (!) machines (security says hi)

          I won’t even continue the list.

          You say the web should be inclusive, but admit that there could be a “zoo” scenario.
          You suggest that every site could roll it’s own runtime and make the user download it just to display a webpage.
          Now how many webpages you visit each day? Imagine they each would require you to download a whole language runtime.

          We all know JS is not perfect but without some consistency it would be pure chaos and insanity.
          There are languages for a reason. You want to develop for the web -> js, android -> java, etc.
          The industry would fragment itself so bad it would shatter in days if this was allowed. You wouldn’t find a developer to maintain a project because every other site is written in different languages.
          You say the new standards is a step in the wrong direction, but what you suggest is we all fall off a cliff.

  • markbrown4

    Interesting post Rasmus :)

    I mostly disagree, one of the beauties of the web is that it’s built on tech that everyone must work with. If you know HTML, CSS and JavaScript you can contribute to *any* web app without needing to learn new languages. The explosion of frameworks has added complexity there for sure but you get my point, having a huge base of people that know JS is a powerful thing. If you write in a hipster language you’ll have to spend time upskilling new hires. For all of JS’s flaws it’s arguably the most successful programming language on the planet.

    • Rasmus Schultz

      Not every language that isn’t Javascript is a “hipster language” – being able to code in Java, C#, C++ or other mainstream languages, on the web platform, on equal terms with Javascript, in my opinion has the potential to make the web a lot less “hipster” than it is today.

      Forcing everyone to work with the same tech does not create harmony – we should be working to bridge our differences, rather than trying to eliminate them.

      The web needs to be inclusive rather than exclusive – diversity is a good thing and, in my opinion, the only thing that enables progress; monoculture creates stagnation, even if it does create a false sense of harmony and subjective beauty.

      • markbrown4

        Don’t get me wrong, I like hipster languages. I’ve just seen evidence to suggest the opposite is true – it’s when these other languages are used that creates disharmony.

        • maryo

          Both uniformity and diversity have their pros and cons. But the freedom or the ease of integrating a new language would make the web much healthier , more competetive environment I guess.

        • Rasmus Schultz

          It creates disharmony now, because other languages have to be shoehorned in by transpiling to Javascript, which makes other languages second-rate passengers, for one, by setting unrealistic expectations about interoperability with the “primary” language.

          I don’t believe you can force harmony by making everyone do the same thing.

    • maryo

      But I guess it’s primarily because of web browsers and the history of web. One is actually FORCED to learn JS and that’s why it’s so “successfull”. But OFC it has also it’s good parts you mentioned.

      • markbrown4

        I don’t feel forced to use any of the web standards, Java Applets, Flash and Silverlight offered some genuinely new ways to build web apps and have failed. If you were able to program in any language of your choice in the browser you’d still want to be able to use all of the web API’s available in js.

        Right now it’s possible to compile almost anything to js, there is no forcing any more apart from the community that you are working with.

        Other really good options already exist, the most successful of which seem to be those that have stayed as close to JS as possible. Personally, I really enjoy writing CoffeeScript but there’s so many people in the community that reject it – it’s seen as one extra thing to learn and a lot of people don’t like “new” things when they can already get stuff done in a language they’re familiar with. And that’s fair enough, I now see the benefit of a single language that everyone knows at least a little of.

        • maryo

          OK. Maybe we are not so forced to. Approaches like JavaApplets, Flash and Silverlight failed for a reason. The reason was not the language itself. And I think Flash actually didn’t fail. We should identify the reason and do it better.
          But the choice of a different language than ES5 comes with a price. It is not cheap. At least not now. Maybe the need for much better tooling is the worst price. The tools and development stacks are combined of hundreds of packages, it is mostly slow and not the most reliable. But it is still the best we have when ES5 does not fit.

          I love webpack or JSPM/SystemJS loader but it is partly a workarround. We need to go somehow further. The idea of CDN distributed languages sounds very interesting. Not sure it is the way though.

          Or… instead of baking this into the client – the CDN thingy. We could have a central repo of the languages following a standard you could install into a standardized HTTP2 server. The server could compile the code to the WASM on the fly (and cache it) using a compiler downloaded from the CDN. Then it could send the compiled WASM to the browser using HTTP2 server push.

          If we (i mean the community) focused on something like this instead of making ES6/7 possible everywhere…

      • mbokil

        I choose to use JS since I actually like it. The language has incredible flexibility but that flexibility can also lead to much chaos with undisciplined habits. Hardest part of working with JS is I inherit a lot of projects that are horribly unstructured like 2K lines of JS in an angular controller since the developer didn’t understand how to share data using a factory or broadcast messages. On the bright-side people pay well to fix those problems which makes me happy!

        • maryo

          I also like many of JS fundamental parts, it really is very flexible. Not sure how the web would look like if it was not so.

          “people pay well to fix those problems”
          Because it needs a lot of discipline you mentioned and skill to tame it and do it well they offer mostly good money. But it is also very hard to find an engineer who deserve it. And since there are not so many competent engineers who can do it well (and many of them come from a world of spaghetti jQuery – BTW I like even jQuery) then it sometimes leads to the long controllers you mentioned.

  • martinczerwi

    Particularly like the part about classes, and ES6 taking a step in the wrong direction. Though I appreciate many of ES6 new features, classes is one I’m not sure about. There was a lot of discussion, about JS coders taking detours to achieve class-like functionality with prototypes, or constructor functions (which then again get criticized, “new” becomes an antipattern). This has a lot to do with features you might expect in a language, depending on your background. And as a lot of coders use JS as their secondary language, a lot of workarounds appear.

  • Flynn

    Very interesting article. I agree with everything you pointed out. Being forced to develop in JavaScript has been a pain point for me for many years. There has to be a better way. Asm.js or webassembly may be the foundation for the solution to this problem.

    I enjoyed reading it very much.

  • Luis

    I agree on everything except on the pessimism. All that you say should be done, can be done today, and people are free to do it. We actually already have quite a considerable amount of languages that compile to JS, ready to be used.

  • Hardik Kansara

    Really good. Agree with this. Nicely explained.

  • Cory Brown

    How could this article dance so closely around WASM without actually mentioning it? WASM’s aim is dang near the premise of this article. It decouples the platform from the language, freeing up JS to be JS and gives the platform a byte sized :trollface: target for other languages. Eventually, even JS would compile to WASM.

    • nrkn

      I came to the comments to say exactly this – thanks

    • Rasmus Schultz

      Yes, I’m sorry about that – I meant to, but I was pressed for time and the article went out before I had a chance to update it. Either way, the same arguments and considerations apply to WASM, so you can do a mental search and replace with asm.js since WASM seems to be its logical successor :-)

  • Pijamoney Get Free Bitcoins

    Every big corp wants to get their hands on Javascript dominance with their own shitty bloated specs in order to divide and conquer the webdev world. Javascript ES5 is simple yet powerful, and good enough for any application these days.

    • Rasmus Schultz

      I understand you feel that way – but we don’t all feel that way. That’s really the main point of the article.

  • Sandro Pasquali

    “JavaScript, as a language, has some fundamental shortcomings — I think the majority of us agree on that much.”

    I don’t think you can make this claim, neither on the “majority” line (sources? data? explanation of scientific social study of all JS programmers over some number of years and contexts that irrefutably proves this?) nor on the claim of “fundamental shortcomings” as a language. That claim represents a key premise of your argument. You need to argue for it better, or your entire argument fails.

    I see that this article was peer reviewed, so I have to assume those words were carefully chosen — this is the very first line of the article so I would expect nothing else.

    I as well am slightly uncomfortable with how often the JS group is bending its royal eye navel-wise. They look forward often enough, but one hopes they will lie flat on their backs and rest, soon.

    JS is also a compile target, so it is very easy to use some other language to write code for the browser and other web clients.

    This passage is confusing: “Despite a growing variety of languages that compile to JavaScript, the language itself remains the dominant language in both client-side and server-side eco-systems for web development. The idea of replacing JavaScript with languages that compile to JavaScript, has been explored, and for whatever reasons, it hasn’t really liberated anyone from JavaScript.”

    This is a circular argument. It affirms the unjustified premise comprising this article’s first line — that everyone is trying to escape from JS because of its “fundamental shortcomings”. You need to think more about what the “whatever reasons” might be.

  • Brook Monroe

    “Our languages and run-times would be hosted and distributed by CDNs…”

    I find your faith in the network…disturbing. If the network were monolithic, that might work. It would be an all-or-nothing proposition, but it isn’t. Suddenly I’m faced with the possibility that I might have to try to load required libraries from multiple sources because one section of the ‘net is down because a router went south or some overzealous guy with a Bobcat forgot to check where the fiber was buried before digging in. (No, I don’t do server-side JS; Node isn’t a thing in my world, and while I initially thought it was a bang-up idea, now I’m not so sure after watching what’s happened as a result of it. That is a separate discussion, though, and I won’t be entertaining debate on it in this thread.)

  • Samarjit

    WebAssembly is exactly this it will enable evolving the runtime seperate from the language syntax. I feel pushing javascript to do something that better suits other languages is a stupid idea. Making one size fit all is a stupid idea. In my opinion we need a language which speaks the web language. A DSL perhaps. The fight is not which language is best, the fight is which language suits a particular job. Second problem with this article is that it says runtime be opensource language be opensource. all good! but it still needs a governing body it still needs dedicated people to look after it. Almost all opensource projects are actually having a company to give it momentum. Nothing really works for free. Where there is a hype community run to it, then they run after another hype. You can see while so many people like jquery, jqueryui library never really grew up. All opensource successful projects have a company behind it which does 70-80% of the hard work.

  • jamtr

    I can’t agree that evolution of the language is a step backward. So you don’t like that class feature? Don’t use it. I didn’t like `with` — it’s existence never forced me to use it. Everyone I work with finds the development of a module pattern, lambdas, and other consise syntax additions very positive to their productivity and enjoyment of the language. We use classes too, but mostly for their more expressive syntax in constructing prototypes. We don’t generally use “classical inheritcance” such as it is.

    The notion that the future is that lots of things should compile to Javascript is not at all in conflict with the evolution of the language itself. Typescript, Coffeescript, jsx, to name just a few very successful languages that compile to ES5 and ES6.

    You may also have noticed — we already live in the world where you can upgrade to the next version of Javascript the day it’s released. It’s called Babel. Transpiling isn’t something that the language evoluition will ever eliminate, as long as there’s such a thing as a browser version that wasn’t released in lockstep with the language itself.

    To me this is a manifesto about philosphy and nothing more. All the things you say you want, already exist, and seem in no way impaired by the parallel evolution of the core language itself.

    “ES6 makes some developers a bit happier, and others a bit less happy.”

    So far you’re the only one I’ve found who falls in the latter category!

    • rbrtsmith84

      Totally agree.
      I’m not sure disliking classes in JS or not is a matter of opinion. They are fundamentally not classes, they are just syntactic sugar over prototypes to make them look a little more like classes but have nuanced differences which only confuses. When developers write JavaScript then they should write in that language and not try to shoehorn patterns from other languages into it. I would never try to write functional style code in C#, I would use the tools provided by the language and if I don’t know them then I should learn them.
      Typescript isn’t great either again as it’s trying to introduce classical inheritance in, but also dynamic types is a feature of the language and not a bug. You won’t have any issues with types if your are writing your software using TDD – we we should all be doing anyway.

      • nickwalt

        I believe that you can use the functional paradigm in TypeScript – there is no restriction or requirement to use classes. You can just use prototypal inheritance and functional composition.

  • Sylvain Pollet

    Strongly disagree. This post aims to build walls and divide the JS community in ghettos, while the versatility of the language is a strength. There is no such thing as a monoculture in the JS community. On the contrary, JS is one of the most polycultural developers community because it is rarely the first language learned. I went to many JS meetups and conferences, and met very different profiles. People coming from Java, Python, Haskell, OCaml, or even C/Assembly for IoT projects. If there was a monoculture, then we wouldn’t have people constantly arguing between each other about things like proto vs classes. So all these arguments are actually a positive sign. I am so glad I have been able to move to imperative programming to OOP to event-driven to Functional Reactive programming, all this without having to change language. JS made me a better developer thanks to its multiple paradigms.

Get the latest in JavaScript, once a week, for free.