Although still in draft form, HTML5 is seeing widespread adoption and implementation. But there’s still a fair amount of pushback and skepticism about whether HTML5 is really ready for production.
At a session at OSCON next month, Left Logic’s Remy Sharp will address this. Sharp’s OSCON workshop will dive into HTML5 technologies that are already in production.
I recently asked Sharp about how HTML5 is changing development, in terms of what’s developed and how. Our interview follows.
How is HTML5 going to change web apps?
Remy Sharp: We’re going to see JavaScript being used to push further and further out of the old confines of the browser. We’ll also see more applications that work without an Internet connection.
The more APIs that the browser gives us, the more the idea of the browser fades away. There are APIs to access the file system and we can do drawing and photo editing and save the files to our computers. There are APIs that are just making their way in to the wild that give us access to the webcam and microphone — all natively — with JavaScript.
We’re seeing it already, but with time, I believe people won’t access the web apps through the gateway of the browser. The “browser” part will be invisible and the web app will just be part of the computing experience.
What is HTML5 going to make easier? How is it going to aid performance?
Remy Sharp: I see HTML5 and related specs as heavily focused on the JavaScript. The HTML5 spec used to be called “Web Applications 1.0,” and it shows given the amount of APIs that have been specified out of that process.
So to me, as a web developer who spends most of his time in JavaScript, HTML5 and related specs, this make doing a lot of things easier.
For example, adding audio and video is a doddle. Adding real-time two-way communication between the client and the server is a matter of a few lines of code and it has an extremely low barrier to entry.
OSCON JavaScript and HTML5 Track — Discover the new power offered by HTML5, and understand JavaScript’s imminent colonization of server-side technology.
As for performance, I see it improving in two key places: first, the browser won’t have to rely on external plugins for more advanced applications. This reduces the work the browser needs to do, and the amount of work JavaScript would have to do, if indeed the technology is baked directly in to the browser. More practically there’s a number of APIs that allow data to be stored on the client side, allowing for local access to data or website assets. Removing this dependency on the server for data and assets (like images, CSS, JavaScript, etc.) increases the free resources the browser has for doing other things, like rendering the page and responding to the user.
Second, the time required to develop will decrease since the learning is limited to HTML, CSS and JavaScript. If my company wants me to create a branded video player for their website, it’s just CSS. If I want to learn how someone has built a branded video player, I just view the source.
Developing for a multitude of browsers has long been the bane of web development. Is HTML5 going to make this simpler?
Remy Sharp: HTML5 first and foremost gives developers a consistent specification that all the browser vendors can work from. HTML4 didn’t have this. In fact, some of the key technologies we rely on today were reverse engineered into specs, which is why we see subtle differences. HTML5 is specified right down to the tiniest detail, ensuring that all the browser vendors are singing from the same hymn sheet. This means that new HTML5 APIs are easier to work with, since the implementations are the same.
As for making it easier to work with browsers: on-going that’s certainly easier, but today’s development and browser wrangling remains the same. That said, we’re better off than we were 10 years ago. Developers’ approaches to JavaScript have matured, and more developers are relying on clearly maintained libraries (jQuery, although having nothing to do with HTML5, is a perfect example of this).
When developing an application that solves a problem using a new technology that’s part of HTML5, or even not part of HTML5 — like geo-location or Web Sockets — we developers can rely on polyfills: micro-JavaScript libraries that mimic future APIs by providing fallback support to “older” browsers. This means I can write my markup to use the new HTML5 elements, and a JavaScript polyfill can trigger IE8 to allow me to style those new elements.
Most importantly, HTML5 and related APIs provide native technology that means I, the developer, do not have to rely on Flash or some other plugin technology to solve the problem I’ve been faced with. I only have to learn open web technologies and I’m able to create interactive, real-time, graphics-rich web applications — should I chose to.
This interview was edited and condensed.
Related: