Inside every browser is the core of the ideal client-side application environment, incorporating everything that I'd estimate half of commercial applications need. There's the best dynamic, object-oriented, loosely typed programming language, bar none (JavaScript), transparently bound to a very simple yet extensible presentation layer (DHTML, CSS, XML, DOM, SVG...). Browser-based apps don't require specialised development tools, or any tools at all. All that keeps your browser from being the perfect client app environment is speed, stability, strict adherence to standards, and offline capabilities. That is not too much to ask; it's all within reach, right now. It's a matter of adjusting our priorities and perspective. Forget about trying to make projects fit browsers and focus on higher objectives. We want a cross-platform, cross-architecture development platform that can take an app from behaviour-accurate prototype to full functionality in stages and with minimal skill. We want applications that can be QA'd in situ at the operational level, patched remotely, and updated automatically. We need to adapt to specifications that are altered while the project is underway. Code has to be ultimately reusable, and we need the capability to easily reach out to legacy back-ends. We never want to hear our support staff tell a user "we can't reproduce that problem". If we have to let a developer go, we want to know that he can't lock up his code on the way out, and that anyone of comparable skill can take over and be up to speed in a couple of days. Now, knowing what we want, we can think about how to achieve all of this, and now we can come back to the browser. If we could achieve the ideal, a browser's got everything a development project would love to have but can't dream of putting into the schedule. The trouble is that browsers are designed for surfing, not as application platforms. Think about it. If you were cranking up a new client development project, would you issue a statement of objectives that it must look like a website, take twenty seconds to paint a window, offer no feedback when you click a button, skip reporting the progress of transactions, refuse to run unless you're connected to a network, and force users to re-enter form data if there's a hiccup in delivery? It's telling that the first thing an erstwhile web application does is free itself from the trappings of a browser: It removes the navigation bar, the menu (when it can — OS X doesn't allow it) and the status bar, redirects the right mouse button away from the default context menu and makes it impossible to resize the window. If you use the browser, the standard is to work like hell to hide it, and to solve performance problems by embedding Java or ActiveX objects. It reads like a no-win deal until you realise that you don't need a fat, clunky browser. You don't need to host a browser in an application window. Just take the framework shared by multiple commercial browsers and bake it right into your project. That's WebKit. At a total cost of nothing and with free lifetime updates, it's as sweet a deal as you'll find, and unlike many open source projects that you'd love to use but which vary in the quality of support, documentation, and maintenance, WebKit is driven by companies like Apple, Nokia, and most recently, Google, that rely on it for commerce. The Iris Browser from Touch Mobile, which uses WebKit, is the first worthwhile free alternative to Internet Explorer on Windows Mobile devices, and it's the best first pass I've seen yet on borrowing iPhone's touch interface. Even though it's most frequently seen in browsers, WebKit is a lot more than a browser in a can. It advances the state of the art faster and farther than is required for a browser. The best example of this is WebKit's new tokenising JavaScript engine, SquirrelFish. The latency associated with the retrieval of most web pages makes the speed of JavaScript execution a minor issue, but JavaScript's poor performance takes it out of contention as an application language. It's not a hard problem to solve; there is no shortage of engineers skilled at making interpreted languages run faster. There just wasn't the will to do it for JavaScript until some people realised that JavaScript is a serious language in need of a serious implementation. SquirrelFish takes two vital first steps toward elevating WebKit's JavaScript to first-class status: Mapping bulky JavaScript to more efficient, partially digested ("compiled") bytecode, and using a register model instead of a stack model. The stack model stuffs all of the data passed between functions into a single pool of memory. It is the duty of every function that uses the stack to leave it precisely as it found it lest other function calls get the wrong data passed to them. Functions have to pull data from the stack to make local copies for their use, and to return data to the calling function they must shove the results back onto the stack. Stack-based interpreters are easy to write, but hard to optimise. Register-based interpreters use a direct reference (in loose terms, pointers) to data needed to call a function. Just this one change from a stack-based interpreter to a register-based virtual machine delivers performance gains of 1.5x to more than 3x depending on the operation, and that's how WebKit without SquirrelFish compares to WebKit with SquirrelFish. It borders on unfair to compare WebKit (Safari 3.1) performance to Firefox, but it does highlight the difference between a JavaScript for applications and a JavaScript for surfing. It's not that no one thought of making a bytecode JavaScript, any more than it's a new idea to put smoothly scaled and animated vector graphics in a browser (SVG). No one cared to do it because the day-to-day surfing experience wouldn't be enhanced by it. WebKit has higher aspirations than surfing, and there is more advanced science in WebKit than its JavaScript interpreter. The whole framework is shifting into ever higher gears in performance, standards compliance, completeness, and stability. WebKit is a framework that brings the benefits of a browser to all applications, across platforms, even ones that don't use the network. It doesn't hurt that WebKit is free and open source, that a Safari-workalike browser is included in the distribution, and that it uses middleware (HTTP) and object representation standards (XML) that bind it to all back-ends. Get WebKit and be proud to use browser technology in serious applications.
Apps gets browser-like capability with WebKit
Tom Yager salutes taking the browser's benefits beyond the browser