HTML5 Is Kind of a Big Deal

0 Flares Twitter 0 Facebook 0 LinkedIn 0 Google+ 0 0 Flares ×

Have you looked at the new features that are part of HTML5?  I must admit that it took me some time to actually look at it because I dismissed it as just some new markup to have to deal with.  In that way, its really not correct for this to be labeled as HTML at all!   In fact, HTML5 is a collection of technologies that have been sorely missing from web browsers, and upgraded markup is a rather minor footnote.

The introduction of these technologies now means that we’re probably about to witness a major new architectural paradigm for web applications, toward that of a fat client, and away from the traditional static page model. Dare I say Web 3.0?  As someone who has always had an affinity for UI centric application, I must admit that I find this pretty exciting!

So let’s get into it. What is so exciting about HTML5? There are 5 major categories that I would us to describe these upgrades:

1. Dynamic Image Rendering

There are two major technologies to discuss here: SVG and Canvas. SVG is ‘retained mode’ and used mostly for data modeling or whereas the canvas ‘abstract mode’ and can be used for real-time painting and animations. In totality, these vector tools are what will allow the technology to replace what has otherwise been accomplished mostly with Flash up til now.

SVG – essentially a markup language for vector images that live in the document. That in itself is pretty cool which you consider the semantic web potential of the image data.   Mozilla has a really great example of SVG with their glow map that shows a glow dot on a map for each download of Firefox. The real time update of the graphic shows what can be done here.

Canvas – more for user interactivity and animations. So whereas SVG might be used in place of traditional Flex modeling, imagine the canvas replacing most uses of Flash.  A friend sent shared an example of an interactive animation in which the user draws a stick figure and then interacts with the stick figure as he begins walking across the screen and doing random activities.  The painting of the screen is all possible via the HTML5 canvas. The animation and interactivity, is the interplay of JavaScript with the canvas.

2. Native Media Support
Embedding an image or audio file is now as easy as embedding an image. This is probably the most famous feature of HTML5 as we all have heard that Steve Jobs pointed out that you no longer need Flash to embed videos, right?   But that is  just a tactical concern.  What really makes this cool are the implications of having natively supported video.  Imagine what you can do when you have a UI that can directly interact with the video, rather than simply play it.  For one thing, you can have multiple iterative hot spots throughout the document that trigger videos based upon user or application events. That’s true Flash or Director multimedia, directly in the DOM and SEO and Mobile friendly.

There are also interesting experimental technologies such as the Popcorn.js library that looks at triggering events within the UI or application via embedded footnotes in the video itself.  There are many people buzzing that Interactive/Internet TV is finally going to take off in 2012 because the technologies are finally going to be present to do so. Imagine the implication for TV content producers if they’re able to conduct the iterative events on an Internet TV video embedded directives in their video content?  They could instigate real time data and social media and coordinate it with their media experience.  That is very compelling.

3. Semantic Tagging
This is compelling from a Semantic Web perspective. So far in the evolution of the Internet, everyone has focused on creating websites and web applications that engage a user.  But what if a computer needed to interact wit your content?  The only significant example of this to date are the search engines and we should all be familiar with SEO and how pages are altered to make a document parseable by search engines.

But imagine taking it a level beyond that.  What if your computer acted as a virtual assistant for you and you were able to book a plan trip on Expedia, when your computer interrupts you to remind you that you have a scheduling conflict already.  These sort of aware systems would only be possible if they were themselves aware of the content we are interacting with.  So the idea with the semantic web, is that if we all properly tag our content with appropriate tags and meta data, we make it possible for such systems to be aware and to consume our content.

HTML5 takes a big step forward on this, both with semantically appropriate tagging, but also with formal adoption of meta tagging standards such as RDFa and the @rel attribute that can be used to map together authors and their contributions online, which I discussed a bit in another post.

4. Local Data Storage

Initially the HTML5 specification called for a location implementation of a SQL database.  Sadly, this was deprecated last year.  Many of the modern browsers have already implemented but it may not be there in future browsers.

What is there however, is an client-side key-value database solution for local storage. Using the localStorage API, you can store up to 5mb of data and it seems to persist indefinitely, or until the user manually purges their database.  So this can still be very useful. This is basically cookies on steroids.

This probably is a better solution than a local SQL database.  Consider the movement of NOSQL database systems toward non-structured document databases rather than tables and schemas; they essentially store JSON objects which are native and ideal for persisting state of a JavaScript application.  Given that an HTML5 JavaScript application would be the consumer of this database, it seems this might actually be the perfect solution for maintaining state, compared to a traditional SQL dB.

As for why this is a big deal, it has the potential to completely change the architectural paradigm of web applications!  Persistent state is one of the big issues that pushed traditional “fat client” application design toward a thin client/fat server model, since web applications relied on the server to remember everything.  If this issue of state is finally resolved, we could see a return to a fat client model, in which we’re doing way more development in JavaScript on the Client side, and much less on the server.  Many, many implications here!

5. Standardized Resources

Other resources have also been standardized here as well:

JS Web workers – this is a subtle yet bit one.  We’ve all probably experienced the occasional web application that seemed to load really slowly and kill usability because the JavaScript had a lot of work to do and ran away with the app.  With web workers, its possible to isolate certain JavaScript threads as background processes, similar to Unix Daemon processes.  That could he very helpful for large those pesky social 2.0 JavaScript includes that delay your document ready event or other data fetching or calculation intensives such as prime numbers, etc.

Cross Domain – AJAX can finally make calls cross domain, rather than being limited to the domain or origin.  This is again huge in terms of being able to build a fat client app, particularly in the days of  mashup APIs.

GEO Location – Also apparently each browser now provides a standardized Geo-location API. The implementation details are up to each browser; Firefox in particular apparently now implements Google’s Geo API.  So now we have standardized location approximation, for all computers not just mobile.  This has recently popped up in Google’s maps in fact.  Clearly this is an attempt to support creation of a single fat client app for mobile and the desktop.


So there you have it, HTML5. Each one of these respective upgrades is a big deal, but in my opinion the really big deal is that I think this will trigger a new architectural paradigm in web applications.

Imagine writing a single application that is equally engaging on your mobile app or desktop.  It retains its own state and doesn’t require page refreshes, so its an optimal experience with even a slow internet connection or lack of connectivity such as being on the rode or in airplane mode.  Imagine the client is where the majority of the application logic lives and only minimal server calls are required any more, and even those being written now in an event-model pattern using JavaScript via Node.js, rather than an entirely different server side technology.   Yep, this indeed has the potential to trigger a really exciting new era of web application development!