Google & the Future of JavaScript

There’s very little public information yet about Dart (nee, Dash), and as I’m not on Lars’ team I can’t comment about it. More details will be forthcoming at the GOTO session next month. I’ll also be at GOTO, speaking on JavaScript and the state of the web platform.

Making the rounds is an accidentally leaked early draft of notes from a meeting last year that discusses both Dart and JavaScript. I work on many web platform-related things at Google, including serving as a representative to TC39, the body that standardizes the JavaScript language. I wasn’t at the meetings having previously committed to presenting at FFJS, but my views were represented by others and my name is on the document. As I said, though, it was a draft and doesn’t reflect either the reality of what has happened in the meantime or even the decisions that were taken as a result. And it certainly doesn’t reflect my personal views.

So what’s the deal with Google and JavaScript?

Simply stated, Google is absolutely committed to making JavaScript better, and we’re pushing hard to make it happen.

Erik Arvidsson, Mark Miller, Waldemar Horwat, Andreas Rossberg, Nebojša Ćirić, Mark Davis, Jungshik Shin and I attend TC39 meetings, work on implementations, and try to push JS forward in good faith. And boy, does it need a push.

Erik and I have specifically been working to focus the TC39 agenda away from syntax-free, semantics-only APIs (Object.defineProperty, anyone?) which might be good for tools, compilers, and frameworks but which are hard for day-to-day use.

Through Traceur and other efforts we’ve been socializing the idea that the one thing the committee can exclusively do — and should do more of — is to carve out syntax for commonly exercised semantics. Seemingly small things like the class keyword as sugar for the constructor function pattern, or a shorter syntax for functions are big improvements, if only because it’s TC39 that’s making them. Syntax can end battles over common patterns and help you say what you mean, and JS is overdue for some of this. Larger but more subtle things, like agreement to use pragmas as a way to enable the process of progress in a compatible web, are even more exciting to me. Even proposals that haven’t made it through like Scoped Object Extensions and deferred functions have been fought for by us because we desperately want JavaScript to get better. We’re big fans of much of the work coming out of Mozilla for the same reason — in particular Dave Hermann’s excellent modules proposal. Together, these are going to do much to help give modern JS some “backbone” in the near term. I’m proud of what we’ve accomplished in TC39 over the last year, and while I hoped for more, the result is an that looks like it’ll embody many of the things I feel are currently missing. The day-to-day practice of writing JS is going to change dramatically for the better when arrives.

But it’s not the end — not by a long shot. Classes will give us a humane, interoperable inheritance syntax, but it leaves composition unaddressed by syntax. I’m hopeful that we bless traits in future versions, removing the use of inheritance in most cases. Similarly, I think we can find a way to repair “this” binding foot-guns with softly-bound “this”. Repairing the shared-prototypes issue, either through DOM or through something like Scoped Object Extensions, can and should be done. And once we have all of this, the stage will be set for a flexible, advanced type system that does not need to be all-or nothing and does not need to be hobbled by the ghost of C++/Java’s inflexible nominal-only types. That’s the dream, and we’re not shying away from it.

It’s hard to square this sort of wild enthusiasm for “raw” JavaScript with what’s in the leaked memo, and I can only beg for some amount of understanding. As committed and enthusiastic as I am about the prospects for JavaScript, others are just as enthused about Dart. Google is big, can do many things at once, and often isn’t of one mind. What we do agree on is that we’re trying to make things better the best we know how. Anyone who watches Google long enough should anticipate that we often have different ideas about what that means. For my part, then, consider me and my team to be committed JS partisans for as long as we think we can make a difference.

Reality Check

There are risks, of course. TC39 is long on seasoned language design skill and short on webdev experience, meaning that many things that Erik and I may take for granted as pressing problems need to be explained, sometimes to an incredulous audience. The flip side risk is that naïve solutions may have better alternatives that seasoned language hands can quickly spot and that simple answers have non-obvious risks or preclude movement in other important areas later. It’s good, then, that the committee is working well and is taking appeals to developer productivity seriously.

Whatever you might think about programming languages for the browser, let me assure you of one thing: your problem isn’t the language. Not really, anyway. We’ve made good progress in the last year repairing some of the seams between JS and DOM, and Cameron McCormack has helped us drive a new version of WebIDL that correctly explains DOM as a reasonable prototype chain. But it’s only the beginning. The DOM is in terrible shape, and not due to implementation differences. The malign neglect of IDL-addled designs, the ghosts of dead-end XML experiments, and endless cruft will plague any language that sidles up to it. Until we get a real Component Model, a better CSS OM, and some sort of a pragma for DOM that allows us to fix DOM’s abhorrent JS bindings, we’ll continue to be hostage to C++ APIs inartfully wired up to an incredibly dynamic language. And that’s to say nothing of the pressing need for better CSS, animations, and a built-in data-binding/templating system. When the platform doesn’t provide it, today, we get it from JavaScript. But that’s not where the solutions always belong.

Let me put it another way: when you find yourself thinking “man, JavaScript sucks,” remember that it’s only painful in large quantities. And why do you need so much of it? ‘Cause the DOM, CSS, and HTML standards are letting you down. Any language wired up to the browser today is subject to the same fate, and the insane reality that these things are specified under different roofs in processes that aren’t subject to the popular will of web developers. Python doesn’t have it’s DOM APIs decided by the W3C, they borrow the idiomatic ElementTree API from within their own community. WebIDL is an artifact of a different time that has a tenuous relationship to idiomatic JavaScript, the CSS-OM barely exists, and DOM apologists are doing more harm than any of JavaScript’s warts ever have. We can fix these things, of course, and here at Google we’re trying – in good faith – to work in standards to make them better. But the bottom line is that the language isn’t the problem. I repeat: the language isn’t the problem, the platform is.

The only thing that’s going to replace the web as universal platform is the next version of the web. Those of us working on Chrome believe that to the core and feel a deep urge to make things better faster. We might not always agree on the “how,” but we all believe that we can’t do it alone.


  1. Posted September 12, 2011 at 6:20 pm | Permalink

    >The only thing that’s going to replace the web as universal platform is the next version of the web. Those of us working on Chrome believe that to the core and feel a deep urge to make things better faster. We might not always agree on the “how,” but we all believe that we can’t do it alone.

    “Make things faster” is a possibility. Though it depends on what we want. Faster is not always an improvement. It really depends on the circumstances, the context.

    “Make things better” is what makes me stop any discussion. When someone is starting or closing a discussion by “This would be better”, I go away. Better than what, for who, in which community, for which interests? And that is maybe part of the arrogance or misunderstanding into the discussion.

    I usually prefer someone who comes to me and says: “It will not be perfect, it will not be the best solution, but we will **work together**”

  2. john
    Posted September 12, 2011 at 7:01 pm | Permalink

    >> karl -> ‘I usually prefer someone who comes to me and says…we will work together.’


  3. Shaun N
    Posted September 12, 2011 at 9:13 pm | Permalink

    I like turtles.

  4. Posted September 12, 2011 at 9:21 pm | Permalink

    If I had to pick one thing that sums up everything that is wrong with the current web standards work at the W3C, it’s WebIDL.

    It’s entirely detached from reality yet it’s the language used to define new standards. It succeeds greatly in creating barriers to entry for web developers that would want to even read standards that are in development.

    I’m mostly invested in node.js these days. One great thing about node.js is that it’s trying to solve the right problems. It’s not concerned with the language, in our opinion the language is mostly fine and what isn’t great we’ll fix ourselves.

    But, as new W3C standards grow we would *like* to implement them in pure node.js and share some commonalities across platforms. It would make my life much simpler to write PouchDB for IndexedDatabase and have a compatible API in node.js.

    But at the end of the day it’s actually easier to write an entire parallel implementation directly on top of leveldb than to try and implement the IndexedDatabase spec. Just reading it gives me a headache, and it’s not because it’s hard problem, it’s just in a ridiculous language (WebIDL).

  5. Joe WebDev
    Posted September 12, 2011 at 9:59 pm | Permalink

    Guys, please leave javascript alone, she is a language!!11oneone11!

    Seriously though, push for standardized bytecodes, make it work. If for some reason you see -> as an improvement on “function” then clearly you guys shouldn’t be touching JS at all.

    Go get bytecodes and you can write all the languages you want for yourselves, deal?

    I agree that the DOM and CSS interfacing sucks – a really handy thing to have would to be able to defer reflows and repaints, guess what? Thats where RIA’s spend orders of magnitude more time. DOMfragment double-buffering can mitigate some of that, but it isn’t practical for ‘bubbling’ change propagation or when needing to alter content which may be dispersed throughout the page.

    I don’t know whose problems you are trying to solve, but it certainly doesn’t seem to be of actual working webdevs in the trenches. Most of the things that you refer to are solved problems.

    Give us WebCL, give us processing resource abstractions ala C++ AMP, give us 64bit integers, leave the foot-guns on your way out.

  6. ʚɶʔʫɒəɩɬɗɖɻʩɒʥəʩɴʗɤʠ
    Posted September 13, 2011 at 2:07 am | Permalink

    So, what about the future of Google’s Closure tools? They’re used for all of their web applications, but there doesn’t seem to be much community traction behind.

  7. Posted September 13, 2011 at 2:27 am | Permalink

    I don’t know why changing the syntax is called improvement. This is the javascript and we should accept it. JS is popular and even went to server side by nodejs because it is JS with this beautiful syntax.

    Google is big but Javascript belongs to all developers not Google. if you think you have better ideas, then create a language and a compiler to compile your better language to Javascript! It is way better for all of us! Don’t make another JAVA out of javascript.

  8. Astero
    Posted September 13, 2011 at 5:37 am | Permalink

    “I repeat: the language isn’t the problem”?
    Why Google’s GWT use java and the compile to javascript if the language is not the problem? Why jquery is the reason why we see web apps now and not years ago?

    Javascript 2, is already here with classes and strong typing, ECMA4 , ECMA5 or whatever is called now. And you can use it on server side too, since it’s supposed to be faster.

    Mozilla and Google prefer to showoff pointless WebGL instead, cause it’s not going to be on IE.

    I feel this new thing it’s going to end up like CSS a designing tool made by really smart people that sadly doesn’t do design.

    Corporations… Web development is a nightmare for no reason, it could be a smooth process if only we … make an HTML5 logo! Yea!

  9. Tyler
    Posted September 13, 2011 at 7:31 am | Permalink

    Karl is affraid of change it sounds like. This article was written from one mans perspective and I will take it as such. All of this sounds like you and others are thinking about the future of the web with sound mind but I agree all of this is going to slow. If anyone is holding you back fork development and have two ideas on how things should be done, the stronger product will win over the market. If Microsoft doesn’t want to create webGL and the market wants it then no one will use Explorer, it’s ok. The same goes for any of the features anyone else is talking about. Just focus on creating killer features and move forward forgetting about everyone agreeing. You already dumped many of Adobe’s idea it’s time to dump a few more and finish up this new spec.

  10. Posted September 13, 2011 at 8:40 am | Permalink

    Interesting thoughts Alex, I completely agree. It’s actually quite amazing how many moden web devs still don’t get that the DOM isn’t JavaScript. I work with so many people who will come into my office and exclaim, “JavaScript sucks!” When I go and look at their problem 9/10 it is a problem directly related to the DOM, the other 1/10 times it’s because JavaScript has to bend over backwards to fix the DOM or add to it’s poor implementation.
    I have almost never seen a person with a legitimate problem that was the direct result of the language’s limitations. You almost never run into them until you start doing serious application development (Gmail scale or higher). Keep up the good work.

  11. Posted September 13, 2011 at 10:22 am | Permalink

    @Joe WebDev: Completely agree.

    Leave classes the hell outta JavaScript. I wish people would understand that it doesn’t follow Classical inheritance. So there is no need to make it look like it does. JavaScript is Prototypal, which is awesomely powerful. If you take the time to learn how to use it.

  12. Dave Hampton
    Posted September 13, 2011 at 10:38 am | Permalink

    I don’t think rewriting the inheritance structure of a prototypical language to a classical one is a smart move at all.

    It seems as though many, perhaps Google included, prefer classical, have a hard time getting their heads around prototypical and want to change it.


  13. Posted September 13, 2011 at 10:45 am | Permalink

    It’s unfortunate that y’all are seeing “class” and not reading the *actual* proposal. Looks like I need to write another blog post on this = )

  14. Posted September 13, 2011 at 11:08 am | Permalink

    @tyler. Quite the opposite. :) I’m happy about changing things if we are doing it in the open. Let’s not be naive. What we are talking about here is for the business interests of each companies involved.

    Though I have a hard line on power. If the goal is to create an **open ecosystem**, then we need to go of our way to work together. Yes working together is slower, but that it is a feature or a benefit. If the goal is to dominate the market, then there is no rule, and qualifying the work as open is a mere marketing tool.

    And yes as you noticed, I’m not into “the stronger wins and others die” ;) let’s call it philosophical views on life.

  15. Joe WebDev
    Posted September 13, 2011 at 12:17 pm | Permalink

    Alex, can you tell us what the perceived benefit of -> for functions actually is?

    The difference in typing speed is much less than the reduction in characters would seem to indicate, it also forces a wider range of motion.

    If the issue is with nesting in callbacks, please just educate people on things like named functions and parameter passing and context binding.

    As for ‘Class’, I am not particularly bothered – but you should realize that this is a non-issue for most web devs, we already have sugar to take care of this.

    If people can’t be bothered to look at what the ecosystem already provides, why should the fundamental underpinnings of that ecosystem be fiddled with to cater to them?

    There are actual, important, things that we need to be able to build bigger and better things – a modified syntax isn’t one of them.

  16. Liam
    Posted September 13, 2011 at 4:51 pm | Permalink

    Great point about the platform being the issue. Some people seem to miss that, and get frustrated when the language is changed fast enough.

    Also I agree, Scoped Object Extensions would be a major benefit.

    Being limited by the platform I’ve set up a project allowing for a form of Scoped Object Extensions in IE6+,Firefox,Safari,Chrome and Opera. Basically it allows for you to create a namespace a functions that you can call on objects. You can read more about the syntax here
    and the actual project here

    I hope to hear more about dash.

  17. Liam
    Posted September 13, 2011 at 7:32 pm | Permalink

    @Joe I do agree that the -> provides little addition because of the lack of an ending delimiter and awkward typing, but +1 for going for a nicer syntax. Having to call Object.defineProperty with all of the options is absolutely crazy, along with a softly bound this is occasionally annoying while also being really powerful.

  18. MJ
    Posted September 14, 2011 at 5:46 am | Permalink

    Given how piss poor Google is at sticking with things, why don’t you stay away from JS and just go abandon some more of your projects ?

  19. Posted September 14, 2011 at 9:32 am | Permalink

    I’ve been coding almost exclusively in JavaScript for the past 5 years.

    Leave the language alone, please! It’s a thing of beauty as-is.

    If you want to bastardize the language so it looks like Java, feel free to implement some sort of preprocessor in the browsers that can compile Java into JavaScript. (Replace “Java” with the language of your choice).

    In fact, a C-like preprocessor with conditional compilation and the like would be great for server-side.

  20. Posted September 14, 2011 at 12:36 pm | Permalink

    It’s a shame that block lambdas [1] won’t make it into They are concise and they fix the dynamic “this” problem:

    – Methods: dynamic “this”, use “function” or the compact method syntax proposed by Allen Wirfs-Brock [2].

    – Non-method functions (especially as arguments): lexical “this”, use a block lambda.

    Everyone will automatically do the right thing.


  21. Posted September 14, 2011 at 2:04 pm | Permalink


    Block lambdas don’t “fix” dynamic this, they exacerbate it somewhat since they have to be intermixed with plain-old-functions which aren’t bound in any way.

    Mark Miller, Erik Aarvidson, and I have spent much time over the past year trying to tease apart the concerns here, and this is what has gotten me to “soft binding”. If block lambdas or short functions use soft binding for the lexical “this”, they’ll fix some of the common cases (as you hope), but not defeat “.call(scope)” invocation and therefore avoid breaking one of the most fundamental contracts in the language. Class methods can use a similar soft-binding approach. Over time, that provides a transition strategy. But block lambdas aren’t the whole shebang.

  22. Posted September 14, 2011 at 5:59 pm | Permalink

    Have you described your idea of how to fix this somewhere? My favorite solution is still how Python does it: “this” becomes an explicit parameter of a function. Alas, that won’t fit into the JS universe.

  23. Luis González
    Posted September 15, 2011 at 6:08 am | Permalink

    It all comes down to a philosophical difference, the endless battle between democracy or dictatorship. What’s better? All depends…
    When the dictator is someone of our liking, it’s the best of the situations, because he has all the power to do what we want him to do, without delays. But when he is tyrant, there’s no way to get rid of him other than a bloodshed.

    Python’s “Benevolent Dictator for Life” is one of the best things of python’s community. Everybody seems to love him and nobody dares to criticize his judgement. But many wonder what would happen if Guido was hit by a bus… What would happen next? What if the sum of all powers land in hands of an incompetent dictator?

    On the other hand, a committee driven evolution is a tedious, exhausting and sometimes demoralizing path, but it gives guarantees that no crazy tyrant will make our world miserable. And in the end, we will all live peacefully, although not entirely happy.

    In my opinion, and when talking about open source projects, the best results are achieved when a sole champion gets a first prototype of a working idea, gathering a loyal community of followers identified with his philosophy, and driving the project to wide adoption and maturity.

    Will this be the solution the whole universe needs and wants? Only the quantity of loyal followers will tell. If not, it will simply die.

  24. Posted September 16, 2011 at 9:14 am | Permalink

    There is only one problem: Javascript is too subtle for beginners and they get in trouble. See the “Bad parts” Doug Crockford talks about.

    So lets piss all over JS to make it something that it isn’t: Easy.

    -1 for me, JS is a success and most folks building important systems are fine with it as it is. Please leave it alone.

  25. Benoit
    Posted September 24, 2011 at 10:29 am | Permalink

    Seriously Alex, JavaScript dosent need class and developers need to stop using functions as constructors and leverage ES5 additions.

  26. DigDug2k
    Posted September 27, 2011 at 2:32 pm | Permalink

    “We might not always agree on the “how,” but we all believe that we can’t do it alone.”

    The “how” is exactly the argument here. And the answer in the Dart memo is basically “We’ll do it alone”. I don’t see how you’ve addressed that at all here, except that the world is supposed to take your word that you aren’t… even though you all admit that you’re working on something and that you’re working on it alone.

  27. Posted November 25, 2011 at 3:39 pm | Permalink

    I prefer a pythonic syntax rather than a Java based one. pythonfiddle has object oriented CSS and a Python to JavaScript compiler.

9 Trackbacks

  1. […] Google & the Future of JavaScript | Infrequently Noted – Simply stated, Google is absolutely committed to making JavaScript better, and we’re pushing hard to make it happen. […]

  2. […] Google & the Future of JavaScript (Alex Russell) […]

  3. […] Russell, a Chrome programmer at Google, cautioned yesterday in a blog post that Google is big enough for many opinions and that the memo “was a draft and doesn’t […]

  4. […] Russell, a Chrome programmer at Google, cautioned yesterday in a blog post that Google is big enough for many opinions and that the memo “was a draft and doesn’t […]

  5. […] the email as helping push a mission codenamed “Harmony” to help develop Javascript – has said about the email: “[It w]as a draft and doesn’t reflect either the reality of what has […]

  6. […] corporate forkwits, genuine frustration with the path of progress, evil play for ownership. Read Alex Russell’s commentary on this (Alex is the creator of Dojo, now an employee of Google) for some context. I have to say, We Will […]

  7. […] credited with authoring the e-mail is Lars Bak, who is scheduled to speak at GOTO about Dart. A blog post by Google developer Alex Russell, who’s name is also on the e-mail, unofficially confirms […]

  8. […] including Brendan Eich himself, who’s been quite active on Hacker News. Google’s own Alex Russell has also blogged about the issue and has distanced himself from the leaked comments, while also […]

  9. By It may be interesting on October 12, 2011 at 10:19 am

    […] One thing is clear, though. No matter what Dart turns out to be, Google's commitment to JavaScript (the lingua franca of the web) is strong. +Alex Russell has a great write up on how Google is continuing to work hard with the JavaScript community: […]