My Top 5 (9?) Favorite HTML5 APIs

HTML5 is a lot more than just a few cool new semantic tags. The HTML5 specification actually has a bunch of new JavaScript APIs for us all to work with. Not all of these specs are finalized and they’re not all widely implemented in browsers. That doesn’t necessarily mean that we can’t take advantage of them right now, though. Let’s look at a few of the ones that I’m most excited for and discuss if and how they can be used today.

1) WebSockets & Server-Sent Events

I won’t bother going in reverse order from 5 to 1. There’s no point, especially because I can’t really decide how I’d rank them all anyway. However, WebSockets are certainly my favorite and I included Server-Sent Events with WebSockets because they offer a similar functionality, except that it’s a one-way, long-lived, HTTP connection from the server to the client rather than a 2-way connection.

The ability for the server to inform the client about certain events in real time is a wonderful ability. There’s the obvious and ubiquitous example of a chat application, but that’s far from a true test of its power. Real-time, or even turn-based games can communicate actions this way. It’s used in social media to inform you any time there’s a new update to your feed (different social networks use differing techniques for this; they don’t all use WebSockets). You can even use WebSockets to give you full command-line control of a server from the browser. In fact I’m working on a project right now that allows me to control MineCraft servers through a WebSocket connection. You can see a demo of the alpha version here.

While I haven’t used Server-Sent events yet and cannot give you any idea of how easily you can use them right now, I do know that WebSockets are ripe for use immediately. Even if WebSockets aren’t available in a browser, there are several techniques that can be used to emulate them, though some of them won’t be good for real-time gaming because they won’t necessarily give you fast enough results. You don’t even need to worry about this though because there are some libraries out there that do all of this for you. The two most popular are Socket.IO and SockJS which I’d recommend. I have a basic and advanced tutorial for Socket.IO, but you’ll have to learn SockJS on your own.

2) Page Visibility

The Page Visibility API is very interesting and allows all sorts of enhancements to applications. This API allows an application to detect whether the page that the script is running on is the active tab/window. If a user is viewing a separate tab or application window, then the API will let you know the page isn’t visible and vice versa, so you can react accordingly.

Practically all of the latest browsers support Page Visibility (except Opera Mini), and most of them support it without a prefix (except Android and Blackberry browsers). There are even polyfills for the older browsers that don’t support it, but I’m not sure what kind of browser support those have or how accurate they are. For now, especially with a polyfill, you can just use it as a progressive enhancement, but know that your users have a decent chance of supporting it.

What sort of applications are there for the Page Visibility API? Well, one that you’re probably aware of is what Facebook’s and Google’s chat apps use it for: notifying you that you got a new message while you’re away. They use a audio notification (at least on desktop browsers), but there are other means of notifying the user that you can use, some of which you’ll see with the other APIs below. Another way you could use it would be to use fewer resources when the tab isn’t being viewed. You can do this by skipping animations (just move the element where it should go) or discontinuing periodic server requests (such as checking for connectivity) and so on.

The Mozilla Developer Network has a pretty nice tutorial on how to use the Page Visibility API if you’re interested. It’s actually pretty darn simple once you’ve determined any vendor prefixes you need to use.

3) Web Notifications

The Web Notifications API allows you to display a notification to the user that appears outside of the browser window. You can add icons, text, links, event handlers, and more to the notifications to get them to do what you want. I’ve seen these in action a lot recently since I enabled them for GMail and Google Calendar. Now I get a notification any time I receive a new email or get close to an event on the calendar.

The Web Notifications API support is pretty sparse, though Firefox and Chrome have both supported it for a while. This API’s specification is still a Working Draft, so the lack of support isn’t too surprising. Overall, I’d say you can use them as a progressive enhancement, but it’s far from being ubiquitous enough to rely on it.

Even if you could trust that support is there for the API, you still can’t necessarily rely on the ability to show Notifications because this is a feature that the user needs to grant permission to, which means that the user can deny your application permission to show the notifications. Of course this doesn’t mean that you should avoid it; as I mentioned, Google is already putting it to good use. In fact, you can use it in conjunction with the Page Visibility API to determine when notifications should be shown.

There a couple things that I’m not too fond of with this API:

• You create a Notification object using the constructor and it will show the notification immediately after creation. I don’t think that the constructor should handle it. Rather I would prefer a show method to be available.
• You have very little control of the duration of the notification. In fact, this is largely controlled by the browsers themselves. Chrome will display a notification until the user closes it or the application closes it with the API. Firefox, on the other hand, will automatically close a notification after a few seconds. We can, of course, close the notification early via the close method, but I think the developers should have more control over it.

Once again, the Mozilla Developer Network has a pretty nice tutorial on how to use the Web Notifications API.

4) Vibration

The Vibration API is pretty limited compared to most of these APIs because it can only work on a device that can vibrate, which pretty much means that we’re talking about phones and maybe some tablets. Despite the limited field of devices, this API still gets onto my top 5 simply because it can work so well on those devices. It can be used along with (or instead of)notifications to get a user’s attention, or it can be used to give users feedback, especially in a gaming environment. It seems that making great gaming possible with HTML5 is a high priority because so many new APIs that have been in the works lately offer a lot for games. Makes me kinda wish I was a game developer…

Browser support is extremely limited on desktop browsers (only makes sense since most desktops can’t utilize the API anyway), and mobile browser support is starting to pick up, though it still has a few more contenders that need to jump on the bandwagon. You can’t rely on users getting the vibrations, but it can be an enhancement to those who are using a capable device and browser.

The API is super simple, since it consists of a single function: navigator.vibrate(). You can either send in a number of milliseconds for the device to vibrate or you can send in an array of numbers representing multiple vibrations, including the length of time the device should vibrate and the pause lengths between the vibrations. You can check out Vibration API Guide on MDN for more details.

5) Client-Side Storage

This isn’t actually a single API. Instead it’s a classification of APIs (which is part of the reason there is a “9” in the post title). Previously, if we wanted to store persistent data on the front end, we were pretty much limited to cookies, which have countless reasons to be avoided. With the advent of IndexedDB, WebSQL, localStorage, and sessionStorage, we have a plethora of options.

These means of storage give us much greater flexibility and less dependence on the server. In fact they are one of the few key technologies needed to make offline applications, which are becoming more common amd mecessaru now that devices with patchy internet connectivity are more commonplace.

The likeliness that a browser will support at least one of these APIs is pretty darn good. Sadly developer tools haven’t advanced as quickly as the browsers themselves, so if you want to have control over the storage without writing scripts for it, you’re largely out of luck. Chrome, by far, has the best tools in this area, but they still lack some basic functionality. All-in-all, though, it’s not really something that should deter you from using these APIs.

Honorable Mentions

• Application Cache: Along with client-side storage, this is one of the most useful tools for enabling offline applications. The best introduction I’ve seen is on HTML5 Rocks.
• Network Information: If this API was more explicit and consistent, and actually had the ability to give perfectly accurate information, it would have been more than an honorable mention. It has some useful features, but has a long way to come. Otherwise it’d be quite useful for bringing down different assets depending on connection type/status.
• Battery: This has limited use, but it can be used in a similar way to the Page Visibility API. If the battery is low and the device isn’t plugged in, you could throttle back some of the computations and other power-hungy tasks. MDN once again has a great guide.

Conclusion

Thanks for reading the list I know it’s a bit longer than advertised, but it’s hard to narrow the list down. I’m very excited that many of these are becoming widely available in browsers and I look forward to hopefully putting all of them through their paces in future applications. Was there an awesome API that you absolutely love that I missed? Let me know in the comments! God Bless and Happy Coding!