SVG Is The Future Of Application Development

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

A screenshot of Sun Labs's Lively Kernel running in the Safari 3 web browser.

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.

Win an Annual Membership to Learnable,

SitePoint's Learning Platform

  • jonathansnook

    The problem with the current state of HTML is that it’s elements for interactivity are quite limited without JavaScript. We have a limited set of form elements and then we fall back to the page request/response of old.

    This is a problem that SVG does not solve. Sure, it might make certain presentation elements easier to create but that’s more of a CSS issue than an HTML issue.

    This is something that HTML5 is trying to address with additional input types. We’ll still need JavaScript though to mimic more common complex desktop interactions like tree structures and tri-state inputs.

  • Sergey’s Mom

    If you belive for an instant that “(X)HTML/CSS really (is) the PostScript of the Future”, they you don;t know anything about PostScript or typography. Furthermore, by refering to HTML of the 90’s as a GUI language you just show how blindered you really are.

    HTML – HYPER TEXT MARKUP LANGUAGE – the name says it all.

    (X)HTML/CSS will become the PostScript or the future as soon as

    1) you get capabilities for anyone using any crazy technique to match what PostScript does today.

    2)you get tools that allow for creative exppresion with text and lines that you get with the great tools like Illustrator, Quark (in its day) and InDesign to name a few. With those tools a DESIGNER could DESIGN and produce output that would be consumed on a limitless number of output devices including screens on all platforms and high end print processing. So get real – or go work with some designers who specialize in print.

    Finally – if you knew anything ambout Memex and you might as well mention Xanadu (Ted H. Nelson) – this has precious little to do with that.

    Reading this is like reading a WorStar user group posting on Compuserve…

  • Mordy Golding

    Interesting read. With regard to Adobe support though, I think we’ll see less and less support for SVG — as it was originally something Adobe hoped would become some kind of interchange format that could be used internally between Adobe apps. With CS4 and Adobe Flash Catalyst out in the open, it appears that Adobe has decided to leave SVG by the wayside and move towards its own implementation, which is part of the Flex 4 spec, called FXG. You can read up on this decision and other pertinent info here:

  • Rob Russell

    @jonathansnook SMIL integration with Javascript helps that. It handles declarative animation. Opera’s had some support for SVG+SMIL for a couple years now and there are libraries to do SMIL in Javascript as a shim for UAs that don’t do SMIL yet.

  • Rick O

    Hmm. Amusing, but it’s pretty clear that you’ve never actually sat down and done anything with SVG. Yeah, SVG is useful from a progressive enhancement point of view, in an extremely limited number of scenarios, but “the future of application development”? Hardly.

    Do me a favor: set the Wayback Machine to 1998, find-and-replace all instances of “SVG” with “XML”, and re-read this article. Same tripe, different decade.

    Salon called. They want their content-free-zone back.

  • http://MeitarMoscovitz.com/ Meitar

    @jonathansnook: You make a good point stating that SVG doesn’t solve for the JavaScript-less case. At the same time, I don’t think interactivity without JavaScript is the goal. JavaScript is the most mature way to add “programmatic features” to Web-like payloads. That is, in the end, JavaScript is what gives us a web application as opposed to a web document, right? (I guess the other option for a Turing-complete language would be XSL? No thank you….)

    To that end, I think you’re also right in stating that things like animations do belong in CSS to a degree. So the question becomes, which language becomes the display primitive? CSS or SVG? There’s a conspicuous overlap there, which is not necessarily bad, but is worth exploring. Case in point: CSS3 Animations in Safari are relatively new and hardware accelerated, yet SVG animations have been around for much longer.

    @Sergey’s Mom: Hmm…not sure I’m following what you mean. Perhaps you thought I was saying HTML/CSS is comparable to PostScript? In fact, I was stating that it is not.

    @Mordy Golding: Yeah, I recently (and tangentially) heard about FXG. It does look interesting, and it’s certainly good that Adobe is building that as an open standard. That said, I’m not sure I understand how they’re justifying FXG as distinct enough from SVG to be worthwhile pursuing, apart from becoming the dominant vendor in the space. Then again, I’ll admit to not being intimately familiar with that particular technology. In any case, thanks for the link.

  • stelt

    And SVG is already used in many very different ways as seen on http://svg.startpagina.nl

  • phil

    Absurd. SVG has been fading for years. Once adobe ditched the player you didn’t have a good IE solution. And each browser supports a different level of SVG support.

    Just use flash. It’s easier, more powerful, and works everywhere.

  • Sergey’s Mom

    I stand corrected.

  • AndrewCooper

    I began reading a book about SVG and SMIL a few months back and was instantly fixated on it. However, when I went home to try some of the techniques out, the browsers didn’t display what I wanted because they didn’t support it.

    SVG and SMIL are, in my opinion, fantastic technologies and they should be taken advantage of and used and abused like our bodies are, but unfortunately, the browsers don’t fully support these two technologies.

    If all of the mainstream browsers fully supported both SVG and SMIL, sheesh, I’d be more happier than me getting my new PC for Christmas! Hehe.

    I love what Sun are doing with they’re Lively Kernel project. Although, I’m very weary on the Web OS, I think I’d prefer it if we didn’t go into the Web OS era, ever.

    AndrewCooper

  • Anonymous

    Blah. SVG is next to useless. Flash and/or Ajax/widget JS frameworks are the way to go.

  • jose

    SVG will never take off unless IE supports it. I dont see this happening, M$ wants to promote silverlight and adobe only cares for SVG. This is a major problem. SVG with JS and CSS could open up a whole bunch of new web apps and services (trust me I can think of many ways to make sites with SVG and make money). The problem is IE, sure there are libraries people have made using Canvas or VHTML or whathave you with JS, but we really need native SVG support in IE. As far as I know IE8 will not deliver that. IE8 is only being made because Windows 7 is on its way out, just like IE7 was only made cuz they wanted a shiny browser for Vista. IE9 is a long way from here, probably 2013 or later.

  • http://MeitarMoscovitz.com/ Meitar

    @jose (and some others): I see where you’re coming from with the arguments that if IE doesn’t support SVG, then the technology will not get far. At the same time, I have to say that I don’t see that argument holding water. There are examples of technologies that Microsoft has failed to implement and yet which have been instrumental in changing the Web as an application platform in the past. Perhaps CSS is one of the most notable of these.

    Any time arguments of single-vendor support (or lack thereof) are used as generalist claims of success or failure, I tend to have suspicions. The fact is that the world of tomorrow can not be controlled by a single vendor, no matter how influential—the people (people like you and I) just won’t stand for it because openness and transparency and freedom from single-vendor lock-in is one of the things the Internet has catalyzed for us.

  • http://manwithnoblog.com tuna

    Meitar, I’m totally with you on this one. SVG is something that people really have to start looking at. I have the distinct feeling that we are going to see it rolled out into the market place via different angles.

    On that note from a design view I would be investigating it with the view that soon my html/css skills won’t be all that valuable in the near future. And that a designer with just html/css skills is not going to be very employable.

  • biznit

    Your example of CSS not being supported by MS is wrong, they supported CSS early on while Netscape initially pushed a proprietary standard called called Javascript Stylesheets.

    I hope you’re right that SVG can succeed as a web technology without Microsoft’s support but it seems that if they are adamant in not supporting it, then unless there’s a fairly massive erosion in IE’s share it doesn’t look good. But I guess anything can happen..

  • http://panesofglass.org/ aranwe
  • Jacobus

    Good article, thanks

    SVG offers seamless integration with other XML technologies. It’s well supported by in many ways. It’s not just a web language. It’s a language to describe vector graphics, and allows you to programmatically do so. I’ve been using SVG for 9 years now. The support has gone from strength to strength. Whether IE supports it or not, is a Microsoft problem, it’s affect on SVG adoption is minor compared to the number of SVG applications. A great many desktop applications use SVG under the bonnet. It will never go away.

  • K

    I have been saying this since 2000 – 9 years in the wilderness.

    The only important and perceptive question is why Microsoft and Adobe want SVG to remain inadequately supported?

    Both Flash and Silverlight are free downloads, so its not as if they are making money there… Somehow, each of these leading contenders for the coming “visual web” feel the need for controlling the developer base. SVG is owned by a non-commercialized hacker base of enthusiasts who use text editors to write amazing web apps. The commercialized droid developers are being sucked into Flash and Silverlight development environments, from which they may never emerge. Pray for earthquakes.

  • James

    It’s frustrating to read so many say that svg may be useless in times to come.

    What to people say in response to Apple’s improved support for SVG in Safari 4?

    I am currently transforming XML slope stability information in order to display images and text to represent the data held in the XML (transformed using XSLT). I have chosen to convert the images to SVG for display within a XHTML page to both maintain scalability/clarity and to add some interactivity.