KWICies #006: Thoughts on HTML5 and HTML5DevConf 2015
We live in a web of ideas, a fabric of our own making.
Joseph Chilton Pearce
Roses are red, violets are blue, I’m schizophrenic, and so am I.
Oscar Levant
The Web is Your Oyster, Now Watch Out for the Clams…
Let’s face it. HTML5 was originally designed as a weapon.
HTML5 is the culmination of a political movement to overthrow Microsoft Internet Explorer (IE) as the web platform for all of humanity.
If you recall from your readings of the ancient dead (ANSI) C scrolls of the Internet circa mid to late 1990’s, Microsoft’s IE (a browser licensed from Spyglass) was the only browser allowed by most companies. And many large companies wrote apps specifically for IE, effectively shutting out any other browser vendor. This was tough to take for the other browser vendors at that time such as Mozilla, Apple and Opera. The browser was the portal to knowledge and Microsoft was the gatekeeper. Not only that, the pace of innovation with Microsoft’s browser back then was glacially slow (and that’s being kind). Microsoft also leveraged this control to constrain the growth of the Java browser plugin to run applets (anyone remember any useful Java applets? Me neither). When you have a monopoly, why rush to innovate? It’s no different than in any other business sector.
“I’m certainly not interested in forking a shell”
But this situation was only good for Microsoft and gave enterprises a false sense of security. Yes, you can be sure there’s a browser running on your user’s desktop so you can deploy your web app, but its frickin’ IE with its own proprietary implementation of HTML and related technologies. Didn’t we learn portability as a trait of good software back in Computer Science 101?
Since the browser is the portal to knowledge and information, and just an indispensable tool (to buy incredibly bad country music, to rent movies from the 70’s with a laugh track funnier than the movie, and to watch videos of cute kitties riding on Roombas), the other browser vendors were at a disadvantage. They could not run those non-portable, IE-specific apps.
And quite honestly, the W3C as an organization back then was no zippy roadrunner either. It moved quite slowly especially with the evolution of XML-flavored page markup, which thankfully died on the vine. Hopefully the vine died a painful death too.
What were they smoking?
Because of the slow evolution of this markup language by the W3C (and because they needed to stop the IE monopoly), Apple, Mozilla and Opera proposed a new unofficial web standards group called the WHATWG (Web Hypertext Application Technology Working Group) in 2004. These three proposed HTML5 to the W3C as the basis of the next generation of web applications not web documents. Effectively this turned the web into a programmatic platform rather than a document storage platform. HTML5 was not just an upgrade of HTML4, it proposed sophisticated graphics, animation and a collection of useful ECMAScript (note JavaScript is an Oracle trademark) APIs such as File I/O, Geolocation, Database, Messaging, Threading, Touch Events, Audio, MIDI, Speech Recognition, et al.
Eventually Google recognized the pervasive, far-reaching, accessible power of HTML5 and joined the programming plumbing party with the ever-growing list of HTML5 goodies. And HTML5 is providing all of these features without plugins. Since plugins were attack vectors for hackers, the more plugins you have, the more possible security breaches. HTML5 only allows a single way to connect the browser to the web. This significantly reduces the possible ways that hacker can break in. It certainly doesn’t eliminate breaches, but HTML5’s no-plugin philosophy dramatically reduces the attack surface area (just love that jargon from the security boys).
The only time more Doors is better
So now we have a large number of modern browsers (amazing what competition does, right?) all with varying compliance to the list of really cool HTML5 features.
Any many of these features were on display at the 2015 HTML5DevConf in San Francisco. The conference chairperson Ann Burkett put on a wild week of web wonderment at the Yerba Buena Center for the Arts in the city by the bay. There were speakers from Netflix, Google, Meteor, Microsoft, Yelp, Dolby, PayPal, Adobe, Wal-Mart, Yahoo, Couchbase, Qualcomm and of course Kaazing.
I particularly enjoyed Jennifer Tong’s talk on “Prototyping the Internet of Things with Firebase”. Jennifer, a Mountain View Googler, did an incredible job explaining simple electronics to the web-savvy audience. She brought everyone up-to-speed on simple hardware hacking in the first 20 minutes of her talk and setup her live software demos using Google’s Firebase, the Johnny Five library and the Raspberry Pi small computer. Excellent presentation.
The original Johnny “Five”… Johnny Bench
Steve Souders is no stranger to the web world; he’s well known in high performance web circles and the web in general. Steve had successful stints at Google and Yahoo! as the lead performance expert. His session on Design+Performance was certainly very informative. Essentially users want both a media-heavy website but a very fast user experience, but how do you design an optimal site that satisfies both criteria. Steve talked about gathering metrics using new tools and employing an interesting development process that joins both requirements at a project’s outset.
Peter Moskovits and I delivered a well-attended session on novel uses of WebSocket using our own Kaazing Gateway server. Historically WebSocket (and its technically incorrect but more popular moniker “WebSockets”) has been used to push data from the server to the browser. But now there have been several advances in alternative mechanisms for simple data push such as the Notification specification and the Push API. There is also the new HTTP/2 standard, where multiple HTTP connections can share a single, underlying TCP connection for 20-50% more performance. The use of WebSocket specifically for browsers is now more suitable for certain high-performance or highly reliable messaging use cases.
Kaazing’s Peter Moskovits Talks WebSocket
As we pointed out in our session, the overwhelming majority of web usage is not via the browser. Most of the web is consumed via APIs. Currently the dominant API model is REST (there were a few people in the audience actually admitting they used SOAP, poor souls). REST is a very easy synchronous API model that typically uses request/response HTTP as its transport, which means REST calls have to wait for a response.
But as streaming and reactive services mature and continue to proliferate (especially with the IoT wave growing exponentially), the need for higher-level asynchronous mechanisms and APIs for developers to use will grow significantly. The world is asynchronous and event-driven; many applications in the future just cannot use REST, which was never truly designed for events. WebSocket is perfectly suitable for these types of use cases.
We also proposed a novel application for WebSocket as an alternative to an old-fashioned VPN. Since WebSocket is a bidirectional, web-friendly software tool, why not use it to create an on-demand connection between applications or server processes? Since WebSocket is effectively a “TCP for the web”, let’s use it like a TCP. That’s the basis of our KWIC software, which provides on-demand VPN-like connectivity using WebSocket under the hood.
There were certainly many other sessions with interesting topics and excellent speakers that you can check out at their website. The HTMLDevConf just gets better ever year!