The Browser Is The Platform... Seriously
Posted by Greg Bulmash in Techno Thoughts, Technology & LifeAs I've been investigating frameworks that would let me create an installed app for Mac/Linux/Windows/iPhone/Android, the two words that have come up most might surprise you: JavaScript and WebKit.
Most of you know what JavaScript is. It's a programming language that allows you to do client-side tasks in the browser (programs you embed in a web page that are run by the user's browser, rather than on the web server). Fewer might know about WebKit.
WebKit is an engine for powering a web browser. When Apple went to create Safari, they borrowed and built upon an open source engine called KHTML which was created by the KDE project. Over the years, it's stayed open, stayed free, tried to stay ahead of the technological curve, and by many opinions, is less bloated and burdened with legacy code than the open source engine that powers Firefox.
And it's spread. Webkit powers Safari on Windows, Mac, iPhone, and the upcoming iPad. It powers much of the new Google Chrome browser and the Google Chrome OS. WebKit powers the built-in browsers on Android and the Palm Pre. It also underpins multiple cross-platform application frameworks, including Adobe Air and Appcelerator Titanium. I haven't spent a lot of time researching it, but it seems that Blackberry's going WebKit for it's main browser and you can get a WebKit browser for your Windows Mobile phone.
Basically, you get the broadest range of targetable systems not with Flash, not with Java, but by targeting development to WebKit.
Most of your smartphone users will go with the built in browser. Even if they downloaded something else, it's hard or impossible to delete the built-in browser in many phones, so they'll have it. If you want to make sure your desktop/laptop users are running a WebKit browser, just package up the front page of your web application in Adobe Air or Titanium Appcelerator and the framework's runtime will bundle your app around a runtime that gives you all that WebKit functionality.
With client-side databases, "offline" mode (web scripts can determine when the browser is offline and continue to offer various services), some pretty cool JavaScript libraries for user interface animation and 2-D gaming, HTML5's native handling of video and audio, and the ever-expanding functionality of the Canvas element, applications will continue to migrate to the browser. As more browsers offer a standardized option for user scripts (3rd party scripts that run after a page loads... with the user's permission), even more ways to blur the line between desktop and web app enter the picture.
Don't get me wrong. You're not going to see the whole computing experience handled inside the browser. For some computationally intensive tasks like video compression and 3-D gaming, you just need the pure, throaty roar of compiled code running natively on the platform you're using. But where pure speed, power, and access to various hardware devices isn't needed, you're going to find enterprising souls creating online competition for your favorite desktop apps, and it's all going to be handled in your browser by its built-in functionality.
After a week of trying to figure out the best way to structure my latest secret project, I've decided to target WebKit, because with a combination of a WebKit-based framework for the desktop and WebKit powering the default browsers on a huge portion of the smartphone universe, it's going to give my project the broadest possible reach.


Entries (RSS)