With the recent release of Google’s Chrome browser, I’ve been thinking a lot about the possibilities the growing capabilities of the Web gives us. Almost everything about the new Google browser, from the process-per-page sandbox to the application window UI, screams “application platform.” One of the key ingredients is Chrome’s new V8 JavaScript engine, which is rapidly making the language a viable competitor for serious computing thanks to its execution speed.
Of course, Googlers aren’t the first or only people to dream up the possibility of making web-based applications first-class citizens on the desktop. There is Prism (formerly WebRunner), a Mozilla project that launches a web page without any browser-related chrome. There is also Fluid, which does much the same thing for the Mac’s WebKit engine. These programs are all basically thin clients for cloud computing applications like Apple’s MobileMe, Google’s suite of tools, or any of the various “Web 2.0” properties that have sprouted in recent years.
Companies like Adobe and Microsoft have each jumped on this bandwagon as well. Adobe’s offering is called AIR and enables developers familiar with Web development technologies such as MXML, ActionScript, and Flash or HTML, CSS and JavaScript to write networked desktop applications. Microsoft has a competing offering called Silverlight. Both are cross-platform and are capable of utilizing Web standards as core parts of an application’s code base.
Is (X)HTML/CSS really the PostScript of the Future?
I started my technology career in the 90’s making web pages because HTML was the easiest “GUI language” to learn back then. As we know, trying to write cross-platform browser-based code was nothing short of nightmarish for a long time. However, as the web stabilized and solid engineering practices began to permeate the web development community, the trifecta of (X)HTML, CSS, and JavaScript became arguably the most widely implemented GUI toolkit on the planet. Now, its ubiquity and implementation-agnostic nature is what makes developing web apps so attractive, but could we be approaching this challenge from the wrong angle?
The notion that HTML is a display language has been proven long ago to be a Bad Thing. CSS taught us to separate our presentation from our content, and the doors that opened when we did it were invaluable. Today, however, we’re still delivering web applications as HTML documents with a bit of scripting layered on top. This works, but is strangled by all of HTML’s limitations. Fundamentally, HTML is not an application delivery format, it is a content description language, despite the valiant efforts of the HTML5 Working Group.
Enter the red-headed stepchild of Web graphics: SVG
Where are our drop shadows? Rounded corners are still a PITA to do in HTML. Getting animations and styled modal dialogue boxes to work easily requires us to pile layer upon layer of JavaScript abstraction onto our pages in the form of libraries, and still we can’t do the sorts of things that GTK and OpenGL can do for us in desktop apps.
So if HTML can’t deliver for us here, what will? Microsoft wants us to use Silverlight and Adobe wants us to use Flash and AIR, of course. And Apple…? Apple ostensibly wants us to use HTML5’s canvas. Both Microsoft’s and Adobe’s contenders are proprietary, which seems to be reason enough for web developers to avoid them to a certain degree, and all of them muddy HTML, which is a dangerous thing for the semantic web.
But Apple actually has a trick up its sleeve. Like Mozilla’s been doing with Firefox, Apple has quietly been implementing better support for SVG, the W3C’s Recommendation for XML-based vector graphics, into WebKit. SVG delivers the same kind of vector graphics capabilities that Flash does, but it does so using all the interoperability benefits that XML brings along for the ride.
SVG is great for graphically displaying both text and images, manipulating them with declarative visual primitives, and it comes with a host of lickable effects. Ironically, SVG was originally jointly developed by both Adobe and Sun Microsystems but recently it’s Sun Labs that has been doing interesting stuff with the technology. The most compelling experiment of this kind has to be Sun Labs’s Lively Kernel project.
Putting some Lively into the Web
Even though it doesn’t claim to be a “web application” or a “web operating system” like many other projects, the Lively Kernel is a full-fledged graphical application environment and even includes its own IDE. It’s reminiscent of early SmallTalk implementations, no doubt thanks to the influence of one of its core developers, Dan Ingalls, who was also one of SmallTalk’s co-creators. What’s more, the Lively Kernel is built entirely in JavaScript and SVG.
The project’s page says that it places a special emphasis on treating web applications as real applications, as opposed to the document-oriented nature of most web applications today.
For web application developers, the most interesting thing about this project is that it accomplishes many of the graphical things we can’t do in HTML (using only a subset of the SVG standard, no less) and provides the ability to interact with real JavaScript objects as opposed to HTML DOM nodes. Windows are JavaScript window objects, as are sliders and buttons, and when you change the properties of a button its GUI representation updates accordingly.
Moreover, since the Lively Kernel is based on published, open standards, it’s portable across any user agent that supports said standards, including Firefox 3, Safari, and Chrome. When Mobile Safari adds SVG support, the Lively Kernel will probably run on iPhones, too. Further, WebKit is in the infrastructure being developed as part of the KDE project, which is used as the basis for a number of mobile devices (like recent models of Nokia’s smartphones), and which already ships with a number of games that primarily use SVG as their graphical primitives.
What about semantics? Let’s have our cake and eat it, too!
HTML was a fantastic success because it’s really good at generically describing content in Web documents. Since both SVG and XHTML are applications of XML, we can mix the two in the same file, or reference one from the other, and literally get the best of both worlds. This is exactly what the Lively Kernel project promotes as well, since they say that In general, one of our goals has been to leverage existing technologies as much as possible.
A marriage of “lickable” graphics with semantic content is precisely what we’ve been after for years now. Interfaces built with the combination of HTML and CSS just aren’t capable of providing fancy GUIs, but as this was never what that technology was designed for, that limitation shouldn’t be a surprise. On the other hand, every application has some data associated with it and if Web “mash-ups” have taught us one thing, it’s that one application’s data is far more useful when combined with another application’s data. Lucky for us, describing data and its relationship with other data is a natural fit for standard Web technologies like XHTML and RDFa.
One way to describe what we’re really talking about is linking the “semantic desktop” with the “semantic Web.” The folks at the KDE project have some interesting stuff to show us on this front, too. KDE’s latest release has made some fascinating inroads into the semantic desktop by providing low-level frameworks, collectively called NEPOMUK, for applications to communicate with one another, exchanging information about what’s going on and enabling the application to behave intelligently with regards to what information to display or how to supplement a user’s activity. By itself, as this Linux.com feature quotes Ansgar Bernardi who is Nepomuk’s coordinator saying, that isn’t anything new. But combined with the massive, distributed knowledge store that the semantic Web can unlock, a semantic desktop like that brings us another step closer to the realization of Vannevar Bush’s dream of the Memex.
Forward-looking web sites are already using SVG today, and there are a number of tools available to help ease its implementation. The Raphaël JavaScript library is particularly noteworthy thanks to its ability to output SVG to conforming browsers and VML to Internet Explorer. This enables front-end developers to use vector graphics in a cross-browser compatible way with only a single source to maintain.
With the increasing ubiquity and accessibility of these Web standards, a combination of semantically structured data coupled with capable display primitives such as SVG are clearly a core part of the Web’s, and possibly even the semantic desktop’s, future graphical design toolset.
Meitar Moscovitz
