Since Steve Jobs has bashed Adobe and Flash recently, calling Adobe "lazy", saying no one will use Flash anymore, and that everyone will move to HTML5, and since I agree with his arrogance (at least in the "everyone will move to HTML5" department), this is a great time to talk about HTML5.
I've just been tinkering around with some of the features that are already available in today's browsers and their nightly builds, and I was very pleased to confirm that all these nice features are incredibly easy to use. Just to get you up to speed, HTML5 brings with it not only new markups, but also some kickass extensions to the DOM API. Here are some of the features that come with HTML5 or are piggybacking on them:
- Dropped obsolete elements: frame... you will be missed :(.
- Added new elements meant to replace the generic and semantically shallow div tags by giving more semantic information about their contents (example: header, section, article, footer).
- New form controls as well as the ability to make any marked up content editable.
- Offline Storage: Goodbye 4kb cookies.
- Application Cache API: One of the many nails in Google Gears' coffin.
- Drag and Drop: No more frustrating upload forms.
- Websockets: Goodbye polling, hello push notifications.
- Notifications: Desktop apps get to be able to notify me even when they're hidden, and the browser doesn't? Not anymore.
- Geolocation: You are here!
- Canvas: Hello special FX.
- WebGL: Will anything run outside the browser now?
- Video and audio: Hasta la vista 90% of Flash applications (I just made the 90% figure up).
The Desktop Killah
One of the nicest things about HTML5 is that it reduces the need for browser plugins like Flash and Silverlight, both technologies that deserve their spotlight for having redefined the browser's role, to that of a much more multi-purposed and capable tool, but that also deserve to have the spotlight removed from them for making it much harder to make web applications seamless and platform independent. This move represents a strong detachment from the language's original purpose, which was to layout content, as there is now a strong focus on satisfying the needs of web applications.
HTML5 is demolishing the last obstacles that prevented us from forsaking desktop applications and all the evil that comes with them:
- I am lazy and I don't like to install stuff.
- I don't like to upgrade applications either.
- Nor uninstall them.
- I don't like to clean viruses out of the computer of someone that used an USB pendrive.
- I don't like to have to choose an operating system.
- I don't want to have to install all operating systems.
- I reaaaally don't like to reinstall an operating system (I left that lifestyle along with win9x).
- I don't like to give tech support, as I'm much happier if things just work all the time... and I like giving tech support for free even less.
- I don't like to have to tell people that they shouldn't have to buy a new computer, that it's not slow for being obsolete, but from all the crap that they downloaded, that infected their computer, that is spamming everyone, and hogging their computers resources.
For these reasons and more, everything should be on the cloud, everything you need should be a browser, and all browsers should remove their download features. When this happens, the world will be a much more peaceful place where the skies are blue, unicorns will roam the streets, and the sun will shine. HTML5 is a huge milestone in this paradigm shift and it therefore has our full support.
Webless Web Applications
If 1990's Tim Berners-Lee were to slip and fall into a wormhole that sucked him into our time, he would probably be speechless at what we've done with his beloved World Wide Web. It was supposed to be a bunch of pages with links, and not a platform that aims to steal the desktop realm's throne.
Everytime one of us web application pseudo-prophets chants the good ol' word of a world without desktop applications, heretic voices shout: "What if I lose my internet connection?". Until now, the answer was one or more of: use Google Gears, get a better ISP, and/or get a backup internet connection like 3G.
The answer is becoming much simpler, with the Application Cache API, DOM Storage and Web SQL Databases, which are the most recent omens validating "the prophecy" (these along with Web Workers and Geolocation features, easily justify why Gears was dropped by Google in favour of HTML5).
Application Cache API
With the Application Cache API, one can now control what parts of the web application should be cached on the client side. To do so, is as easy as placing a manifest attribute in the document's html tag, with an URI to the location of a manifest file, which indicates which contents should be cached (this file must be sent with the "text/cache-manifest" mime type).
The cache manifest file is a simple text file with a list of the resources that should be cached and those that shouldn't. Its structure is beyond the scope of this post, but it's pretty much straightforward. To learn more about it you can have a look at the Offline Web Applications chapter of the HTML5 spec.
You can now also partially, or fully replace the usage of cookies with the easier and more flexible DOM Storage. Now you can access two new structures in your browser called localStorage, and sessionStorage.
With local storage you can store data that is accessible by all scripts within the domain that originated it, and that is persistent even after the browser closes. With session storage, you can store data that is accessible only by the specific window/tab, and therefore disappears after it's closed.
You are not limited to storing only strings like in cookies, it's really easy to use, as you can use them as regular associative array structures, and browsers offer somewhere around 5-10mb per domain for this kind of storage.
You can have a look at this online demo to give this feature a test run.
Web SQL Databases
This feature is just totally sweet, the idea that I can now write a full blown web application without even needing a web server is pretty liberating. The concept may be kind of stupid, but bear with me for a while. Imagine that I just wanted to write a quick personal app, to keep track of workout logs or whatever, and I lived in a parallel universe where spreadsheet software was never invented. Previously I would have to pick up some programming language, or combination thereof, which offered me a way to quickly prototype an application with an user interface, and I would probably end up in .NET and Windows Forms land.
Give this online demo a try to get a feel for how this works.
Pimp my Website
HTML5 brings with it some nice features that will make web applications increasingly indistinguishable from their desktop counterparts.
Video and Audio
I remember the old days when playing video and audio content on the web was a huge pain in a part of my body. Buffering 10%.... buffering 20%... buffering failed... or I didn't have the appropriate player, or the appropriate player was loaded with spyware, it just wasn't fun to say the least... until YouTube and similar services appeared.
Due to Flash's ubiquity, the experience of watching media in these services is nowadays pretty decent, as they work out of the box. However, the way Flash deals with video is pretty resource intensive, and to top that, it uses proprietary formats for compression. HTML5 kind of deems Flash obsolete in this department, as it lets the browser deal with media playback by itself, by now adding a way to reference them via video and audio tags.
Here's another cool demo showing off video in HTML5.
Another one of Flash's nemesis, Canvas consists of a drawable region defined in the HTML code that can be manipulated via a set of drawing functions similar to other 2D APIs. Amongst its many utilities (charts for example, just from the top of my head), Canvas may very well be the container where a new wave of video games an other interactive media applications will run in. Their quality may even be boundless, as the WebGL specification is in the works, which will provide the Canvas container with OpenGL ES bindings, and make hardware accelerated in-browser cross-platform graphics a reality.
You can check out CanvasDemos for a motherload of Canvas demos to play with.
Drag and Drop
Have you closely checked out Gmail recently? Try dragging and dropping multiple files into the attachment upload area when using Firefox or Chrome, and just watch the magic happen. The files will be uploaded and attached with no extra interaction.
Gmail is using an interesting hack to do this, it's just using a normal form input tag, of type "file", with the new "multiple" attribute offered by HTML5, which already supports dragging and dropping multiple files into it, and it's hiding the input control and masking it with CSS trickery.
Most browsers already handle custom drag and drop events, but when these events are caused by dragging and dropping files, accessing and manipulating their contents seems to be a whole other story. Hopefully this will become a standardized reality in the not too distant future, and it will bring a whole new level of user experience to web applications, but for now you can already fool around with it today, by using Firefox's FileReader object.
Yes, you can install plugins in your browser to provide you with notifications when you receive something in your Gmail inbox for example. But change browser or computer, and you've lost the feature.
The fact that web applications can't issue decent notifications nowadays, kind of forces them into having to be visible all the time, which makes them a lesser breed than desktop applications. This is probably a thing of the past, as you can now issue desktop notifications with Chrome, through WebKit's Notification API.
Actually, for the sake of accuracy, I looked for this feature in the current HTML5 spec, and I didn't find it there, so I can't promise this will actually be somewhere in the standard, but I won't be very surprised when this API finds its way there.
And Even More Miscellaneous Sweetness
Breathe deep... and there we go... more HTML5 goodies.
Browsers and web servers just didn't get along until now. Everytime the browser requested something from the web server, it would just close its door afterwards without asking it if it wanted anything else. Ok, it could ask it to keep the door open for more or less time, but still, it ended up being pretty rude in the end.
Try to design an application that needs to be notified of server-side events and you'll notice how messy and inefficient your solution will be, as you'll have to keep polling the server time and time again, asking it the same old question and having the door shut in your face afterwards. Websockets make things so much easier, since now you can just open a connection with the server and have it notify you instead, leaving you with the simple job of waiting for the notifications, instead of having to be asking questions all the time.
Here's a demo of an IRC client using Websockets.
Want to track down someone who is owing you money? Make a website that will draw him in, and use the Geolocation API to get his coordinates. I'm sure there are better uses for this feature than that one, I mean, even in the desktop computer where I'm writing this post, which naturally has no GPS, I was able to get some pretty accurate coordinates as to the whereabouts of my current location, so I guess coming up with cool uses for this feature just requires a tiny bit of creativity.
Try out this demo, and don't blame me if you get a little paranoid after trying it.
Until now, everytime you wanted to perform heavy computations, either you used some nasty setTimeout hacks, or you would get a frozen user interface. With Web Workers, you can now run your code in different threads (or something thread-like, I guess this depends on the browser and the operating system it's running on), and fully use the browser's power without handicapping your user experience.
Watch your CPU fly without crashing your browser, with this demo.
We Want You for the HTML5 Army!
Still not convinced that you can kiss Flash bye bye? Then you can go back to sleep. In case you are, then use HTML5, it's right here, right now. Yes, the specification is still a draft and it's obviously not implemented in all browsers as a consequence, but at least whenever there's not much of a risk in going for HTML5 instead of a sluggish browser plugin, then go for it. When Flash becomes an archeological artifact found in archaic websites, along with GIF animations of mailboxes, then you can proudly say you were one of the standard's pioneers :).