HTML 5 is the fifth major revision of the core language of the World Wide Web and was pioneered in 2004 by the Web Hypertext Application Technology Working Group (WHATWG). Although the specification is ongoing work, parts of HTML 5 are already implemented in browsers like Safari 4 beta.
In addition to specifying markup, HTML 5 exposes several new scripting APIs:
Amongst the new features squarely targeted at application developers, HTML 5 introduces a number of new Javascript APIs. These can be used in conjunction with corresponding HTML elements and include:
- A 2D drawing API which can be used with a new canvas element for rendering graphs, game graphics, or other visual images on the fly.
- An API that allows a web application to register itself for certain protocols or MIME types.
- An API that introduces a new caching mechanism to support off-line web applications.
- An API for playing video and audio which can be used with the new video and audio elements.
- A history API that exposes the browsing history and allows pages to add to it to facilitate better back-button support in AJAX applications.
- Cross-document messaging which provides a means by which documents can communicate with each other regardless of their source domain, in a way designed to prevent cross-site scripting attacks.
- A drag & drop API to use in combination with a draggable attribute.
- An editing API to use in conjunction with a new global contenteditable attribute.
- A new network API to enable web applications to communicate with each other on local area networks, and to maintain bidirectional communications with their originating server.
- Client-side persistent storage with JavaScript APIs for key/value pairs and support for embedded SQL databases.
- Server-sent events in combination with the new event-source element which will facilitate persistent connections to remote data sources and largely eliminate the need for polling in web applications.
InfoQ recently conducted a virtual panel via email regarding how the JavaScript frameworks will evolve in order to take advantage of these new APIs. The panel featured representatives from some of the most widely deployed projects that deal with client-side JavaScript:
- Dylan Schiemann, CEO of SitePen and co-creator of Dojo
- Matt Sweeney & Eric Miraglia, YUI engineering team
- Andrew Dupont, core developer of Prototype
- Thomas Fuchs, creator of script.aculo.us, and core developer of Prototype and Ruby on Rails
- David Walsh, core developer for MooTools
- Scott Blum and Joel Webber, GWT lead developers
Below you will find the questions asked and each participant's answers.
InfoQ: With HTML 5 still being a work in progress, not many developers are familiar with the new features that it brings. What features do you find most noteworthy for web developers?
Dylan: HTML5 is a very large topic. Many of the features that we find valuable are things that you already find in toolkits like Dojo. For example, richer form controls with native implementations are promising including multiple file uploads, as well as data attributes so people won't complain about Dojo using allowed but impure custom HTML attributes. Peter Higgins recently wrote a Dojo Parser patch in 1KB of code to support this feature once browsers add it. That said, the single most interesting feature to me is the WebSocket which was proposed by Michael Carter and first implemented with an API shim by Orbited. WebSocket is highly useful for Comet applications, and can be thought of as a web-safe TCP Socket.
Matt & Eric: HTML 5 contains some groundbreaking building blocks for programmers who think of the browser as an application canvas, but in so doing it over-reaches the realm of document semantics and extends into the realm of the DOM API -- another aspect of the ecosystem that needs attention, but not necessarily as part of the HTML spec. Our preference would be to see the HTML 5 spec confine itself to the enrichment and refinement of document semantics while leaving the behavioral APIs to be treated by other specifications.
In general, developers should be aware of the following HTML-related features provided by HTML5:
- Deprecation of presentational elements and attributes
- More semantic elements
- More input types and semantics
- Custom data attributes
Developers are seeing more attention paid to the DOM API aspects of HTML 5, and indeed some of these, if ultimately codified, will increase the depth of our toolkit in important ways. The early uptake by browser manufactures of a 2D drawing API (via the Canvas element) and the client-side storage APIs have generated a lot of interest already -- and that interest is directly related to browser manufactures having prioritized their implementations prior the spec being finalized. But there are a host of other important changes being proposed in the current draft, including:
- Iframe sandboxing
- "getElementsByClassName()" support
- "classList" API
- Audio/Video (via Audio/Video element) API
- Offline web apps API
- Editing (via contentEditable attribute) API
- Cross-document messaging API
- Server-sent events API
HTML 5 tries to tackle a lot of big problems, and it goes well beyond what we've listed above.
Andrew: Man, there's stuff in there for everyone. The "web storage" stuff (client-side database) is going to be huge - a number of sites are putting it to good use already. The new form controls (née Web Forms 2) have been in the spec since the very beginning and I still can't wait for them to get implemented. Server-sent events are going to make it possible to do pure "push" applications instead of relying on incessant Ajax polling or a brittle Comet connection.
I also like the custom data attributes, even though it's a minor feature compared to the ones I've listed.
Thomas: Next to to offline features (mostly the persistant storage), I find the VIDEO and AUDIO tags the most important addition, as there finally is a way to do it without the OBJECT and EMBED pain. Of course it will take a while until this is supported everywhere, but still this is a huge step into the right direction, plus all the standardization of informal standards should lead to general better browser behaviour. A hidden gem is the ability for web applications to register protocols and media types so they can become default applications, just like desktop apps (but there's a lot of hurdles to overcome here from a UI point of view, as Joe User doesn't understand what a 'protocol' or 'media type' is).
David: No HTML 5 feature is too noteworthy unless there's wide support for them all. Concepts may be worth emulating, but using the native version of a specific feature when few browsers support it means trouble. This is why we're not using querySelectorAll: the different implementations by browser vendors could present more browser-specific hacks than simply avoiding QSA all together.
Scott & Joel: The things that I find most exciting presently in HTML5 are those features that can be used right now, without requiring developers to build a completely different version of their app. The database and application-caching APIs are particularly interesting, because an app can realistically support both online- and offline-modes. They're also a huge boon to mobile web developers, because they provide a lot of leverage in dealing with incredibly slow and flaky mobile networks.
I'm also excited by the other HTML5 features, such as <canvas>, <audio>, and <video>, that unlock new functionality that currently requires plugins to support. These tags aren't yet universally supported by the major browsers, but as adoption spreads so will their use.
InfoQ: How do you think current JavaScript frameworks will have to evolve in order to facilitate the new features like built-in media and offline support, as well as advanced communication with server-side processes? What is a rough roadmap for your project?
Dylan: Our goal is to always create things that fill-in the browser gaps. We hope that things we do become irrelevant over time (e.g. normalizing event systems or QuerySelectorAll). We're finding that in some cases, we get to remove code over time, but users of Dojo don't notice a difference as they can continue using the same API that will just wrap the native call when feasible.
For the more advanced features you have mentioned, Dojo already has support for media and offline support, as well as things like JSON-RPC and REST, and it even works inside server-side JavaScript environments like Persevere!
Matt and Eric: The role of JavaScript frameworks is to improve the programming environment by providing richer APIs and doing so in a way that works transparently across the common browsers. What YUI will do, where appropriate, is take HTML 5 idioms (especially those that have some traction in the browser already) and extend support to older browsers so that the new functionality can be adopted even before it's implemented and propagated to a majority of users. Implementing a client-side storage API is one example where YUI will look to fill the gap between what HTML 5 promises and what current browsers deliver.
Andrew: A "middleware" framework like Prototype - which takes ugly, inconsistent APIs and makes them uniform and whole - doesn't benefit much from the new HTML5 stuff. Some HTML5 features will make some tasks easier, but Prototype will still have to remember the "hard way" until the last of the non-HTML5 browsers is no longer supported. Bleh.
On the other hand, libraries that build atop Prototype - script.aculo.us, most notably - will have to make some decisions. Script.aculo.us offers a "slider" control. So does HTML5. Does scripty use the HTML5 slider in browsers that can support it? Or does it stick with a pure JavaScript version to ensure the control looks the same in all browsers?
It's great that HTML5 provides native implementations of some of the things we've been approximating with plain HTML and JavaScript for so many years. If we all switched en masse to HTML5 and left all old browsers behind, it'd mean that most libraries would be able to remove large chunks of code from their source files. But we'll have to keep that old code in for a while longer.
Prototype and script.aculo.us don't have long-term roadmaps, but I know I'll start thinking seriously about using a certain feature once at least two out of the four major browsers support it. Keep in mind HTML5 isn't going to be implemented all at once.
Thomas: Yes, they will evolve, and will gradually support those new features as browsers implement them. This is nothing new for the frameworks, though it's mostly bugs, not features that have to be addressed as new browser versions are released. Right now, for script.aculo.us, the biggest new "playground" will probably be the CANVAS element, and of course it can leverage everything we put into Prototype, e.g. the insertAdjacentHTML() DOM API is probably faster then how we do HTML insertions into the DOM now.
David: We think it's likely that we'll do what we've always done: abstract the API away from browser implementations and fix issues where they diverge. To the extent that we can develop solutions for older browsers to provide cross-browser stability we will, but in cases where we can't we'll provide functionality to detect that and deal with (or maybe fake it). Let's not forget that IE6 refuses to die. It'll be a long time before we can really count on these features.
As for a roadmap, we would imagine we'll take advantage of features that enable us to make a smaller, faster library first. So if we can build, say, a faster selector engine for browsers that support H5, we're more likely to focus there than on enabling features that only a few bleeding edge browsers support. Integrating the spec into our API will likely mean performance gains and byte savings, which are bigger wins for us in the short term until the more advanced features are more prevalent in the browser market.
Scott & Joel: With GWT we tend to focus on features that can be implemented across the major browsers, but we may provide different implementations depending on what browser a given user is running. To give a concrete example, I could easily see us providing a slightly abstract storage API that could use either Google Gears or HTML 5 persistent storage depending on what the user has. The nice thing with GWT is that end users only have to download the specific implementation their own browser supports because of how we compile all the possible permutations ahead of time.
InfoQ: As HTML 5 adds so many powerful features to the client-side, some people argue that the existing paradigm with JavaScript and DOM is reaching it limits. Do you think that we should be considering a different model in the immediate future?
Dylan: One of the main distinctions between jQuery and Dojo is that jQuery is DOM-centric to the core, whereas Dojo also tries to fix JavaScript in places where it is rough around the edges. Applications like Mozilla Labs' Bespin point to the need of non-DOM-centric development, and I've always thought of the DOM as a tool for JavaScript developers, rather than the approach some take, where if you can't represent a change withing the DOM, it shouldn't be done in the browser. Frankly, I think we're already there with different paradigms by different toolkits.
Matt and Eric: The browser ecosystem allows for alternative models, and in fact many of these have been developed. Flash/Flex/AIR is a good example of an "alternative model" that thrives as part of (and in parallel to) the HTML/DOM/CSS web. Arguably, when you reach for your Facebook application on the iPhone instead of the mobile Facebook website you're voting for a new model there, as well. Thus far, no alternative model has managed to marry the low barrier to entry of the web with its inexpensive reach and accessibility.
Should we be "considering a different model" in the future? We'd argue that, as application developers, we're all considering alternatives every time we build a new application. If most apps today are web apps, that's simply an indication that the value proposition of the browser continues to be compelling. We think there's a lot of undiscovered value left in the browser and that evolving the specs intelligently (as with the ECMA 3.1 evolution) will continue to improve the foundation meaningfully.
Andrew: That's a tough one. Some people want browsers to interpret markup; some want browsers to draw pixels in a viewport. Depends on what sort of app you're building. It's not about replacing the DOM; it's about finding other models that complement the DOM so that you can pick the best tool for the job. I think CANVAS and SVG both have potential here.
Thomas: I don't think so-- the HTML/CSS/JavaScript combination has proven very useful and versatile, and all parts are actively evolving. There's no need for a replacement.
David: How can we in the "immediate future"? Anything that H5 brings us that would allow us to change that model would only be available after years of availability. Further, that model is now well defined and understood and in use on billions of web pages. We don't think it's changing any time soon.
Scott & Joel: Oh, I don't think the current paradigm is anywhere near its limits. But it is evolving more rapidly and organically than ever.
On one side you have a lot of new energy being poured into making browsers better (Chrome with V8, Firefox with TraceMonkey, Safari with SquirrelFish Extreme, and of course IE8). No matter which browser you prefer, users will have a much more powerful platform for developers to build on.
At the same time, the tools that developers have available to target this platform get better every day. Perhaps unsurprisingly, I think GWT was pretty revolutionary when it launched. But we just put out GWT 1.6 a few weeks ago, and it's a much more compelling product than the original GWT, or even the GWT you could have used just a year ago. And you see the same thing across the board with other tools as the space matures.
So I think it's safe to say we have a lot of room to run here.
InfoQ: There have been suggestions for using a different client-side language, eg. Ruby. Do you think that JavaScript is powerful enough as it is now? Does it need a major facelift or not? Maybe with more DSL techniques?
Dylan: I think it's much more likely that we'll see DSLs, and the continued encroachment by JavaScript on the server-side. There's a new server-side JavaScript group that has tremendous interest. JavaScript itself was never really the problem. The problem was how browser implementations supported DOM-JavaScript interaction, and that previous JavaScript engines were much slower than the recent advancements by Mozilla, Google, Apple, and Opera. I've thought a lot about what it would mean for Python or Ruby to be available as a client-side language, and frankly I don't think it fixes the problem people have.
Matt and Eric: JavaScript is getting a facelift with ECMA 3.1, which is all we really need at this point.
Browsers are free to support alternative script engines. As long as they implement the DOM APIs to spec, it doesn't really matter what scripting language is used. Some people -- including Douglas Crockford here at Yahoo -- have argued that a new language built with security in mind is necessary for the Web to take the next step.
Andrew: Switching languages altogether won't happen - there's too much momentum behind JavaScript. I liked a lot of the new features of the abortive ES4 proposal - operator overloading, Ruby-style catch-all methods, and so on. Sadly, ES4 tried to do too much. I like that we'll finally have getters and setters as part of the ES 3.1 "compromise." But I think ES 3.1 doesn't try to do enough. In short, I'm for making JavaScript more dynamic by any means possible.
Thomas: Yes, I think JavaScript is pretty much "there". It shouldn't be extended to be a "real OOP language", it's just fine as it is, with the very powerful prototype mechanism. This allows to craft on all sorts of programming styles and allows for customization for personal preferences when developing. JavaScript and Ruby are actually very close at times (and the Prototype JavaScript framework in large part tries to add more Rubyisms to JavaScript!). And yes, more DSL techniques would be good-- the only two things i would like to see in JavaScript in the future is a way to catch missing method names (aka Ruby's method_missing) and a shortcut to define inline functions (blocks), as to avoid having to write function(){ ... } all the time.
David: JavaScript is one of the most successful programing languages on the planet. While there are other languages out there that are less problematic (we know Valerio would love to write in Lua, as he's in love with it), the real problems with Javascript have been with the implementations in the browser. Frameworks fix a lot of that for us, but certainly the spec for JavaScript could be and will be improved. The purpose of the frameworks are 3 fold: 1) abstract away from the browsers where they differ and provide support for older browsers 2) provide a richer, more convenient API 3) provide functionality that isn't in the spec (like effects or sortables or image galleries).
To the extent that we will always have browsers who do things wrong, we'll need #1. To the extent that the API continues to suck, we need #2. And to the extent that the spec does not endeavor to provide rich functionality, we need #3.
We just don't see any of this changing any time soon.
Scott & Joel: I think JavaScript as a language is plenty powerful, perhaps even too powerful sometimes. You could ask for things like 64-bit integers or native support for BigDecimal for financial apps, but the biggest challenge facing JavaScript seems to be the practical aspects of trying to build and manage a large handwritten code base. When we were first creating GWT, we made a bet that the very flexibility of JavaScript that makes people like coding in it also makes it good as a compiler target language, and so it is also useful to think of it as a sort of the assembly language for the web.
You can find more information on JavaScript frameworks and Rich Internet Applications, right here on InfoQ!