Before jumping into the HTML5 APIs topic, Kyle talks a little about the facades he likes to wrap around these APIs. Facades add a thin layer of abstraction between the actual API and the production code using it.
(mystical sounds) - Now, I'm going to present to you just real quickly again because I don't want to belabor lots of HTML5. This is not an HTML5 workshop, but I want to present to you several APIs that exist in HTML5, but I'm going to do so in a different way than maybe you're used to seeing. Because I'm not actually going to show you the native APIs. What I'm going to show you is code that's using, what I call API facades. Now I have an entire talk on this particular topic if this is at all interesting to you.
I'll give you like the two minute blurb on what a facade and why it's important. A facade is an extremely thin layer of abstraction, around a native API. It is not a polyfill. It does not put functionality into an environment where that functionality does not already exist. It does not add new functionality on top of the existing APIs, for the most part. It is not terribly concerned with lots of bug fixes and things. The main goal of a facade, the main goal of this thin wrapper API, is for you to have a thin layer of insulation, between the code that you write across your production application, and the actual APIs that sometimes develop bugs in them.
Sometimes they change. Sometimes they move from not being vendor prefixed to being vendor prefixed, or the other way around. Sometimes quirks occur, and if you have production code that is using the direct native API, it's all over the place. Say for instance the Canvas API, or the localStorage API. If you're using those APIs directly, and one of the environments that you're supporting your production app in changes something about it, like a bug is introduced. I don't remember the exact details, but I remember a few months ago there was some change that (coughs) happened with Safari and their number of concurrent AJAX requests or something.
And all of a sudden production apps just have to start dealing with a change to the environment that they used to be able to run in. So, when those things occur, if you've been using the native APIs directly across your whole code base, you've got a whole bunch of places to go and fix it. But if you've been using a facade, the facade is a place that's sort of a pressure release valve, or it's an insulation layer, that allows you to fix that problem, or fix that bug, or whatever that quirk, in one location rather than having to invalidate the code across your entire app.
So facades are an incredibly important thing to be using. If you're using these native APIs directly, I encourage you to rethink that choice. Use some sort of facade, use some sort, frameworks are just a more complex version of a facade. Frameworks add all kinds of extra stuff into it. They add in polyfills, and if you're using a framework around Canvas, like if you're using D3 or whatever, great, no problem. I'm not going to complain about your use of a framework. But if you're using the Canvas API directly anywhere, you should either be using a facade or a framework, rather than the direct API.
So that's my little two minute spiel on that, and what I'm going to show you is several of these APIs using a facade, using facade APIs that I have built. There's a project that I built called h5ive, and the goal of that was sort of a community driven thing. It really hasn't gotten as much attention as I hoped it would, but the goal was for us as a community to collectively build facade APIs for all of the builtin HTML5 APIs that are available. Everything from localStorage, to WebRTC, to WebSockets, all everything, I wanted us to build facades for that so that we could responsibly use these features now, but insulate ourselves in case there are problems or changes or bugs down the road.
And we've probably got five or six of those facades written. So I'mma show you some of those today. But if you go and checkout, it's h with the number five. H5ive is the project name, and if you go and check out h5ive on the GitHub repo, you'll see there's 20 or 30 other APIs already identified that we need to write that haven't been written yet. So, if you'd like to help I would love that, and I've got a contribution guide there on how to help participate in that. It's pretty easy stuff, but (coughs) I'm going to show you some of the facades for the APIs that I already use that I've built.
- HTML5 facades
- Using APIs
- File I/O
- The asynquence library
- Publishing npm modules
- Grunt and Gulp
- Node as a web server
- Simulating asynchronicity
- Making a socket connection
- User-triggered messaging
- Signaling and data channels