There's a lot of "don't turn it into Java!" in the comments on my last post, and I feel it needs a response -- and not because I think there's anything to like about Java's class or type systems (perhaps that they exist at all? I'm torn on even that).
Lets look at some possible ES.next code and walk through how it relates to today's equivalent JS:
module widgets {
// ...
export class DropDownButton extends Widget {
constructor(attributes) {
super(attributes);
this.buildUI();
}
buildUI() {
this.domNode.onclick = (e) -> {
// ...
};
}
}
}
Ignoring the semantic improvements of Harmony modules over the module patterns we're using today, we can see a pretty straight-up de-sugaring of that to today's JS with an emphasis on the many and varied uses of the word function:
var widgets = (function(global) {
// ...
function DropDownButton(attributes) {
Widget.call(this, attributes);
this.buildUI();
}
DropDownButton.prototype = Object.create(Widget.prototype, {
constructor: { value: DropDownButton },
buildUI: {
value: function(e) {
this.domNode.onclick = function(e) {
// ...
}
}
}
});
})(this);
What you should take away from this isn't that we're turning JS into Java, it's that we're making it easier to read, AND THAT'S ALL. Once more for effect: what class means in ES6 is function. Or at least one of the things you currently do with function.
Better yet, we're blessing a single pattern which you can use with old-style classes just as easily as you do today. I'll leave it as an exercise for you to name all the different class patterns and systems that do nearly the same thing in slightly incompatible ways today. It's a very long list.
If you like JS, and you like functions + prototypes (I do!), you have nothing to fear from the sugar we're adding in ES6.
Update: A lunchtime conversation here at DojoConf today reminded me of perhaps the largest thing that this new system doesn't do; ES.next aren't tied to a Java-like type system. Many of the conjoined fears of Java come from the very real pain created by a strict, nominal type system, and nobody in the committee is proposing a mistake like that -- least of all me.
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 ES.next 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 ES.next 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.
The title says it all: you can now put a link like this in your app and users will get the stable version of either admin or non-admin Chrome Frame, depending on what rights they have on their system:
The redirect=true ensures that once the the install completes, users are automatically redirected back to your site (slick, huh?) and the conditional comments keep the prompt from being shown to folks with modern browsers.
At the top of your document you'll still need to add the header or meta tag to your apps/pages to opt-in to Chrome Frame rendering:
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
Couldn't be easier, and if you're using a starter kit like the excellent HTML5 Boilerplate, it's already in there!
Nearly forgot...
So, why, you might ask, did it take this long from showing user-mode at I/O to get this to the the world?
Good, if convoluted question. The answer is long, complicated, and involves a harrowing-yet-seamless transition of hundreds of millions of Chrome installs to a new installer infrastructure, but I'll skip to the punch line: millions of users won't even have to download Chrome Frame to install it. Chrome Frame's quick-enable mode is available on every system that has Chrome installed -- even if Chrome isn't being used as the default browser -- which means that for many of your users installing Chrome Frame can be nearly instant. No download, no traditional install process. Just "activate", "accept" and those users are on their way back to your site to experience the HTML5 goodness you've built.
If you're contemplating adding a prompt to your site or app, know that you're not alone either. As promised, GMail is asking all IE 6 and 7 users to upgrade or install Chrome Frame. A growing list of sites like Angry Birds couldn't have been built without assuming Chrome Frame as a solution to "the IE problem".
Chrome Frame is all about turning HTML5 from a "someday..." prospect to a reality for your very next project, even if you're deploying to users and organizations that can't join us here in the future by adopting modern browsers. Only the trailing edge has been standing still, and now that we're all free of it I can't wait to see we build.
The web is about to get better a whole lot faster.
Update: Erik Wright informs me that we don't even need the prefersystemlevel now! Post updated to reflect this.
In a half hour, I'm going to be on the Web 2.0 Expo Browser Wars panel with a cast of incredible folks. A couple of weeks back, I had the privilege of doing something similar on a browser panel expertly moderated by Arun Ranganathan.
As a part of that panel, Brendan, Lars, Arun, John, and I all agreed to post a list of links to demos and such that showed off what our latest browsers are doing. Belatedly, here goes:
The browser wars panel is designed to be a discussion, so we didn't use any kind of presentation media. So here's a list of demos and resources so that you can learn more about stuff we talk about. Pictures speak volumes about what gets us excited about the web, anyway.
HTML5, CSS, and JavaScript Demos
WebGL Demos
To get maximum mileage out of these, you'll want a fast PC with the latest Chrome or Firefox.
Resources
I'm headed to Austin soon for spring break SxSWi, and this year I'm lucky and grateful to be representing Chrome on the always-packed browser panel (more usable Lanyrd talk page here). The context for this year's panel is interesting to me -- a couple of years into a renewed era of browser competition, users have more choice but developers are still struggling with the same landscape, even as HTML5 starts to materialize as the platform of choice for most apps -- even the ones wrapped up in native wrappers to jump the various app-store-form distribution hurdles.
It's good to see MSFT belatedly trying to put IE6 out to pasture, but what about IE 7? Or 8? Lets take stock of where we really are and where we're likely to be in the next couple of years. First, remember that there's no IE 9 for Windows XP -- an OS that's currently the most popular in the world -- and no matter what happens with IE 6, IE 8 is the end of the upgrade road for XP. Unless you think half of the world's computers will be replaced/upgraded in the next couple of years, it seems likely that IE 8 will be with us for the foreseeable future.
And what about the folks who do get IE 9? Well, so far, there's nothing to make me believe that the uptake rate will be anything better than the IE 8 transition; a process which has taken 2 years to give ~30% of the market the latest version. If anything, we should expect that rate to be retarded somewhat by the XP hurdle.
MSFT's browser replacement rates bear understanding because they're the most popular and suffer from the longest half-lives. That is to say, the time it takes for an old version of IE to decay in the wild is much, much higher than for other browsers. Some part of this is surely due to sheer market share, but not all of it. The XP hurdle, for instance, is a form of structural drag on uptake rates -- a flaw that browsers that aren't tightly tied to OSes don't suffer from. For web developers, I dare say that half-life of popular browsers matters much, much more than the current or trending market share since it's predictive of our potential for browser improvement in the near future. It's one thing to get the new shiny, but how long will it take you to install it? If the shiny is old and dingy by the time it's in place, what good is that? It's this lens that makes browser market share stats interesting to me; i.e., what percentage of the web's users will get the new features soonest? 'Cause those are the folks we can start building super compelling content for.
The average half-life of the majority of browsers in the wild also gates the rate of progress in standards. When the process is working well, bugs in browsers or pre-standards implementations of features aren't a permanent features of the landscape. Instead, they're the understandable and inevitable result of a process that prioritizes implementation experience and iteration over raw compliance with an academic spec that may or may not actually get it right on the first go 'round. But that iterative, feedback-rich process only works when browsers iterate quickly and web developers can target the future without thinking so hard about the past, else progress simply turns into something to resent and distrust. That's good for no one, and a shorter half-life is the key to making progress more than just a spec-tease.
I'm personally hopeful that when IE 9 is finally RTM'd, that it includes some provisions for shortening its life expectancy in the ways that Chrome and Firefox have through aggressive auto-updating. Getting IE 9 out to the world will be a good thing, but only if it happens quickly and if IE 10 can follow it even faster.
There's obviously a lot more to talk about at the browser panel -- Chrome 10 just launched with Crankshaft, for instance -- but the fact that nearly every Chrome user will have those improvements this week and that if you're building a Chrome Web Store app, you'll get to target those improvements nearly instantly seems like the biggest, most interesting change from where we were just a couple of years ago.
Older Posts
Newer Posts