At yesterday’s keynote Microsoft was proudly displaying their first platform preview of IE 10. Amongst all the crowing about its performance enhancements a bigger issue was missed. What do they really mean by “Native HTML5”? Is it really just about hardware acceleration? We don’t think so.
In the accompanying press release on the IE blog talks a lot about standards but there are a few hints about their long term direction in the first three paragraphs.
IE10 Platform Preview 1, available for download today is the first step in delivering the next wave of progress in native HTML5 support. Web sites and HTML5 run best when they run natively, on a browser optimized for the operating system on your device.
We built IE9 from the ground up for HTML5 and for Windows to deliver the most native HTML5 experience and the best Web experience on Windows. IE10 continues on IE9’s path, directly using what Windows provides and avoiding abstractions, layers, and libraries that slow down your site and your experience:
The only native experience of the Web and HTML5 today is on Windows 7 with IE9. IE9’s approach to taking advantage of what the operating system offers – from the native graphics stack to jump lists in the shell – maximizes performance, usability, and reliability. We released a fast, clean, trusted, and interoperable IE9 globally for consumers and businesses four weeks ago with the goal of delivering the best experience of HTML5. The best HTML5 is native to the operating system, so Web sites have the fewest translation layers to pass through. The best HTML5 enables sites to use the same markup – the same HTML, CSS, and script – across browsers. The best HTML5 respects developers’ time and enables same markup by treating site-ready HTML5 differently from unstable technologies.
Clearly jumps lists have nothing at all to do with hardware acceleration or performance in general. So what is really going on is an attempt to embrace HTML5 as a way of building native Windows applications. Jumps lists are just a tip of the iceberg, an opening shot in what will probably take them several more iterations to complete.
To foresee what is next, one needs to start by looking at what makes a “native” application different from a web application. Then remove the things that are covered by the HTML5 standards. For example, what would a web enabled document editor need?
- Text editing
- Formatting
- Fonts
- Loading/saving files on the local/network drives
- Loading/saving files on the web
- Spelling and grammar checking
- Recent Items Support
- Launch from the Start menu
- The ability to run without a network connection
The first two are well established. The Fonts module in CSS 3 will take care of the third item. The fourth one is our first candidate. While saving files to local/network drives is easy enough, opening them is quite painful. You cannot simple double-click on a document and expect your web browser to launch a website that will load and render the file. So the ability to associate file types with a web app is the first missing feature.
Continuing down the list, loading and saving files on the web is a no brainer. Spelling and grammar checking, done right, will require the multi-threading capabilities of HTML5 Web Workers. Recent Items support is our next candidate. Not everyone uses this, but that who do would be quite annoyed if this dynamic list wasn’t kept up to date.
Launching from the Start menu is something that all applications are expected to do. With IE 9 web sites can be “pinned” to the Start menu by dragging a shortcut onto it. If the rumors are to be believed, Windows 8 will offer a new deployment packages scheme called AppX that will make this even easier. According to Long Zheng you can use AppX to describe a website as the target instead of a compiled application.
The final item is the real challenge. To offer the “performance, usability, and reliability” of a native application a web app needs to be able to run without access to the server. There have been several attempts to do this before but they have largely failed for a number of reasons including too much reliance on server-side processing or the fickleness of the browser’s cache. With the enhanced capabilities and performance of modern JavaScript, much of this server-side processing can be shifted to the client where it rightly belongs. And the browser cache can certainly be tuned or enhanced to prevent “installed web apps” from being prematurely removed.
To summarize our feature list:
- Associate file types with Web Apps
- Recent Items
- Start Menu Integration
- Persistent Caching of Web Apps
We don’t know when or if Microsoft is going to implement any specific feature. Nor does anyone really know all of the other features that various types of applications are going to need in order to look and feel like native applications. But it is clear that for Microsoft to succeed at offering “Native HTML5” they need buy-in from the website developers. This stuff isn’t free; developers need to explicitly use it on their sites. And since it is clear that the other browser manufacturers have no interest in offering Windows-centric features, web developers would only be doing this for IE users.
Fortunately this is still good news all around. Since this strategy also requires supporting most if not all of the new HTML 5 and CSS 3 standards, web developers are going to win even if they never give Windows a second thought. IE is going to be implementing this stuff as quickly as the standards are ratified and the other browsers won’t even consider allowing themselves to fall behind Microsoft.