JavaScript is Dead. Long Live JavaScript!

For 16 years, JavaScript has been the language of the web browser. This language has enabled the building of compelling web applications and contributed to the success of the web. Other scripting languages could have filled the role JavaScript does but JavaScript was in the right place at the right time. Microsoft added Basic to Internet Explorer a long time ago but JavaScript was the language in all the browsers and so it won. Since JavaScript has been cross-browser and at least good enough, the browser makers have not needed to add other language interpreters to the browsers themselves.

But we still didn’t choose to use JavaScript. It has been the one option. It has powerful features like closures and we learned to love these features while turning a blind eye to the warty parts of the language. There has even been a lot of apologizing to the programming community along the lines of “Yes we know it is a pretty funky language but please give it a chance. I’m sure you’ll learn to love it.” It shouldn’t be that hard to sell the quality of the language. JavaScript has been described as an experiment that escaped the lab a little too early and we’ve been stuck with the warts ever since.

Still, JavaScript has been a great language. In 2007, Steve Yegge declared JavaScript as The Next Big Language and it has been. Between then and now JavaScript-based web-applications have become bigger and better. With JavaScript’s help, the web has continued to flourish even with the threat of native mobile apps taking over the same space.

In very recent times, JavaScript has been making its most successful attempt at being a server-side language. The Node.js platform, with its non-blocking I/O, may be solving a problem that programmers have needed solved for a long time. JavaScript is the language for Node.js and so JavaScript may go along for the ride to become a successful server-side language after many failed attempts in the past.

Overall, JavaScript has been a wild success. The most popular programming language in the world. But if the browser died today, how much new JavaScript code would be written tomorrow? Most likely JavaScript would become a fringe language overnight. But the browser isn’t dying tomorrow. We will be programming for it for years to come.

As JavaScript has been used for more and larger programs, the warts of the language have become more apparent and caused increasing amounts of grief for many developers. It may come as a surprise that even though I’ve written about JavaScript for years, I’m not a JavaScript fanboy. Most of my JavaScript articles have been about me working through the difficulties of finding a peaceful coexistence with the language. Yes I’ve enjoyed programming in JavaScript and have learned a lot but there certainly have been times when I’ve felt like I’m wallowing in the muck.

One of the most obvious deficiencies in JavaScript is with its user interface: its syntax. The inability to quickly improve its syntax has lead to the language’s downfall.

The Case for Syntax Extensions: Verbose Idioms

Here we look at just four of the many examples where JavaScript’s syntax could be improved to remove verbose idioms from our daily programming existences.

Optional Parameters and Default Values

JavaScript functions can be called with a variable number of actual parameters. This makes some of the formal parameters in the function’s declaration optional. Often times these optional parameters must be set to a default value if no actual parameter is supplied. I’m willing to bet you’ve written and seen plenty of code like the following.

function(a, b, option) {
    option = option || {};
    // ...
}

I have and still write code like this. This code is wrong. If a falsy value is passed to the function for option then the wrong thing happens. We should be writing the following.

function(a, b, option) {
    option = arguments.length > 2 ? option : {};
    // ...
}

Although this code expresses the intended thought of setting a default value if an actual parameter for option is not supplied, it is too verbose and less readable. The reader must count to determine which variable is has index 2. Beyond the awkwardness, the correct version is more difficult to maintain. It is easy to produce the following buggy code if the b parameter is removed.

function(a, option) {
    option = arguments.length > 2 ? option : {};
    // ...
}

If your application uses optional parameters with default values, some new syntax would be beneficial for you.

function(a, b, option = {}) {
    // ...
}

The addition of this new syntax tunes the language better to your application’s needs.

Let

Does the following buggy code look familiar?

for (var i=0, ilen=elements.length; i<ilen; i++) {
    var element = elements[i];
    LIB_addEventListener(element, 'click', function(event) {
        alert('I was originally number ' + i);
    });
}

All the elements were the same number?! The solution is to use an immediately evaluated function expression so each alert reports a different number. This is the “let” idiom after Lisp’s various let forms.

for (var i=0, ilen=elements.length; i<ilen; i++) {
    var element = elements[i];
    (function(num) {
        LIB_addEventListener(element, 'click', function(event) {
            alert('I was originally number ' + num);
        });
    }(i));
}

Sure sometimes delegate listeners might be better than the above code but sometimes the above code is the desired idea. In the above case, we are trying to bind the order of the elements when the loop runs. This order could be lost with the delegate pattern if the elements are rearranged in the DOM.

This syntax is particularly awkward because of the distance between the formal num and actual i parameters of the immediate function.

The immediate function could be factored out to another location and called inside the loop.

function attachListener(element, num) {
    LIB_addEventListener(element, 'click', function(event) {
        alert('I was originally number ' + num);
    });
}
for (var i=0, ilen=elements.length; i<ilen; i++) {
    attachListener(elements[i], i);
}

Even with this option, sometimes programmers still use the immediate function because it conveys better their intended message to readers.

If your application uses the let idiom, wouldn’t it be nice to have new syntax for it?

for (var i=0, ilen=elements.length; i<ilen; i++) {
    var element = elements[i];
    let (num = i) {
        LIB_addEventListener(element, function(event) {
            alert('I was originally number ' + num);
        });
    };
}

With num and i together it is much easier to read this code and a new scope containing new has been introduced so the closure works properly. Once again, the addition of new syntax can tune the language better to your application’s needs.

Modules

One of the most common idioms in JavaScript programs we all know and love is usually called “the module pattern.” This idiom provides the benefits of encapsulated variables that are private to the module and imparts sanity to our code.

var event = (function() {

    // private variables
    var listeners = [];
   
    function addEventListener(f) {
        listeners.push(f);
    }

    function clearEventListeners() {
        listeners = [];
    }
    
    // ...
    
    // export the module's API
    return {
        addEventListener: addEventListener,
        clearEventListeners: clearEventListeners
        // ...
    };
}());

The goal of encapsulation here isn’t security. It is to ensure that other developers keep their dirty, monkey-patching hands off your module’s data.

The exporting can be done a few ways but no matter which way there is some boiler plate.

Importing is verbose also

(function() {

    // import desired properties of the event module
    var addEventListener = event.addEventListener;
    var clearEventListeners = event.clearEventListeners;
    
    // ...
}());

Some new syntax would be nice to convey the intent of the module pattern better.

module event {
    
    // private variables
    var listeners = [];
   
    export function addEventListener(f) {
        listeners.push(f);
    }

    export function clearEventListeners() {
        listeners = [];
    }
    
    // ...
}

(function() {

    import event;
    
    // ...
}());

The module pattern is almost everywhere and some new syntax to better express this idiom would better tune the language to all of our applications.

Inheritance

These idiom examples have been growing in how they each span an increasing number of lines of code. The JavaScript idiom that potentially spans the most lines of your program may be the inheritance idiom.

function Employee(first, last, position) {
    // call the superclass constructor
    Person.call(this, first, last);
    this.position = position;
};
// inherit from Person
Employee.prototype = Object.create(Person.prototype);
Employee.prototype.constructor = Employee;

// define an overridding toString() method
Employee.prototype.toString = function() {
    // call superclass's overridden toString() method
    return Person.prototype.toString.call(this) +
           ' is a ' + this.position;
};

What a mess. Yes JavaScript makes single inheritance like this possible by linking prototypes but it takes a lot of code to manually make super things happen they way you might like inheritance to work.

If there could be a maintenance nightmare that is it. The strings “Person” and “Employee” are sprawled throughout the code for the Employee “class”.

If classes with inheritance are a big part of your application, some syntax would really help clean up the code. Perhaps something like the following.

class Employee extends Person {
    constructor(first, last, position) {
        super(first, last);
        public position = position;
    }
 
    update(camera) {
        return super.update() + ' is a ' + position;
    }
}

That is a major improvement.

Learning from Idioms

These common idioms make it clear that JavaScript could use some new syntax for several reasons. The ability to do what we want is usually in JavaScript somewhere. The verbosity of the idioms is sometimes too much. We cut corners. Sometimes we avoid certain algorithms because the idioms are too verbose. The idioms are not self explanatory. They are inside secrets of the community and the intent is not easily recognized by outsiders.

The ECMAScript committee has recognized that the above idioms, and others idioms, are common across a wide variety of applications. There are proposals for all of these syntax cases in Harmony. Some of them may make it into the next version of ECMAScript and into the browsers for your use. If new syntax gets there eventually then you can use use it.

Idioms may have emerged in your application that do not appear in a wide variety of applications. For example, Node.js’s non-blocking I/O and heavy reliance on callbacks will undoubtedly result in idioms that do not appear in browser scripts. Syntax specific to just your applications will likely never make it into ECMAScript.

If you would like to use specialized syntax for the general idioms like those shown above or you would like syntax for your own idioms, what can you do?

If Only We Had Macros

Lisp languages have had full-blown macros for decades. Through macros, Lisp gives programmers the ability to tune the language’s syntax to best match their own applications. Because of its macros, Lisp has been described as “the programmable programming language.” Powerful stuff.

Lisp’s s-expression syntax, you know, the syntax with all those parens, gives the language a special property called homoiconicity. It roughly means the syntax of the language is also the syntax of its data structures or that a program’s parse tree uses the languages data structures. This homoiconicity makes Lisp’s macros possible.

JavaScript doesn’t have macros. A major reason for this is that adding macros to languages with C-like syntax, languages that are not homoiconic, is still a research topic. Excerpts from a short conversation on Twitter with littlecalculist, Dave Herman, Ph.D., ECMAScript committee member, and Mozilla Researcher:

@petermichaux

I believe @littlecalculist knows more about the research and possibilities for macros in ECMAScript. I’d like to know more also.

@littlecalculist

I have thoughts on it for sure. But macros for non-sexp languages is still very much a challenging research topic

@petermichaux

[...] We’ll turn blue waiting for macros.

@littlecalculist

Might I suggest you keep breathing? ;-) Seriously, I do hope to try, but trust me, macro system design is hard.

The message is pretty clear. JavaScript macros are not just around the corner.

Harmony Syntax ETA

Perhaps the syntax extensions in Harmony are all you dream of and more. If Harmony becomes ECMAScript 6 and ECMAScript 6 becomes ubiquitous then you’ll be all set. So all you need to do is wait...patiently.

First, let’s look at browser adoption. Unfortunately I’ll pick on Internet Explorer a bit, which has almost become a cliche, but not because I have something against the Internet Explorer development team at Microsoft or the newest versions of Internet Explorer. It is necessary to look at this browser because it is perhaps the most important case study for estimating when features will be available for all visitors to your web site.

As of May 2011, w3schools, which has relatively tech-savvy visitors, reports Internet Explorer 6 still has 2.4% market share. Net Market Share reports Internet Explorer 6 still has 10.36% market share. Your site probably has a market share somewhere between those two numbers but this browser is still hanging on even though it was superseded by Internet Explorer 7 in November 2006. How many people are still using Internet Explorer 6 or 7? The w3schools site shows 7.7% and Net Market Share shows 18.2%. These browsers just aren’t going away fast enough. A publicly available site (e.g. Amazon) cannot afford to ignore market share numbers this large.

There is no point in spending any energy moaning that users should upgrade their browsers or that “IE should die!” It won’t happen. I don’t know if it is true but someone once said to me “Internet Explorer users upgrade their browser when they upgrade their hardware.” For the past few years, hardware has certainly become sufficient that people don’t need to upgrade anything to use email, Facebook, Twitter, etc.

Suppose your web app is sufficiently advanced that you’ve decided that you only care about users with “modern” browsers. Google Apps recently announced that on August 1, 2011 they will stop supporting Internet Explorer 7. That is almost 5 years after Internet Explorer 7 was released.

Now think about this: Internet Explorer 10 is not out yet but, of course, even it won’t have Harmony’s syntax extensions. Let’s estimate that Harmony is approved as ECMAScript 6 in mid-2012 and Internet Explorer 11 is released in early 2013 with support for all of Harmony’s syntax. Five years after that, in 2018, the Google Apps team can drop support for Internet Explorer 11 and finally use Harmony syntax freely. (On August 1, 2011, they are also dropping support for the four-year-old Safari 3 and two-year-old Firefox 3.5 so the waits are still long-ish for other browsers too.)

Amazon developers might need to wait an additional 5 years before they can use Harmony syntax. That’s 2023!

Will you be satisfied waiting 7-12 years before you can start using syntax that would be helpful developing your web apps today? Being more optimistic, even if the wait is just 5 years, will you wait?

JavaScript is Dead.

Cause of death: semicolon cancer.

Perhaps due to JavaScript’s syntax alone, JavaScript does not have macros now and won’t have them soon if ever. Millions of programmers use JavaScript now and plenty of them are tired or tiring of the verbose idioms confronting them daily. They want new syntax now and won’t wait. For this growing group of developers, JavaScript the source code language is dead.

You had a good reign, JavaScript. We had some good times and wrote some cool apps together. May you rest in peace.

Long Live JavaScript!

Programmers like to control their own destiny and they are taking action. You can have all the new syntax you want for your browser scripts, right now, if you write in another source language and compile to the ECMAScript 3 dialect of JavaScript for the billions of browsers in the wild. By compiling to ECMAScript 3 you are completely freed from JavaScript’s syntactic evolution. As an added bonus, you can even fix some of JavaScript’s semantic gotchas with a sufficiently sophisticated compiler. JavaScript’s new life is as a compilation target.

Languages that Compile to JavaScript

There have been compilers to JavaScript for years now. In 2007, I started collecting a list of languages with compilers to JavaScript. There were JavaScript extension languages: the now-defunct ECMAScript 4, Narrative JavaScript, and Objective-J. There were pre-existing languages: Scheme, Common Lisp, Smalltalk, Ruby, Python, Java, C#, Haskell, etc. There were even brand new languages HaXe, Milescript, Links, Flapjax that were designed to address web programming needs.

Of these compiler projects, Google’s GWT Java-to-JavaScript compiler has probably been the most successful but I don’t see programmers who first learned a language other than Java rushing to use Java as their source code language. In fact, none of these compiler projects have accrued a significant long-term user base. At least in the parts of the web that I frequent, with the exception of GWT, it is rare to read about programmers using these compilers for any real projects. There are several legitimate reasons not to use one of these compilers.

Imagine you build a big project using one of these compilers and part way through find a bug in the compiler. The one maintainer of the compiler may have lost interest or time. Do you want to maintain a compiler? Does anyone on your team have the skills to do that? That ulcer is going to get pretty big while you prepare to explain to the CEO that you now need to rewrite the UI in JavaScript.

Just the thought of debugging compiled code when a production bug is filed makes my stomach churn. Core dump. What line number in the source code matches the line number Firebug is reporting for the compiled code? HURRY! That bug needs to be fixed now!!!!

You’ve used Objective-J for a big project and now you need to hire a new good programmer. What are your chances of finding the right person? They are probably very low. Just finding an available JavaScript programmer is difficult enough. If you use one of these alternate languages, it is very likely you’ll need to train each new person you add to your team.

Even without these compiler projects being wildly successful, the list of languages that compile to JavaScript has continued to grow. There is no doubt that writing a to-JavaScript compiler is a very cool project. Please pay me to write one.

There is one notable new entry in the list of languages that compile to JavaScript that is actually causing a big stir and is possibly changing the game for good.

CoffeeScript

I can tell you right now, I don’t know why CoffeeScript has the magic combination of features to garner the attention it has when other projects have failed. Significant whitespace and arrow function syntax. My gut reaction is yuck. There is plenty of things to like: default parameter values, rest parameters, spread, destructuring, fixing the whole implied global mess, even classes if you’re into that kind of thing and more. Many of CoffeeScript’s features are part of Harmony and so may be in browsers sometime in the future but if you use CoffeeScript then you can have them now. There is nothing like instant gratification.

Programmers are bursting with affection for CoffeeScript.

@pyronicide

Being able to use default values for function arguments in #coffeescript makes me immensely happy.

@_jdpage

CoffeeScript is wonderful. Now I am spoiled and will complain whenever I have to write JavaScript instead.

At the TXJS 2011 conference, Douglas Crockford apparently shared that he thinks “CoffeeScript is clearly good stuff.”

There is one aspect of the CoffeeScript project that I really like and it is summed up by the following two quotations. The first comes from Trevor Burnham, author of CoffeeScript: Accelerated JavaScript Development.

@trevorburnham

[...] It’s not about turning JS into Ruby/Python; it’s about having a syntax better suited to JavaScript’s inner goodness.

The second is from The Little Book on CoffeeScript.

CoffeeScript neatly sidesteps these [JavaScript issues], by only exposing a curated selection of JavaScript features.

The attitude expressed in these quotations really is great and genius marketing too. It is not CoffeeScript verse JavaScript. It is CoffeeScript enhancing the JavaScript programming experience. Could some different syntax and a restricted subset of JavaScript’s features really be better than plain old JavaScript?

Douglas Crockford seems to think so. For years, his JSLint has been hurting our feelings and demanding that we use very specific whitespace and syntax and that we avoid dangerous JavaScript features. Source code that passes JSLint has access to a true subset of JavaScript: the subset that he calls “the good parts.” This dialect of JavaScript deserves a name. Maybe GoodScript? After all, you are only allowed to use JSLint for good and not for evil.

The ECMAScript committee also thinks this is a good idea. The "use strict" pragma introduced in ECMAScript 5 not only restricts some language features like with, strict mode even changes/fixes the semantics of some parts of the language. Because of the semantic changes, ECMAScript 5 strict is a different language or at least a different dialect than ECMAScript 5 non-strict.

CoffeeScript, GoodScript, and ECMAScript 5 strict share common goals of keeping you away from the dangerous parts of JavaScript while giving you access to the valuable, safe parts. Each enforces these goals differently but they are enforced one way or another. You don’t get new syntax with GoodScript. It is already JavaScript and ready for the browser. You don’t get to use ECMAScript 5 strict because it is not available in all browsers yet and won’t be for years.

So CoffeeScript seems to be targeting a particular need of web development and maybe that is something other to-JavaScript compilers haven’t done or haven’t done well before.

CoffeeScript is also a reasonably thin skin over JavaScript. One consequence of this is that the compiled JavaScript code is reasonably easy to read and not brutal to debug (so I’m told.) This reduced debugging fear is contributing to interest in CoffeeScript.

CoffeeScript almost feels like a set of macros for writing JavaScript programs.

Since CoffeeScript compilers are in the hands of developers rather than the visitors to sites, you control which version of CoffeeScript you are using. You can upgrade at will. This also means CoffeeScript does not need to be standardized and go through the subsequent painfully slow growth of a standardized language. CoffeeScript can grow at the rate of its community’s imagination and desire. JavaScript standardization was essential to the success of the web but the same constraints do not apply to CoffeeScript.

Well then I’m going to invent my own language.

You can do this and it would be a great exercise. You’ll be able to call yourself a compiler writer which is pretty darned prestigious.

The danger of inventing your own language lies in the thinking that you can do better than JavaScript has done in the long run. Language design is hard and I bet your language will grow its share of unsightly hairs. Maybe not as many hairs as JavaScript but still. CoffeeScript hasn’t hit puberty yet but there are already signs that hair follicles may exist.

@maxsamukha

CoffeeScript: The way variables in outer scopes can be accidentally overwritten is fishy. How bad is it in practice?

You were so proud that your simple, readable compiled code was easy to debug. That will become harder as you realize the compiled code’s semantics aren’t quite what they were supposed to be in corner cases.

Idioms will appear in your language and someone will fork your compiler to do away with those idioms (unless your language happens to have macros.)

Enough with this nay saying. Go and write your own language right now. You’ll be a better programmer for it.

What’s missing from JavaScript the target language?

JavaScript is embarking on a new life as a compilation target. It is a capable target for many language features but it could use improvement. In his JSConf.US talk, Brendan Eich stated that one the goals for Harmony is to be a better target for to-JavaScript compilers.

Compiled JavaScript can run slower than hand-written JavaScript just like compiled C can be slower than hand-written Assembly (though not always.) Some inefficiency in compiled JavaScript is tolerable because JavaScript virtual machines are fast and the DOM is the bottleneck anyway. That said, some potential source code languages have semantics sufficiently far from JavaScript’s semantics that the compiled code is so inefficient that it cannot realistically be used in production web apps. There are already features in Harmony that will enable some of these languages to be compiled to efficient code and thus make these viable source code languages.

Proper Tail Calls

Programs in Lisp languages depend heavily on recursive calls to properly tail recursive procedures. The proper tail calls proposal in Harmony will allow these programs to be compiled to JavaScript without the inefficient trampoline technique currently necessary to avoid overflowing the call stack. Awesome! Let’s look at that in a bit more detail.

The following JavaScript is an example of mutually recursive functions which would work fine in Lisp but since JavaScript currently does not have proper tail calls, will overflow the JavaScript call stack when number is large.

function isEven(number) {
    if (number === 0) {
        return true;
    }
    else {
        return isOdd(number - 1);
    }
}

function isOdd(number) {
    if (number === 0) {
        return false;
    }
    else {
        return isEven(number - 1);
    }
}

isEven(100000); // InternalError: too much recursion

In the above code, a call to isEven(100000) isn’t complete and removed from the call stack until isOdd(99999) returns which isn’t complete and removed from the call stack until isEven(99998) returns and so on. That’s a lot of calls on the call stack! And there is no need for them all to be on the call stack. isEven(100000) doesn’t have anything intelligent remaining to do once it calls isOdd(99999) because the call to isOdd(99999) is the very last thing in isEven(100000). The call is said to be in tail position. isEven(100000) is just waiting to return the value returned by isOdd(99999) and a clever language can just pop isEven(100000) off the call stack and replace it with the call to isOdd(99999) thus saving space on the call stack.

With trampolines we can ensure that even in JavaScript the call stack doesn’t grow large. The following is just a sketch of how trampolines might be implemented and how isEven and isOdd might be compiled for a JavaScript interpreter that doesn’t have proper tail calls.

function bounce(ret) {
    while (typeof ret === 'function') {
        ret = ret();
    }
    return ret;
}

function isEven(number) {
    if (number === 0) {
        return true;
    }
    else {
        return function() {
            return isOdd(number - 1);
        };
    }
}

function isOdd(number) {
    if (number === 0) {
        return false;
    }
    else {
        return function() {
            return isEven(number - 1);
        };
    }
}

bounce(function() {return isEven(100000);}); // true

You can see the extra overhead of the bounce function which implements the trampoline calls is quite onerous. It creates closures for each continuation, doubles the number of calls, and must examine the returned value after each bounce; however, isEven(10000) does complete and is removed from the callstack before isOdd(99999) is called. The full computation completes in constant call stack space.

The bottom line is trampolines incur too much overhead. They incur so much overhead that when Rich Hickey created Clojure, his Lisp for the JVM, he decided his language could not have proper tail calls because trampolines were too expensive. That must have been a painful decision for someone who loves the Lisp family of languages.

The good news is that the ECMAScript committee has recognized this deficiency in JavaScript and has added proper tail calls to Harmony. This will benefit programmers writing directly in JavaScript and developers of to-JavaScript compilers.

Lambdas

Another strawman proposal not yet promoted to Harmony is the Block Lambda Revival which combines some new syntax with a new language construct called a lambda. A lambda is a callable thing, like a function, but it obeys Tennent’s Correspondence Principle. Tennent’s Correspondence Principle states that wrapping an expression or block of code in an immediate lambda should not change the meaning of that wrapped code. JavaScript functions are not lambdas and do not obey Tennent’s Correspondence Principle. For example,

function one() {
    return 1;
}

one(); // 1

is not the same when the return line is wrapped in an immediate function

function one() {
    (function() {
        return 1;
    }());
}

one(); // undefined

The syntax of the block lambda proposal for a lambda that takes two arguments and sums them is {|a, b| a + b}

Using the syntax of the block lambda proposal we can wrap the return line in an immediate lambda without changing the meaning.

function one() {
    ({||
        return 1;
    }());
}

one(); // 1

Thanks to lambdas obeying Tennent’s Correspondence Principle, the return still means return from the function one.

You may ask “Who cares about this computer science-y stuff?” to which I reply “Did any of that macro business seem useful?” because lambdas are a fundamental building block in the code generated by many macros. And since lambdas play nicely with JavaScript’s return, arguments, and this, lambdas would be a valuable addition to the language for compiler writers.

I’m focusing on the JavaScript-as-a-target aspect of the block lambda proposal. If you plan on writing in JavaScript forever after, the proposal has other benefits for you too that don’t matter to compiler writers.

The block lambda strawman has not yet been promoted to Harmony and so currently doesn’t have a path into ECMAScript 6 and browsers around the world. The standardization process is slow. Maybe there will be another decade stall in evolving the language like there was after ECMAScript 3. Maybe the next edition of ECMAScript will be the last edition. Better to get the best stuff in there than hope to get it in later. If you care about the future of JavaScript and think lambdas would be a benefit to the language then let the ECMAScript committee know by sending a message to the es-discuss mailing list in support of the block lambda proposal. Powerful, orthogonal language features like tail calls and lambdas which have no efficient workarounds may be the most important additions in the next edition of ECMAScript.

What’s missing from the browser?

The browser can help JavaScript succeed in its new life as a compilation target. The browser interprets compiled JavaScript and complains when the compiled code has an error. The error messages contain line numbers in the compiled code but you want to know the line number in source code.

The Mozilla crowd has an open ticket and a dev tools project to ease debugging source code by mapping compiled code lines to source code lines. Since you control the browser in which you primarily develop and test, you can use this feature as soon as it is ready.

Somewhere I read that the Webkit folks are developing similar source code debugging assistance but I cannot find any concrete evidence.

Polyglot

JavaScript’s monopoly in the browser has meant front-end programmers all speak the same language. This has given the community a lingua franca enabling good communication and code sharing. We are now headed for a polyglot future where you choose the language(s) you want to learn and use for developing browser applications. Maybe you are only using a few JavaScript language extensions via Traceur and compiling templates to JavaScript with Mustache. This still means that the CoffeeScript programmer won’t understand your source code immediately.

This divergence was inevitable as it has happened on all previously successful platforms. There have been multiple languages for building native applications almost forever. C is still common but C++, Objective-C, and many other languages are available. The JVM was intended to run programs written in Java but clever developers have added other languages like Clojure and JRuby as options. Microsoft recognized what seems to be a human psychological need for a variety of languages and developed its .NET CLR platform for multiple languages from the beginning. Programs written in Basic, C#, IronPython, etc can all be run on the CLR.

Barriors to communication in the front-end community are not new anyway. A developer using Dojo cannot immediately understand the source code of an application written with jQuery or YUI. There is a plethora of libraries, some very different, that add the ideas of class-based inheritance to JavaScript. So we already have our barriors even within JavaScript.

Having multiple source languages will increase the barriers in our community. Programmers will still need to know JavaScript, at least for a while, but in a few years they may know other source languages better then they know JavaScript.

Choice is a blessing and a curse.

Summary

It is great having the opportunity to watch JavaScript’s transition to a new life as it happens. It’s impossible to say which languages will end up winning market share in the to-JavaScript compilation but it is sure to be interesting. CoffeeScript is gaining momentum now but I think many other successful source code languages will follow.

What do you think will happen?