The JavaScript Disruption

The mainstream programming language for the next ten years will be JavaScript. Once considered a toy language useful only for checking form fields on web pages, JavaScript will come to dominate software development. Why this language and why now?

What is JavaScript? It is the language that web designers use to build web pages. It is not the language the software engineers use to build the business logic for those same web sites. JavaScript is small, and runs on the client, the web browser. It’s easy to write unmaintainable spaghetti code in JavaScript. And yet, for all these flaws, JavaScript is the world’s most misunderstood language. Douglas Crockford, a senior engineer at Yahoo, is almost singlehandedly responsible for rehabilitating the language. In a few short, seminal online essays published shortly after the turn of the century, Crockford explains that JavaScript is really LISP, the language of artificial intelligence. JavaScript borrows heavily from LISP, and is not really object-oriented at all. This curious design was well suited to a simple implementation running in a web browser. As an unintended consequence, these same mutations make JavaScript the perfect language for building cloud computing services.

Here is the prediction then: within ten years, every major cloud service will be implemented in JavaScript. Even the Microsoft ones. JavaScript will be the essential item in every senior software engineer’s skill set. Not only will it be the premier language for corporate systems, JavaScript will also dominate mobile devices. Not just phones, but tablets, and whatever enters that device category. All the while, JavaScript will continue to be the one and only language for developing complex interactive websites, completing drowning out old stalwarts such as Flash, even for games. For the first time in a history, a truly homogeneous programming language infrastructure will develop, with the same toolkits and libraries used from the top to the bottom of the technology stack. JavaScript everywhere.

How can such a prediction be made? How can one make it so confidently? Because it has all happened before, and it will happen again. Right now, we are at a technology inflexion point, yet another paradigm shift is upon us, and the JavaScript wave is starting to break. We have seen this before. Every ten years or so, the
programming world is shaken by a new language, and the vast majority of developers, and the corporations they work for, move en mass to the new playground. Let’s take a look at the two technology shifts that have preceded this one, so that we can better understand what is happening right now.

Prior to Java in the first decade of this century, the C++ language was dominant in the final decade of the last. What drove the adoption of C++? What drove the subsequent adoption of Java? And what is driving the current adoption of JavaScript? In each case, cultural, technological and conceptual movements coalesced into a tipping point that caused a sudden and very fast historical change. Such tipping points are difficult to predict. No such prediction is made here – the shift to JavaScript is not to come, it has already begun. These tipping points are driven by the chaotic feedback channels at the heart any emerging technology. One need only look at the early years of the motor vehicle: steam, electric and oil-powered vehicles all competed for dominance in similar historical waves.

What drove C++? It was the emergence of the object-oriented programming paradigm, the emergence of the PC and Microsoft Windows, and support from academic institutions. With hindsight such large-scale trends are easy to identify. The same can be done for Java. In that case, the idea of the software virtual machine, the introduction of garbage collection – a language feature lacking in C++ that offers far higher programmer productivity, and first wave of internet mania. Java, backed by Sun Microsystems, became the language of the internet, and many large corporate networked systems today run on Java. Microsoft can be included in the “Java” wave, in the sense the Microsoft’s proprietary competitive offering, C#, is really Java with the bad bits taken out.

Despite the easily recognizable nature of these two prior waves, one feature that both share is that neither wave led to a true monoculture. The C++ wave was splintered by operating systems, the Java wave by competing virtual languages such as C#. Nonetheless, the key drivers, the key elements of each paradigm shift, created a decade- long island of stability in the technology storm.

What is happening today? What are the key changes? Cloud computing is one. For the first time, corporations are moving their sensitive data and operations outside of the building. They are placing mission critical systems into the “cloud”. Cloud computing is now an abused term. It means everything and nothing. But one thing that it does mean, is that computing capacity is now metered by usage. Technology challenges are no longer solved by sinking capital into big iron servers. Instead, operating expenses dominate, driving the need for highly efficient solutions. The momentum for green energy only exacerbates this trend. Needless to say, Java/C# are not up to the job. We shall see shortly that JavaScript is uniquely placed to benefit from the move to cloud
computing.

Mobile computing represents the other side of the coin. The increasing capabilities of mobile devices drive a virtuous circle of cloud-based support services leading to better devices that access more of the cloud, leading to ever more cloud services. The problem with mobile devices is severe platform fragmentation. Many different platforms, technologies and form factors vie for dominance, without a clear leader in all categories. The cost of supporting more than one or two platforms is prohibitive. And yet there is a quick and easy solution: the new HTML5 standard for websites. This standard offers a range of new features such as offline apps and video and audio capabilities that give mobile websites almost the same abilities as native device applications. As HTML5 adoption grows, more and more mobile applications will be developed using HTML5, and of course, made interactive using JavaScript, the language of websites.

While it is clear that the ubiquity of HTML5 will drive JavaScript on the client, it is less clear why JavaScript will also be driven by the emergence of cloud computing. To see this, we have to understand something of the way in which network services are built, and the challenges that the cloud brings to traditional approaches. This challenge is made concrete by what is known as the C10K problem, first posed by Dan Kegel in 2003.

The C10K problem is this: how can you service 10000 concurrent clients on one machine? The idea is that you have 10000 web browsers, or 10000 mobile phones, all asking the same single machine to provide a bank balance or process an e-commerce transaction. That’s quite a heavy load. Java solves this by using threads, which are way to simulate parallel processing on a single physical machine. Threads have been the workhorse of high capacity web servers for the last ten years, and a technique known as “thread pooling” is considered to be industry best practice. But threads are not suitable for high capacity servers. Each thread consumes memory and processing power, and there’s only so much of that to go round. Further threads introduce complex programming programs, including a particularly nasty one known as “deadlock”. Deadlock happens when two threads wait for each other. They are both jammed and cannot move forward, like Dr. Seuss’s South-going Zax and North-going Zax. When this happens, the client is caught in the middle and waits, forever. The website, or cloud service, is effectively down.

There is a solution to the this problem – event-based programming. Unlike threads, events are light-weight constructs. Instead of assigning resources in advance, the system triggers code to execute only when there is data available. This is much more efficient. It is a different style of programming, one that has not been quite as fashionable as threads. The event-based approach is well suited to the cost structure of cloud computing – it is resource efficient, and enables one to build C10K-capable
systems on cheap commodity hardware.

Threads also lead to a style of programming that is known as synchronous blocking code. For example, when a thread has to get data from a database, it hangs around (blocks) waiting for the data to be returned. If multiple database queries have to run to build a web page (to get the user’s cart, and then the product details, and finally the current special offers), then these have to happen one after other, in other words in a synchronous fashion. You can see that this leads to a lot of threads alive at the same time in one machine, which eventually runs out of resources.

The event based model is different. In this case, the code does not wait for the database. Instead it asks to be notified when the database responds, hence it is known as non-blocking code. Multiple activities do not need to wait on each other, so the code can be asynchronous, and not one step after another (synchronous). This leads to highly efficient code that can meet the C10K challenge.

JavaScript is uniquely suited to event-based programming because it was designed to handle events. Originally these events were mouse clicks, but now they can be database results. There is no difference at an architectural level inside the “event loop”, the place where events are doled out. As a result of its early design choices to solve a seemingly unrelated problem, JavaScript as a language turns out to be perfectly designed for building efficient cloud services.

The one missing piece of the JavaScript puzzle is a high performance implementation. Java overcame it’s early sloth, and was progressively optimized by Sun. JavaScript needed a serious corporate sponsor to really get the final raw performance boost that it needed. Google has stepped up. Google needed fast JavaScript so that its services like Gmail and Google Calendar would work well and be fast for end-users. To do this, Google developed the V8 JavaScript engine, which compiles JavaScript into highly optimized machine code on the fly. Google open-sourced the V8 engine, and it was adapted by the open source community for cloud computing. The cloud computing version of V8 is known as Node.js, a high performance JavaScript environment for server.

All the pieces are now in place. The industry momentum from cloud and mobile computing. The conceptual movement towards event-based systems, and the cultural movement towards accepting JavaScript as a serious language. All these drive towards a tipping point that has begun to accelerate: JavaScript is the language of the next wave.

This entry was posted in Uncategorized. Bookmark the permalink.

68 Responses to The JavaScript Disruption

  1. I Am Rudiger says:

    JavaScript isn’t really based on Lisp. Mr. Crockford was just making a point that it wasn’t C or Java.

    • Do I get a pass for “dramatic effect”?

    • “Deep down, JavaScript has more in common with Lisp and Scheme than with Java. It is Lisp in C’s clothing.” [JavaScript: The Good Parts, pp3].

      Richard does not say that JavaScript is “based on” Lisp, but “borrows heavily on”. I think that is quite in line with what Crockford said.

    • nod fint says:

      Are you serious here? Even Brendan Eich (its author) said on many occasions he was hired by NetScape to make a Scheme (academic polished Lisp) implementation, and was later forced to change syntax and add some sort of inheritance (prototypes were discussed a lot at that time for Self) because of the Java hype.

  2. cmar says:

    I found your projections very interesting. As you mentioned, Douglas Crockford opened my eyes and helped me reconsider javascript. Javascript suffers from being too powerful with not enough established patterns, although jQuery had made a lot of progress towards standardizing the way we use it. Sounds like its time for everyone to learn Node.js. Thanks.

    • As you can probably tell from the article, I had a bit of a damascene conversion to JavaScript a few years back – mostly from reading Crockford.

      There’s nothing like the zealotry of a convert!

  3. Anonymous says:

    Why Javascript? Because it’s the lowest common denominator language that will run on all platforms. Simple as that. Nothing to see here.

    “JavaScript is uniquely suited to event-based programming because it was designed to handle events”

    Hogwash. Java, Ruby, Python,… any language that has functions can handle events.

    Your prediction is shite. Javascript is shite and although it’s not going anywhere, it’ll be a cold day in hell when it’s used ubiquitously on every tier of every application.

    • You’re right of course – it is the lowest common denominator – which is exactly why it will come to dominate.

      It is true that other languages can handle eventing – Twisted, EventMachine etc. But here’s the problem: it’s not baked in to the other libraries.

      In JavaScript, and in Node particularly, *all* libraries are event based. With the other languages, there are issues using blocking libraries.

      I stand by my prediction though – I’ll even strengthen it :)
      JavaScript will run on all tiers – including the DB! You can already do this with Couch and Mongo.

      You know the way Oracle let’s you write stored procedures in Java – they’ll add support for JavaScript soon :)

      • Anonymous says:

        I’m not sure that what you’re referring to as “event handling” is the same thing that I’m referring to. Can you please define what you mean by this? To me, event handling is simply one implementation of the Observer Pattern (http://en.wikipedia.org/wiki/Observer_pattern). No need for any special projects like Twisted or EventMachine….

        Anyway, you’re not taking into account that a large majority of developers abhor javascript and will often go out of their way to avoid using it.

        Javascript may be _present_ on every tier, but it simply won’t dominate for the same that Web apps and dynamic languages don’t dominate now even though they’ve been around for a decade. Developers don’t want to shoe-horn functionality into frameworks and languages that weren’t designed for it.

        We’ll see though, won’t we. Interested in making a long bet?

        • Yeah – we’re talking about different things :)

          What I am referring to are event generated by the operating system – letting you know when there’s new data in a network buffer, etc.

          Imagine a database request in Java. Your thread will block on the open connection, waiting for a response from the DB. All that time, it’s consuming resources – memory, and context-switching overhead.

          With an asynchronous evented architecture, you have no thread hanging around. The server (e.g. Node) only reacts when there’s a response from the DB. And then it runs your single-threaded code as the point of the callback. You only ever get one thread. When you code reaches another point where it would traditionally block, it returns to the server, which checks if there are any new events for any of the current callbacks it knows about.

          This turns out to be a very efficient way of doing things.

          The long bet – sure! :)

          By March 2021 the majority implementation choice for traditional enterprise line-of-business systems will be on cloud hosted platforms (local or remote), running JavaScript environments that resemble Heroku.

          The winner will cover a meal for four (being each contestant and partner), at Craftsteak in the MGM Grand in Las Vegas (or equivalent).

          • Anonymous says:

            Asynchronous architectures can and have been built into a number of frameworks. My own recent work is an N-tier system written in C# in which every I/O call is a non-blocking asynchronous call. Every call from the client to the server is async and every I/O call from the server to the database or other back-end socket service is async. It’s really not that uncommon.

            I agree with the wording and that bet. Let’s set it up.

          • Send me connect request on LinkedIn :)

          • Anonymous says:

            I’d rather remain anonymous and I didn’t know that longbet.com requires a real name. I’ll have to think about it.

          • Well, it’s recorded here anyway :) You know where to find me!

  4. Ivan Vučica says:

    It’s rather bold to make such a prediction. Javascript lacks a lot of constructs of classic object-oriented languages such as C++, Java, C# or Objective-C that make it mentally easier to understand and organize. Why would otherwise Google invent GWT

    What is so special about Javascript’s “event-driven” features compared to C callbacks, C++ and Objective-C delegates? What about the notification center in Cocoa for Objective-C?

    Sure, Javascript can be written very well. Does the world have the critical mass of truly competent Javascript developers that it needs for a true revolution such as you describe? Will it have it in the next few years? I seriously doubt it. If it had, we’d have even more sensible docs on developing web apps and complex Javascript-based systems.

    With current browser incompatibilities (as well as any standalone implementation incompatibilities) it is hard to find a piece of Javascript with at least some hacks to get it to work everywhere. It’s hard to organize Javascript. And until I can go around any corner and meet someone that has developed a complex system in Javascript (for example, a browser-based game), which actually works and works well, and is not full of hacks, then I’ll consider the world ready for a Javascript revolution.

    As is, best well-known examples of Javascript engineering such as jQuery are still used primarily for decoration.

    And I hope I’m wrong, and that it’s easily possible for common people to organize themselves while writing complex Javascript apps. Because then in 10 years we’d have a universal programming language.

    By the way, have you seen Objective-J, Cappuccino, and what you can do with it, such as http://280slides.com/ ?

    • Hi Ivan – you’re just nostalgic for traditional “Classes” :)

      I have to say, I’m a big fan of George Lakoff ( http://www.amazon.com/Women-Dangerous-Things-George-Lakoff/dp/0226468046 ) so I think prototypes are a much better idea than classes.

      I’m not too concerned about the state of the browser – there’s moderate standards convergence, and the problems are below the threshold of exponential complexity explosion.

      Ever run ./configure to build some C code? We’ll see similar “hacks”. But they’ll be good enough.

      I also think that the code organisation issues are not as bad as all that. First, you have to write less code, so there’s less to manage anyway. Second, the CommonJS module system is good enough. Third, coders gonna code – it’ll always be a mess! :)

      • Ivan Vučica says:

        Hi!

        Yup, I love traditional classes. If I understand correctly what you are referring to, I like the idea of modifying a prototype as well. Objective-C allows that. If you are referring to “every object can be copied and modified as if it were a class”, well, I guess I’m a traditionalist and I like separation of concepts that classes provide.

        Standards convergence being moderate does not make me happy if I have to write code for older browsers. I wrote a piece of code that works perfectly on Safari 5 and Chrome 8, 9 and 10. Firefox 3.5 provides document.sessionStorage but does not allow me to store into it, at least not onUnload. I haven’t had time to examine what goes wrong on Firefox 3.6, nor on Opera — but things go wrong.

        And I’m not really trying to do much magic stuff. There are differences on how JSON serialization of complex objects works. There are differences in sessionStorage behavior. There are even small differences in XML DOM.

        I’m fully aware that all this shows a large lack of experience on my part when it comes to Javascript. I’m aware that I should probably be using something to abstract away the details. But I just want to do things easily using stuff that’s built into browsers. I want good documentation on how sessionStorage works, when it can be used and when it cannot be used. I don’t want nasty surprises such as the XMPP client reconnecting to the server on each page load despite being explicitly designed to serialize its state just because sessionStorage doesn’t work onUnload in FF3.5.

        And yes, I have users that use FF3.5 that I can’t tell to switch (kids). I have users that even use IE. That’s a browser I’m not even trying to support, and they’re on their own.

        This piece of code that I wrote — I find it hard to wrap my head around it, even after a full rewrite from scratch. Debugging is hard and would be harder if Dev Tools did not expose at least the console and some sort of being able to see where the code failed. Getting a stacktrace requires a pretty big piece of Javascript: http://emwendelin.github.com/javascript-stacktrace/

        After being so happy to get away from C++ and “fixing stuff” by moving to Objective-C, it’s hard to find justification to work in Javascript except to “get it to work in a browser”. Which is a very noble goal, but not for very big projects. (By the way, Objective-C’s runloop is pretty much event-based.)

        Javascript keeps trying to run even after an exception terminates a particular code path, and that makes catching crucial problems difficult. You know, a timer remains active, an onClick event executes, etc.

        Javascript can be nice. I saw a few pieces of nice Javascript. What I want to say is that tons of people will resist it heavily.

        —-
        Hacks:
        Compiled programs have them mostly because of documented and/or obvious differences. Javascript differences are rarely documented… or at least, rarely documented well.

        —-

        Code organisation:
        I have to write less code in Objective-C too. Cocoa is a wonderful framework.

        When it comes to web: Fingers crossed that Apple resurrects Web Objects’ idea in a modernized form, and that Cappuccino gains more exposure!
        ———–

        You haven’t said what makes events in Javascript different from what you have in Objective-C or what you could implement in other languages? :-)

        • Hi Ivan – good thoughts – thanks!

          The way to deal with cross-browser issues is to use an abstraction layer like jQuery – this takes away a lot of the pain. On the server side, you don’t really have any cross-platform issues :)

          Agreed – JavaScript stacktraces are a lot less useful than in other languages. The downside of callbacks.

          And that applies to exceptions as well – they won’t stop the callbacks either.

          It’s better to just bite the bullet and work in terms of functional composition.

          On events – it’s not the language. I’m talking about the asynchronous eventing model that Node.js uses.

  5. Paul Brannan says:

    I agree that Javascript will be ubiquitous in 10 years, but not in the sense that you predict. Javascript is already becoming a platform for building other, higher-level languages. Javascript the language will fade away into the background like C eventually did, and a handful of other languages will emerge from the dust cloud, each one suited to a particular style or need. The Javascript VMs will succeed where Parrot, the DLR, and the JVM have failed (in the sense of user adoption, not feature set), and we will finally have one platform where many dynamic languages can and will interact seamlessly.

  6. It’s pretty critical to point out that the explosion in JS development was been made possible by libraries like Prototype, Dojo, and ultimately jQuery. These “browser proxy engines” took the anguish out of JS development; this, combined with the “good enough” DOM offerings of CSS + HTML and the option of asynchronous (“ajax”) interaction with the server/cloud make JS “hawt”. Finally, developers are sick of working on so many platforms/frameworks, etc. The mantra of “DRY” is sinking in so that if one can write a framework once for the front end, why write it in a different language on the back end?

    • Yes! Many dismiss this fact, that you code in the same language client and server-side. Do not underestimate the reduction in cognitive dissonance. Even a language like Ruby suffers here.

      • Josh says:

        Totally agree with the bigger premise that JavaScript will rule: the efficiency and proficiency that a single language both client and server-side with near-zero context-switching is not to be underestimated.

        Also, coffee-script will rule in due time, in turn.

  7. Sorry to break it to you, but V8 (and, hence, Node) runs on threads at a low level.

    • Hi Andrew,

      It does. Necessarily. However, these are infrastructure threads that delegate blocking behaviour to the underlying OS as much as possible.

      The advantage of Node is that is does not have a *per-client* thread model.

  8. Mirko Kiefer says:

    Hi Richard, I agree that Javascript has huge potential especially with the emerging server-side stack. Writing good JS code will certainly become a highly demanded skill in the next years.
    For a mediocre programmer the “lack” of guiding constructs like in typical object-oriented languages makes it fairly easy to create a mess. This and the still not available documentation on designing JS applications is still a critical problem for serious mass adoption – if someone knows a good book besides Crockford’s, give me a shout ;).
    Like Paul I see JS to become more and more a kind of “assembly language” of the web – being the common denominator for domain-specific languages and platforms built on top. We already have examples with awesome projects like Cappuccino, CoffeeScript or Protovis.

    • Hi Mirko,

      Certainly JavaScript syntax is too much like C, and just the wrong side of verbose. It will definitely be a compilation target. As another commenter pointed out (a little sharply), JavaScript has “lowest common denominator” status, which means that it will ultimately dominate enterprise cloud development

  9. I think you are confusing JavaScript with one of its implementations. Event-based development is more or less “Don’t call us, we’ll call you (and don’t forget to give me a proper number (listener) where I can reach you)”. This is a concept, it is not bound to a programming language.

    However, one amazing thing about JavaScript is that you can use it and program with it without actually learning it. There are not many languages like it and a lot of people I know have not learned JavaScript prior to actually using it. It feels familiar. If you know at least one C-syntax language, JavaScript will be easy to understand. That’s JavaScript’s biggest advantage, nothing else, no concept, no implementation is as powerful in this respect as JavaScript’s simplicity is.

    I also agree with Paul Brannan who said that JavaScript will fade away. We already see this with CSS. Both of them are low-level ways to do Web Development. Eventually, abstraction languages will be created set to make JavaScript even easier. There will always be the “hardcore developers” sticking with JavaScript, but a few popular abstraction languages won’t hurt either. JavaScript is not there yet, it has its limitations. Just consider how counter-intuitive it is to pass callbacks around, we need ways to handle this better. The simplest form of an example I can make is how annoying it gets to write out “function(){” all the time. In the immediate future we will probably start using ES6 (once its done) using an interpreter like Narcissus so that we can get features sooner rather than later and so we don’t have to wait until every engine implements it.

    • Yeah, writing “function” all the time is an utter pain. CoffeeScript get this right.

      I think a lot of the ill-will among some developers towards JavaScript comes from the fact, as you point out, that no-one ever learns it properly. You do actually need to learn the good bits.

  10. Guys why we are not discussing about flash here.
    Flash supports majority pf these use-cases, like classes, prototypes, event-based, cross-browser support…perhaps it’s more faster in performance-benchmarks compared to javascript(http://www.oddhammer.com/actionscriptperformance/set4/) and it is elegant in writing the code. Adding icing on the cake, it doesn’t needs any other external support/tool, runs flawlessly in browsers.

    Today, I believe flash is far-ahead in terms of language, design, performance support than any other platform. I’m not a Adobe-guy, but I love the way Flash solves web-centric problems.

    • Is Propietary, not cross-browser, not faster, not elegant, does need external tools, terrible to develop across a team, not far-ahead.

      • pete shand says:

        come on, how is it not cross-browser? it work in every modern browser and has for the past 10 years.
        depends what your doing for speed, certainly faster for graphics, sound, video (flash 10.2) and 3d (flash 11).
        completely elegant, although depends on the developer (so maybe not for you)
        have no problems developing in a team.

      • Doctor McShip says:

        * It is cross-browser, even more so than any other ‘standard’ I’d say considering adoption rate and consistency between players (not something you can say about HTML or JS);
        * It is faster on all kinds of benchmarks against JS;
        * It is elegant (go write classes in JS and compare that to AS3; in everything else they’re the same);
        * Great to develop across a team, unless you’re trying to use the Flash IDE, which is a joke (I’ve been developing in Flash for 10+ years and I never use the IDE anymore; there are better third-party, including open source, tools available);
        * “Does need external tools” is a strange bullet point. I can develop Flash with notepad and the free compiler. It does need as many tools for asset editing (images, audio) as HTML/JS does.

        JS is indeed the language of the future. But blinding yourself to what AS3 has brought to the table is missing the point.

    • pete shand says:

      well said, totally agree

    • Emphasizes the article’s point since actionscript is ECMA which is essentially javascript with the class keyword and static typing.

    • We’re not discussing Flash because there’s no open source implementation of a complete toolchain, so it’s completely out of the picture for servers or embedded systems.

    • Sam Street says:

      LOL Flash…

      Flash is doomed, stop developing with it (except for crappy games)

  11. Good article and I agree that javascript’s best days are ahead of it and not behind. Although it may be a bit early to say that node.js or systems like node.js will take over cloud computing, they definitely have the potential to do so.

    The only thing I’d add is that jquery and libraries like jquery (prototype, jquery mobile, etc.) deserve some of the credit for making javascript more cross platform, easier to work with, and proving that javascript was no longer a “toy” language. They also did a good job at proving Crockford’s point about javascript being more like LISP than any C variant.

  12. Anonymous says:

    Richard,

    I’m sorry you are wrong.

    10 years is far too long – fewer than 5 I’d predict.

    Great post.

    john

  13. Richard, I think you might be getting a bit carried away here.

    First off, as Crockford himself points out, JS has some good parts (above all, functions as first class objects) but also some very bad parts (default scope = global ???).

    You can write non-blocking IO in any language – it’s just easier to handle the callbacks if you can pass them as straight variables.

    Also, non-blocking IO is not inherently faster than blocking IO (it’s not like the disk heads move faster or something). It all boils down to memory usage.

    ** An event loop uses less memory than a thread pool – that’s all this debate is about. **

    And as long as the physical memory isn’t exhausted, there should be no difference between the performance of two equivalent implementations, one blocking and one not.

    So, with a 128 bit physical address space soon to be the server norm and high-speed RAM given away in Corn Flakes packets, are we really using memory usage as the *key* factor here?

    I love Javascript, but I won’t be using it for any back-end infrastructure projects soon.

    Loose typing is okay, but when you get to thousands of different object definitions, you want the *compiler* to make sure you’re passing the right one to the right function.

    In other words, Java won’t be going away from the back end any time soon.

    • Cloud hosting changes this equation.

      In the old days you bought a server. Sunk cost. You could use up all the resources for zero additional opex.

      In cloud environments you need to be as lean as possible, or running costs will kill you.

      You can squeeze a lot out of an Amazon t1.micro with Node. Not so sure how far you’d get with Tomcat there.

      • Yes, I was expecting this answer – and it certainly makes sense.

        But does this not tell us more about cloud (mis) pricing than an anything else?

        In other words, if cloud billing were based purely on cycles and bandwidth then we’d be back to square one in the debate. Right?

  14. And it also happens to be a nicely designed language with a minimum of legacy cruft.

  15. I agree with you completely on the specific issues in JavaScript as a language.

    My prediction is based on a wider range of industry factors, which I think will override these weaknesses.

    It is accidental that JavaScript finds itself where it is – Brendan Eich could have chosen something else with first class functions.

  16. I’m as big a fan of Joe Armstrong as the next developer.

    Erlang is pretty cool. But I don’t see it having the same momentum to push it into ubiquity.

    And if you can beat up on JavaScript when it comes to syntax nasties, don’t even get me started on Erlang :)

  17. The first database-driven website I ever built was in C – that was back in ’96. It was pretty damn fast as well I can tell you :)

    JavaScript’s flaws are not that relevant to the prediction.

  18. FullStackAndFrameworkVoice says:

    Richard Roger… from full-stack, multi-framework experience: standing applause!
    For the diminishing minons of JavaScript (JSON) haters, feel free to keep ears plugged and tongues extended.

  19. Pingback: JavaScript Magazine Blog for JSMag » Blog Archive » News roundup: iOS viewport fixes, Mobile Boilerplate, CommunityJS, Ender.js

  20. Pingback: Всем сотрудникам отдела! «

  21. Well, I think Node.js kinda changes that :)

  22. Anonymous says:

    “JavaScript as a language has so many flaws and is not an Object Oriented Language which is why it is still used solely as a front-end language”

    Nonsense.

    Did you read the article? Have you seen Node JS ?

  23. Pingback: Revision 21: SPDY, Mobile UI, Webshims, und alles hardboiled! | Working Draft

  24. Pingback: galaxy tab peerfly

  25. Great article but I think there’s too much generalization here. It’s hard to promote one language to kill them all. The language should be chosen both on team knowledge and by project needs. There will always be legacy systems and those will need to be integrated. There are a lot of Cobol on financial business today, and that will continue to be true for a long time.

    Another important thing to notice is that Javascript on Client Side and Javascript on Server Side are completely 2 different things, different needs, different features. Both should be discussed separated. Although the benefit of having the same language on frontend and backend exists this is not the main advantage and won’t probably be a diferential for most projects. When this is both are discussed at the sametime it generates a lot of confusion as seen on previous comments.

  26. Pingback: Weekly Links– 2010_15 (50 for Web Devs & Other Geeks) :MS-Joe (Joe Stagner)

  27. Anonymous says:

    Good blog, JavaScript will abide to be the one and alone accent for developing circuitous alternate websites, commutual drowning out old stalwarts such as Flash, even for games.

    toshiba coupon codes

  28. Great article Richard. One criticism of Java is that it doesn’t really provide anything to leverage advantages of multi-core CPUs. The JVM may make decisions to parallelise Java threads or it may not. But there are no specific APIs for the developer to leverage advantages of multi-core, the JVM is still an abstraction above it. If JavaScript is essentially single threaded can the same criticism be made of it? How can JavaScript leverage advantages from multi-core CPUs?

  29. Pingback: Introducing NodeZoo.com | Richard Rodger

  30. Joe Hunter says:

    Wish I had read this 2 years ago when it was originally published Richard! I am only beginning to realise the power of node.js. I think two years in your prediction is looking very prescient.

  31. Pingback: The Continued Resurgence of JavaScript | joeblogs.ie

  32. Pingback: Javascript | Critiqueslibres.com

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>