A few months ago I wrote a rather extensive blog post about the future of applications. With a few recent announcements in the industry and a newly discovered HTML5 API I thought it prudent to revisit this subject.

Of course the recent announcement I am talking about is WebGL implementation in both the latest nightly builds of WebKit and Firefox. WebGL, if you’re not familiar with it, is short for Web Graphics Language. WebGL provides access to OpenGL ES 2.0 from within the browser using javascript. OpenGL ES 2.0 is the graphics engine used on the iPhone and the iPod touch (and other mobile devices). This gives you an idea of the possibilities WebGL is opening up.

The new Canvas element (as well as SVG) in HTML5 adds a vector graphics layer on top of HTML lifting dependence on bitmap graphics. Canvas isn’t new though. In fact, many web applications today use the canvas element today. The CoreGraphics frameworks in Cappuccino is written using the canvas element. For performance reasons the TableView in Cappuccino relies  on canvas to draw the table. I bring canvas up because this is exactly what WebGL uses for rendering 3D graphics in your browser. To draw on your canvas you select a context for which you will be using. Traditionally you will be using the 2D context giving you a “surface” to draw two dimensional primitive shapes. WebGL opens up the 3D context of the canvas element to developers. Actually, WebGL takes it to the next level by more or less “bridging” the 3D context of canvas with OpenGL ES 2.0.

I’ll come back to WebGL later but I want to touch on an API in HTML5 that I had forgotten about when I wrote my original post about the future of apps. I’m talking about Web Workers. First off, you must understand how javascript works in the browser. The javascript in your browser (generally speaking) runs on the same CPU thread as the browser itself. The Google Chrome browser has actually abstracted the webpage and makes it run as a separate process from the browser. This means if your javascript freezes the browser only the page you’re looking at crashes, leaving the other tabs in tact. This however doesn’t solve the problem of a multi-threaded like implementation in javascript. To solve this problem Web Workers were introduced letting parts of your javascript run independently of others. A great example of this is found on the prime number calculators on this page. One version will actually hose up your browser while the other brings the javascript into a new thread preventing the browser from hosing up.

To recap I’ve talked about hardware accelerated graphics and multi-threaded javascript running from within the browser. Now lets take a look at what I said just two months ago.

A few exceptions do come to mind. We currently don’t have support for things like hardware graphics acceleration, extensive support for multi-core processors, standardized local storage solutions, and standardized personal identification.

Now, multi-threaded does not necessarily translate into multi-core but once the javascript is threaded the browser can easily assign different tasks to different cores. So it looks like high performance demanding applications are no longer a problem with HTML5. That just leaves the standardization of access to your personal identity on the web. I am obviously not the only person thinking about how to bring all my desktop applications to the browser. The future is already here, now we must jump ship or waste time catching up.