My first real encounter with what we loosely call "HTML 5" was nearly three years ago, at a 2007 Future of Web Applications conference in London. Mozilla's John Resig showed features including the Canvas element, SVG, video and audio. I reported on it here, noting that it might be too late to disrupt the momemtum behind Adobe Flash and Microsoft Silverlight.

I would not have guessed that in 2010 Microsoft itself would demonstrate a version of Internet Explorer with support for these features. I'm referring to the version 9 fourth platform preview, which you can try out here. In case you missed it, the new IE scores 95% on the Acid 3 CSS stress test (and the other 5% is unimportant), performs creditably on the SunSpider JavaScript performance test, being more then ten times faster than IE8, and implements significant parts of HTML 5 including Canvas, SVG, Video and Audio.

It is true that HTML 5 as a standard is messy and incomplete. It will be many years before it is done. That said, key features of HTML 5 will be ready much sooner; in fact once IE9 appears we will be able to say that the latest versions of all the major browsers support them. This includes WebKit, which is used in many mobile browsers as well as in Apple Safari, Google Chrome and Adobe AIR, so parts of HTML 5 will work on mobile devices as well as on desktops.

The implication is that we need to rethink, again, what are the limits of browser-hosted applications even without plugins. Here's Joel Spolsky writing six years ago:

Here are a few examples of things you can't really do well in a web application:

1. Create a fast drawing program
2. Build a real-time spell checker with wavy red underlines
3. Warn users that they are going to lose their work if they hit the close box of the browser
4. Update a small part of the display based on a change that the user makes without a full roundtrip to the server
5. Create a fast keyboard-driven interface that doesn't require the mouse
6. Let people continue working when they are not connected to the Internet

Interesting to read this now. Of these, it is really only the last, offline use, that is still a major problem. There is some provision for it in the HTML 5 specifications, but this is not an area that is widely implemented yet.

It is more fun to consider what you can do in HTML 5, including high-performance graphics and code. Developers are beginning to push the boundaries. James Pearce, for example, has a work in progress that shows how the BBC could have implemented its iPhone/iPad news app in HTML 5 - it is not perfect yet, but it is making a point: why make an app that only runs on Apple devices, when you can do the same thing for the open web?

The support in Internet Explorer 9 is significant, partly because Microsoft still claims the biggest market share in web browsers (though not in Germany, where FireFox has nearly 60% share according to StatCounter), and partly because Microsoft-platform businesses both have a disproportionately high usage of IE and are an important market for developers of custom software.

Let me emphasise: I'm aware that IE9 is still in preview, and that even IE6 still has significant usage in some quarters (though only 4% worldwide, again according to StatCounter). I'm also aware that HTML 5 application development tools are in their infancy, and that plugins like Flash and Silverlight offer more predictable results as well as middleware support and a full suite of mature development tools. Plugins are essential for real-world use in many scenarios. It is possible that this will always be the case, that as HTML 5 advances the plugins will simply leap further ahead.

Looking ahead though, it now seems likely that native HTML, CSS and JavaScript will grow in importance as a viable client application platform. At the very least, I'd encourage developers to try out the IE9 TestDrive examples, or equivalents for other browsers, and glimpse a future where zero-deployment, true cross-platform, and full web integration come together.

Further reading

Mark Pilgrim's book-in-progress Dive Into HTML 5.

Summary of What is new in IE 9 Preview

I've been trying out JavaScript mapping APIs from Google and Microsoft, which prompted me to revisit the question of JavaScript IDEs and debuggers. My first stop was Visual Studio, since I use it anyway for Windows and ASP.NET development, and I was impressed by how well it works even for projects that do not use Microsoft technology. Take Google Maps, for example. Fire up Visual Studio 2008 (earlier versions are less good for this) and start a new project using the Empty Web Site template. Right-click the solution, Add new item, and choose HTML page. I always name these with an .html extension, not the default .htm which exists solely because DOS could not cope with four-letter file extensions, but it is a matter of taste. You now have an empty web page. Click Debug, and let Visual Studio add a web.config with debugging enabled even though you will not be using this for deployment. You will also be prompted to turn on debugging in Internet Explorer, if you have not already - yes, you have to uncheck disable:

If you then try to debug, Visual Studio fires up its internal web server and opens the blank page in Internet Explorer. So far, so good. Next, I added the code to display a Google map - it's only a few lines of JavaScript. Visual Studio does a good job with syntax highlighting and code completion, for types that it knows about. I found that I could easily set breakpoints and inspect variables; everything worked smoothly: 

You can even debug into the incomprehensible Google library code if you feel so inclined - just press F11 to step into the code. You also get windows for autos, locals, watched variables and call stack; and there is an immediate window.

There are a couple of snags with this. One is that browsing the web with debugging fully enabled in IE is painful, either because the web is littered with broken JavaScript, or because IE breaks easily; I guess both of these are true, and you will see constant debug dialogs. A solution is to use a different browser for everyday use. The good news is that this is said to be fixed in IE8; Visual Studio will turn on debugging in IE8 on demand, though I have yet to try this.

The other unfortunate aspect is that attempting to debug with other browsers does not work in the same way. You could edit in Visual Studio and debug with something like Firebug; but you lose the smooth integration. IE8 mitigates this a little, because it is more standards-compliant so its JavaScript engine and DOM is closer to that in FireFox and Safari, but there is still no substitute for debugging in all the browsers that matter. Of course we will also have to cope with IE7 for the forseeable future.

Still, if you are a Windows developer casting about for a JavaScript IDE, don't forget the one you most likely already have installed.