Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

Comments for Google & the Future of JavaScript

Seriously Alex, JavaScript dosent need class and developers need to stop using functions as constructors and leverage ES5 additions.
by Benoit at
I prefer a pythonic syntax rather than a Java based one. pythonfiddle has object oriented CSS and a Python to JavaScript compiler.
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.

"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.

by DigDug2k at
>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"

by karl at
>> karl -> 'I usually prefer someone who comes to me and says...we will work together.'


by john at
I like turtles.
by Shaun N at
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).

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.

by Joe WebDev at
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.
by ʚɶʔʫɒəɩɬɗɖɻʩɒʥəʩɴʗɤʠ at
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.

"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!

by Astero at
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.
by Tyler at
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.
@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.

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.


by Dave Hampton at
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 = )
by alex at
@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.

by karl at
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.

by Joe WebDev at
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.

by Liam at
@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.
by Liam at
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 ?
by MJ at
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.

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.

[1] [2]


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.

by alex at
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.
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.