Will JavaScript take over the programming world?

Not if it surrenders its ubiquity advantage

Last July, I had to give an impromptu talk. What came out, much to my surprise, was roughly “JavaScript will dominate the programming world.” I didn’t say that JavaScript would dominate through sheer popularity – JavaScript may in fact top the list of languages disliked by programmers, because so many programmers use it as a strictly secondary language beside their preferred server-side toolkit.

Instead, I argued, as you’ll see in “Concentration,” that JavaScript would win by ubiquity, offering a solution that fit well enough in both clients and servers. While I still think JavaScript could indeed “fit well enough,” the winds have changed and JavaScript may be about to surrender its ubiquity advantage, as you’ll see in “Dispersion.”

Concentration: The Wrong Story

After decades of a Cambrian explosion, we may finally see a concentration in the use of a few programming languages and a corresponding decline of many others, leaving us with three main families of programming languages. (Remember, this story is wrong.)

C and its immediate relatives will always be with us, providing a thin abstraction layer just above the processor. Functional languages that trade off ease of use in favor of extreme reliability, scalability, and manageability will continue to thrive in a small but ever-more important space. The biggest changes, though, will happen to the currently diverse general-purpose languages.

General-purpose languages, the tools that programmers have used to quickly assemble programs without having to sweat the details of memory management and data structures, are approaching a turning point. There is nothing intrinsically wrong with Perl, Python, Ruby, PHP, Java, C#, or many others, and they will continue to be used for a long time. However, their growth rates are going to shrink dramatically.

What innovation could unseat those champions? It’s “The VB of the Web,” a language that was patronized and dismissed for over a decade. JavaScript may not have had much respect for a very long time, but it has two major advantages over all of its general-purpose competitors:

  • Ubiquity – it’s on practically every computer sold today, somewhere, and any programmer who’s gone near the Web has at least thought about it.
  • Power – the JavaScript renaissance continues to demonstrate that this language is extremely capable, especially in the ever-growing number of cases where asynchronous communications are necessary.

JavaScript snuck in. For a long time, “write once run anywhere” was supposed to mean Java, with its armies of virtual machines for every platform. The browser was just a window onto a server-based world, with JavaScript providing a few key features on the client. As developers realized that the Web was the easiest way to create user interfaces for shared data, more and more programming activity shifted away from ‘classic’ GUI implementation to building web applications. As more and more Java development fell back to the server, JavaScript solidified its hold on the client.

While the Dynamic HTML boomlet of the late 90s vanished into the dot-com bust, Ajax returned JavaScript to prominence in 2005. Douglas Crockford’s JavaScript: The Good Parts made it clear that JavaScript was a first-class programming language, even if its take on objects was unconventional. Growing demand for more desktop-like user experiences led to massive growth in JavaScript programming, with more processing happening in the browser. That often (though not always) led to simplification on the server side.

Having achieved ubiquity as THE language (pretty much the only language) for client-side web programming, JavaScript is now poised to take over the server as well. It is not just possible to program the server-side components of a web application in JavaScript, but JavaScript has certain key advantages other languages can’t compete with:

  • JavaScript’s years of use in interfaces created a dominant callback style that works efficiently in pretty much any asynchronous communications situation.
  • Browsers now run on an incredibly wide variety of devices, from cellphones with slow CPUs and lousy bandwidth to speedy machines with lots of bandwidth. Using JavaScript lets applications decide where they want the code to run, and new frameworks (notably but not exclusively Mojito) can decide based on a given situation whether JavaScript should run on the client or the server.

It is probably possible to create a language with as much support for async as JavaScript, and a better syntax. It probably also makes sense to compile that language to JavaScript, as both CoffeeScript and Dart do.

The second advantage is much, much harder to overcome. It’s certainly possible for something like GWT to compile Java to JavaScript, but it’s a difficult thing to sustain. RJS (Ruby compiled to JavaScript) became a dead end pretty quickly. JavaScript may be a great target for compilers, as CoffeeScript and Dart are demonstrating, but those languages typically retain many of the restrictions and values of JavaScript.

The JavaScript community itself is evolving to support these new possibilities. Node is the hot and new server-side environment (complete with surprising support from Microsoft), but perhaps more importantly it’s spawning an ever-growing number of extensions and frameworks. Most of those are small pieces, but “full-stack” frameworks, notably Meteor, are emerging to cover the entire range of tasks from querying databases to helping users interact with that data.

Wait five years, and there won’t be much good reason to use other languages to build web applications. Wait ten years, and you’ll see applications written in other languages migrating to JavaScript because of the enormous ecosystem it’s building. Because so many programmers use JavaScript at least “part-time,” it’s not hard to find programmers for JavaScript projects. JavaScript’s lack of a corporate master, a difficulty in its early years, gives it an advantage moving forward because users don’t have to fear corporate agendas.

Other languages will probably not go extinct, but it will be much more difficult for them to grow. My suspicion would be that they find smaller niches, with Python perhaps holding on in the sciences, Ruby in experimental development, Java and C# in some corporate systems, and Perl in text processing and data munging. They will all still be good at what they do, but will face sharper competition.

I was, of course, wrong.

Dispersion: A More Likely Story?

I no longer forecast JavaScript taking over the general-purpose language space. It’s not because polyglot programming is more fun or even more powerful for most cases. It’s because I was wrong about the side effects of compiling to JavaScript.

When I first told this story, compilation to JavaScript was exciting but tricky. It was spreading from GWT to Dart to ClojureScript to CoffeeScript, but it seemed likely to always remain special purpose, buffering a larger shift toward JavaScript but incapable of slowing down a growing shift.

Over the last few months, though, I’ve been surprised by continuing conversations about JavaScript as a new assembly language – certainly more approachable than my distant memories of 6502, but similarly flexible. Asm.js broadened that conversation dramatically. While I remain uncertain that it will be the one true approach, it makes it very clear that the compilation approach can be more generic than I had thought possible.

Compilation approaches mean that “the JavaScript way” will no longer be the only way to do things in the spaces where JavaScript currently dominates. This frees developers who didn’t especially like the JavaScript way to work with approaches that are more comfortable to them. Even developers who are fond of JavaScript may take the opportunity to experiment with something different as toolsets grow and it becomes easier to do.

The Cambrian explosion I mentioned earlier may be returning, to JavaScript itself. Asm.js and related work moves programming another layer up the abstraction stack. Our processors seem capable of handling the known inefficiencies, and our toolsets seem prepared for another bout of rapid evolution.

Related

Sign up for the O'Reilly Programming Newsletter to get weekly insight from industry insiders.
topic: Web Platform
  • Tim Caswell

    Well written. Interesting times for JavaScript to be sure. Having been a node.js contributor since the very beginning and having one of the DHTML companies that went bust in the first bubble, I’ve seen all this play out.

    I don’t know what will happen next. I do hope that this second “Cambrian explosion” happens because I love exploring and experimenting. I worked on coffeescript years ago and am still working on my own language.

  • http://twitter.com/DALDEI David Lee

    I agree with the conclusion. JavaScript as the Assembly of the future, or maybe the C of the future is how I see things. The adoption and architectural and philosophical evolutions are nearly identical to what we’ve seen over 50 years, from machine code to macro assembler. From assembly to Fortran to C. From C to C++ to Java to .NET. From Java to the VM languages like Scala, jRuby etc. I know very few people now who consider themselves JavaScript developers who actually write bare JavaScript only. Instead they use high level languages like jQuery. In the near future I predict they will drop JavaScript entirely as easier and more powerful languages compile to JavaScript. Enterprise development is hard to do in pure JavaScript the same as it was in Assembly, the lack of features for large development like namespaces and packages make big programs hard to write and maintain.

    I personally have enjoyed GWT recently. Why would I write JavaScript when I can write in Java instead and have it compile down and optimized to the browser more efficiently then I can do by hand ? For the same reason I rarely write assembly … there’s no point. JavaScript is not going away any more then the x86 instruction set is going away but its going to lose the surface area.

    Thats my prediction atleast

    • Eric Elliott

      1. Namespaces are ugly. I don’t miss them.

      2. We have packages and modules. Serious JS developers rely on them heavily.

      3. Is there any language where libraries don’t play a big part? JS is certainly not unique in that regard.

      Some people prefer Java. I used Java a lot early in my career. Frankly, the idea of going back to it is not appealing. It’s nice that you can make that choice though, if you like.

      • Tony Stark

        “2. We have packages and modules. Serious JS developers rely on them heavily.”

        This isn’t accurate. JavaScript doesn’t even have a simple “import” statement let alone any degree of modularity or namespace support. We have been working with feature-rich Javascript frameworks and libraries for a few years now. It quickly becomes a nightmare as your codebase grows. We cannot rely on IDE tools (which would greatly boost productivity and eliminate common mistakes) due to the time it takes for the IDE to dynamically introspect the code. Furthermore, not even the best JavaScript IDE gets it right, so it’s broken anyway.

        What you are describing is a hack for an archaic language. We would be better served as web developers moving to Scala, or another fresh language designed for the modern web. JavaScript wasn’t designed for the modern web, it hasn’t undergone any significant improvements for over a decade.

        • Eric Elliott

          npm is one of the best package management systems available anywhere, and you can use node-style modules and require on both the server in Node.js, and the browser with browserify.

          Modules are coming to ES6, as well. Browserify already has an ES6 module adapter.

          AMD exists too, but I agree with your assessment of that technology. There’s room for improvement.

          As for IDE’s, Adobe Brackets has pretty good code intelligence built-in, and the support for it across Node-style modules is a high priority for the team. (It may be done already).

          More IDE’s will adopt that kind of support, soon. And when ES6 drops, count on all the major editors and IDEs to incorporate support for native modules.

          Your description of JavaScript as an “archaic language” isn’t accurate. It has or is incorporating most of the great features available in any modern language.

        • Stephen LeMaitre

          Let’s face it, up until recently, most people used JavaScript inline to do image rollovers… it isn’t like people have been building serious JavaScript applications for very long.

          In fact, much of the debate over JavaScript comes from people in Object-Only languages, such as Java and C#, which don’t understand the object model of JavaScript at all.

          This can easily be seen once they really start to program JavaScript… they will try and emulate the same Object style they are used to in JavaScript, and will end up writing 10x the code they need to to get the job done.

          As for “JavaScript wasn’t designed for the modern web, it hasn’t undergone any significant improvements for over a decade”

          This is both ignorant and completely incorrect, and this statement could only be made by someone that hasn’t been watching JavaScript for the last decade.

          JavaScript is directly absorbing its major libraries (such as inheriting querySelector() from jQuery)… a move that allows JavaScript to develop itself directly towards tried and true ‘best practices’, while simultaneously lowering browser load impact and performance issues.

          jQuery, a long time staple of JavaScript development, is now often being more or less used as a shim for older browsers where the more modern techniques are not supported.

          In addition to this, it is rapidly adding new features, such as Web Sockets, Web Workers, blob and data-url support, native parsing of JSON, improvements to the AJAX model, the addition of typed and clamped arrays, the list goes on and on and on… just take a look at the LONG list of features included on caniuse.com, and realize that this list is still incomplete.

          Simply the fact that this feature set is only fractionally supported, despite constant effort and improvements from browser makers, should be a solid indication of exactly how quickly JavaScript is evolving.

          Even the very structure of the language is growing… such as the use of defineProperty, which allows properties to include actual getters and setters (very similar, in fact, to C#), but to allow these properties to be finalized in various ways.

          This allows developers from the standard OOP languages (such as Java and C#) to be able to pull their programming patterns directly over to JavaScript, yet does so without ‘rewriting’ JavaScript.

          This means that rather than limiting JavaScript to the Object-Only model that Java follows, we are able to include Object Orientation (with the benefits of prototypical inheritance), *AND* keep the functional nature of JavaScript whole.

          I find it significant that JavaScript is doing this while simultaneously rapidly increasing performance of the language as a whole. JavaScript is currently about as performant as Java is in the browser; itself a drastic improvement from a decade ago.

          Then there is the development of Node…

          You claim that there have been no significant improvements in JavaScript over the last decade? I humbly request for any major language that has developed more quickly and improved this much in that same time frame.

          More importantly, JavaScript is developing in the correct ways… towards cleaner, more powerful, more performant, and more standards oriented code, and by following the coding standards and practices that JavaScript developers have formed themselves through rigorous testing in the real world.

          I would predict that as soon as Node starts showing signs of maturity, we will see numerous well designed, highly performant IDE’s… most likely on the cloud rather than the desktop, due to the nature of the language.

          For a preview of what this looks like, take a good solid look at Cloud9 ( c9.io )… while you can code nearly any language in it, it was designed specifically for JavaScript and the Node environment; it has extremely useful features that I have not seen in any other IDE (such as multiple cursors, and quick automated deployment to a number of different types of server).

          Finally, as for the OP?

          I agree that ASM.js part of that future.

          In my mind, very soon you will be able to code in JavaScript on the back end under Node, on the front end under JavaScript in the browser (no difference in language, here, just environment) *AND* include precompiled code in the form of ASM.js (which, in fact, is still simply JavaScript).

          This type of work has been done forever… for example inserting Assembly into C++ or C# code… except in this case, its simpy a special case of the same language.

          That’s JavaScript ^ 3.

          However, JavaScript also has something neither of the other two can claim… an extremely powerful, flexible, cross-platform, and standards based GUI library… called HTML5/CSS3.

          C# has .Net, which is very powerful, but is proprietary and far from being cross platform… and building a Java GUI has always been a mess.

          Personal prediction? JavaScript will quickly replace Java…. and deserves to.

  • Stephen Lum
  • Rob Ludwick

    If javascript is thought to be the Assembly language of the future, just don’t become disheartened when it gets treated like the Assembly language of today — say like what the JVM did to Assembly.

  • Sandro Pasquali

    You are of course right to recognize that Javascript is the language to watch. To follow your imagery, the primordial moment was when the DOM became programmable. Unfortunately most were unable to see the implications (the content delivery system for internet-based software was born).

    It’s unclear why you’ve been scared off of this belief (though it is humorous when someone makes a long-term prediction, then changes the prediction less than a year later — credibility is important). It seems to be Coffeescript. That’s the wrong reason. CS is at worst benign.

    The primary threat to JS are Google and Microsoft, who want to profit by fragmenting a consistent development environment with “improvements” to a problem they still haven’t succeeded in creating: making internet programming a babel. Once that happens, tools and services to “fix” this problem will arrive. Stop supporting this FUD.

    Similarly at fault is the analytical mistake amateur drifters from the dying language worlds make: that JS isn’t an “enterprise grade” language because of (insert your favorites — no OO, no static typing, no modules, etc). A deadly cocktail of ego (JS is easy, so I can claim to be an expert after a weekend with it) and dated software development theory is confusing the clarity of the modern development world like pepto-bismol dropped in a glass of cool clear water by a drunkard. It will fizzle and die.

    JS isn’t about syntax — it represents a revolution in thinking about software development. You must encourage prototypal thinking (which is closer to the way humans actually think), the event-driven model, dynamic typing, closures, single-threaded safety, function-focus, and other beautiful aspects. You need to think very hard about why JS has succeeded. It isn’t the existence (or lack of) curly braces.

    • Simon St.Laurent

      It’s not so much that I’ve been scared off my prediction as that the prediction was based on JavaScript’s ubiquity driving use even in places and with people who might otherwise want to choose something else.

      JavaScript can indeed be a beautiful language. That has helped its path to stardom, but it hasn’t driven it. JavaScript has thrived because of its unique relationship with web browsers, both benefiting from their spread and accelerating their spread. It has had the unique advantage of the easiest application distribution process out there.

      However, while JavaScript is both ubiquitous and powerful, it suffers from fragmentation. That fragmentation isn’t the vendors you worry about, or deep splits in the language. The fragmentation is in the developer communities using it. For many people, JavaScript is a second language, and a reluctant second language at that.

      I love prototypal inheritance, but you are right that it is a revolution, and people tend to resist revolutions. GWT was a an early sign of people going well out of their way to avoid having to rethink how they write code. CoffeeScript is a less drastic alternative (as is TypeScript). Asm.js, if it succeeds and can find useful ways to connect other languages to the web browser ecosystem, is a much more dramatic option for letting programmers come to the browser with whatever tools they like.

      I still expect that JavaScript will thrive in that environment. It will still have many advantages. However, it won’t “take over the programming world” as I had originally suggested, because it won’t have the advantage of requiring people to join its revolution to distribute their code over the Web.

      • Eric Elliott

        JavaScript already took over. It is in the #1 spot in terms of use and active development projects. The question now is, can JavaScript maintain dominance on a more level playing field?

        That’s not a question I’m prepared to answer. Even as one of JavaScript’s enthusiastic supporters, I’m tempted by CoffeeScript. JavaScript has plenty of warts, and that leaves opportunities for better languages to take over.

        It won’t be Java or GWT, but there will be other contenders.

        • Tony Stark

          That’s because JavaScript is the only option available on the most widely used platform: the web browser. Is this really all that surprising?

          • Eric Elliott

            It wasn’t always the only option, and in the 90′s, few people realized it would ever become the “only” option. Flash had very good support until iOS dropped it — but it struggled to compete with JavaScript for most applications.

            Java was being positioned as the de-facto standard for serious web applications in the 90′s, but JavaScript won — only partially because of better vendor support. By being more minimal and less monolithic, it was possible to program better, more responsible user interfaces in DHTML + AJAX than you could with Java.

            There are optimizations that browser vendors could have made, and they could have integrated Java and Flash better with HTML + CSS, but by the time that possibility was realized, it was too late for them to compete seriously on the front-end.

    • Tony Stark

      Let me point-out that not all of us want a one-language development community. Many of us understand and appreciate language diversity partly because no one language is well suited for every task but also because no one person is wired the same as the next and people naturally gravitate towards different things for a variety of reasons including sentimental. This cannot be controlled, it is a natural phenomenon, and it is important to account for this.

      A versatile, efficient, and skilled developer can build an application written in more than one language. JavaScript may be easier to pick-up, but quality software is not a function of easy programming languages. Rather it is a function of developer perseverence, and in the end a difficult yet elegant language simply can’t stand in the way of individual with the will to succeed. He will eventually learn it and conquer it and thrive using it.

      “Similarly at fault is the analytical mistake amateur drifters from the
      dying language worlds make: that JS isn’t an “enterprise grade” language
      because of (insert your favorites — no OO, no static typing, no
      modules, etc). A deadly cocktail of ego”

      Ego need not enter into this discussion. Object-oriented architecture helps organize algorithms into units, static typing helps eliminate common mistakes, and JS devs actually do rely on a hack form of modularity using dynamic loaders or “” tags. How many JS developers actually put everything into one file and then work with that? Most JS developers I know divide their code up into a myriad of files in an attempt to modularize their applications. But most importantly, all of the above helps an IDE introspect source code.

      An IDE is designed to to vastly improve productivity with features such as auto-complete, one-click class navigation, call hierarchies, class hierarchies. Once stream-lined, an individual can get away with typing a few characters and then control-space, rinse and repeat. I cannot achieve this same level of productivity with JavaScript because a dynamic language is impossible to introspect without running it. So the outrage is warranted because it suggests throwing away all their tools for a language whose best support tool is notepad. It may be viewed as a weakness to depend on tools (such as an IDE) but it is simply smart particularly if it frees your mind from the mundane to focus on algorithms.

      In conclusion: “You must encourage prototypal thinking (which is closer to the way humans actually think)”

      How do you know this? Modern neuroscientists even admit that there is no biological basis for personality likely due to quantum superposition. Furthermore, quantum tunneling, an observed and troublesome phenomenon in circuitry, is not inconcievable in affecting the voltage gradient and messing with potassium ion pumps influencing when a neuron fires. At best we can artificially model 100 networked neurons, an extremely far cry from the billions making-up a network in a typical brain. We have barely scratched the surface in determining how the mind works and so I think programming language design is on a completely different magnitude of complexity and deserves further exploration and inquiry beyond the prototypal approach rather than settling on preconcieved notions about brain function. I think what irks me most about this is that you state “You must x” as if there is only one way of doing things. That just simply is not the case.

  • http://thinkingonthinking.com/ Patrick Mulder

    Interesting thoughts and nice discussion of JavaScript evolution. I wonder if a ‘programming language’ is behaving more like some part of a DNA, and it is the actual frameworks that are a bit like the phenotypes. From an even higher ‘biological’ viewpoint, an application is then similar to a member of a species.

    So, from that, we still will have to deal with ‘old’ genes (C/C++, Cobol, Java, etc.) for a long time. I also think that JavaScript on server side is not yet fully production ready (deploy, monitoring, release kind of problems). In fact, the server side might be influenced by the JVM for a long time too.

    • Eric Elliott

      A lot of us are using Node in production, and I must say I’ve been impressed by how well it’s working out. There are issues, of course, but I’ve had issues with every other environment that I’ve deployed into production, and the very large and growing community responds to issues well.

  • A.T. Murray

    JavaScript is not going to take over the _programming_ world, but rather the _entire_ world — through open-source artificial intelligence (AI) released upon the unsuspecting world with JavaScript AI Minds in [English] and in [Russian].

  • Jeff Schwartz

    Unless every browser vendor will seamlessly integrate compile to javascript your “conclusion” is wrong. Period!

  • Abdulrezak taj

    If you speak of web development I would agree with you however in software sectors I suspect that JavaScript would dominate other languages

  • http://NerdyDork.com nerdydork

    “Let me tell you why I love JavaScript… it’s a little thing called stockholm syndrome” — Geoff Schmitt (Meteor.js founder)

    • David Webber

      Fortunately I have not succumbed to that syndrome. I have written some fun JavaScript in the past – but cross-browser hacking – no fun. Frankly though – this is NOT the programming language of the future. Within 5 years you will be looking back and saying “what were we thinking?” – there are vastly better ways to instruct processing in computers than the tedium of current code hacking. We’ve been stuck with this ugly for twenty years now – but entirely new metaphors are out there – and machine execution systems.

      Meanwhile – enjoy your JavaScripting – but do not view this as the future – its merely the last gasps here of the past.

      • bebraw

        Hey, could you elaborate on those new metaphors?

      • http://about.me/ddavis/ Dustin Davis

        I’m a Python guy. I’m looking forward to a more pythonic way of browser scripting. That’s why this post was exciting to me.

  • David Jensen

    There will be two languages: JavaScript and COBOL, thus sayeth a mainstream computer publication.

  • Ivaylo Slavov

    I think all the JavaScript hype nowadays is overly exaggerated to the extreme. The reasons are simple – the last decade contains an increasing demand for software technologies targeting the web – which implies that JavaScript was an essential must-know tool to create a website. Nowadays we have a bunch of people who feel comfortable with JavaScript. Now, we have the technology that allows us to use JavaScript in different ways – as a sever-side language and a platform (via node.js for instance).

    So these people think this could be the next logical step for them in terms of their career and professional development. This could explain the boom of adoption and use of these technologies.

    Still, we cannot assume a taking over will occur, as besides its power, JavaScript is merely a language. The concepts of programming today do not rely as heavily on the language itself as it was a few years ago, when it was important to decide between C or Java, VB or something else. The multiple devices and platforms that are being targeted have caused an evolution in technologies that establishes its basis on a runtime environment. Being a simple script interpreter, or a complete virtual machine like the JVM/JRE for Java or the CLR/Mono for .NET – this is the today’s programming technology concept, which allows you to use a variety of programming languages on top of an intermediate environment, including JavaScript.

    Taking this in mind, I must say that the language is a choice that results both from the purpose of the software being created and the knowledge of the developers entitled with the task. Most of the today’s software demands can be written in JavaScript and most of the people as I said earlier, already know it. It is a natural and expected pattern to see its wide adoption. But, there are areas where JavaScript will hardly ever step a foot as a primary language, and these areas are core to the IT industry. I most certainly doubt that there will be a JavaScript-written operating system, web sever infrastructure, database engine, full-featured computer game that takes advantage of hardware acceleration and runs natively on the client’s machine and etc. And that will not be because JavaScript is not capable for this, but because it is not suitable for serious and big projects, especially enterprise-level ones. It is hard to maintain, debug and diagnose issues when the codebase becomes complex and large, and for that reason many other languages are being favored. That being said, a language (even a newly invented one) that overcomes these disadvantages of JavaScript is more likely to be used in these areas of the IT industry.