Caveat: I’ll be the first to admit I have zero experience with AIR (or Mozilla Prism for that matter), so if anyone can educate me, please feel free below.

If I’m a desktop application developer, I’ve got to decide on a language and framework. Is it easier to build an application using HTML+CSS+DOM+JavaScript (+SVG+XUL) or to use Flex+ActionScript or to use C#+CLR or to use Java+JDK or to use C++ with Qt/Gnome?

I think Adobe is right that picking from the “Open Web” stack is a slightly easier in-road to application development due to the declarative nature of the markup and the lack of a compilation step. But I don’t think it’s why web applications are seeing such an upsurge. To me, the answer is the complete lack of a need to worry about deployment (web app developer) or installation (web browser user). The fact that the web app developer does not have to maintain older legacy code is also a huge win. Once a new version of your application is released, no one in the world is using your older code, it’s instantly retired.

Here’s a snip from AIR’s own documentation where it states:

“On Mac OS, to install an updated version of an application, the user must have adequate system privileges to install to the application directory. On Windows, a user must have administrative privileges.

If the updated version of the application requires an updated version of the runtime, the new runtime version is installed. To update the runtime, a user must have administrative privileges for the computer.”

To me, the bits about the runtime sounds like the same sort of mess that Java and .NET application deployment have with mismatched JREs and CLRs for the past decade. Hopefully changes to the underlying platform are kept minimally disruptive – but the developer really has no control over that.

It does sound like Adobe is trying to make it easier for application developers to employ auto-update functionality (incidentally, so is Sun). It just sucks that each developer has to worry about this individually still.

To me, the sweet spot with these Light-weight Offline Application Frameworks (LOAFs?) will be when enabling auto-update is as easy as it is with Firefox extension development. But that still doesn’t solve the problem of every user having to first download the runtime to ‘bootstrap’ him/herself.

And yes I’m aware that there are some big down-sides to Web Applications. Lessee, differing behavior of platforms (user agents) is the biggest cost. Lack of local storage (which may change in a decade with HTML5) and the cost of a server are also biggies.

It will be interesting to see how web development will change in the coming year, as DHTML toolkits like Dojo, YUI, MochiKit, Google Web Toolkit, Microsoft Atlas continue to mature, Adobe’s Flex 2 continues making inroads and Microsoft’s WPF/E deployment gets underway in earnest. Meanwhile, the venerable Java Platform is still evolving, parts of it now open source and Jave SE 6 recently becoming available.

All of these are signs that seasoned web developers are finally ready to move up the tool-chain stack away from the simple text editor. I think key things to look for in differentiation between the various frameworks are:

• Tool Support: What kind of developer tools are out there to support development in your framework/language(s) of choice? From what I understand, Adobe has always been good with developer tools. On the Java side, there’s NetBeans. On the DHTML side, there’s Eclipse’s wtp. Maybe it’s time I looked into IDEforLaszlo in the New Year. Do your tools allow you to quickly and easily test and debug your code?
• Community Involvement: Not necessarily just an open source community, but a vibrant one with lots of energy and open participation. Of course, a transparent development process will help here.
• Cross-Platform Support: You need to support all of the “high tier” browsers like Firefox, Opera and Safari and you need to support multiple operating systems equally. People are passionate about their browsers and operating systems. Projects need to be careful not to lose the next hot web developer to a more compatible framework.
• Ease of Deployment: How easy is it to change one line of code and deploy that change? That was always one of the beauties of the early days of the web – simply update your HTML file and save it on the server
• Beware Of Vendor Lock-In: This is going to sound very anti-corporate, but the truth is that when one company controls the toolkits and the standards, there is always the potential for that project to be shelved or neglected or dropped in favour of new ventures. This ends up taking its toll on the web developer. With open standards and open source toolkits, developers can shield themselves from the whims of corporations.

Needless to say, competition will engender a very exciting year, with the winners being the web community as projects vie for the hearts of hackers everywhere, sparking further innovation. I hereby dub 2007 as the year of the “Web Hacker Wars” – let the battle begin!

Anyway, sorry for the CPU hit, but ’tis the season. If anyone can let me know if a Safari nightly build displays the snow yet, that would be awesome – you can consider it your Christmas present to me.

Hm, I wonder if I should try to modify the library to use the Dojo2D API in the Dojo toolkit for that true cross-browser effect. That might prove to be a fun little project and a good way to dip my toe in the Ajax toolkit pool…

[Update: Merry Christmas to me. Allan Jardine tells me in his comment below that it's snowing in Safari too. Great news!]

There are some articles on the site that delve into SVG, JavaScript, Ajax, etc. I’m writing a series of articles there about integrating SVG into web applications, so walk on over there and check it out (read Part One).

Ironically, Virtual Earth looks like it has much more functionality, yet most of it is broken in Firefox 2 (not in Firefox 1.5). For instance, the paths are not showing up for me in Firefox 2. Furthermore, Virtual Earth seem completely broken in Opera 9 which is a significant step backwards from 5 months ago.

Via JD on EP. Adobe announces End-Of-Life for SVG Viewer. I’ve tried to keep optimistic about the Adobe purchase of Macromedia but I guess I always knew it was a matter of time before Adobe draws the line and says “No more open standards”. It’s unfortunate because it was the one thing that I still liked about Adobe – I can’t stand their bloated PDF viewer, FrameMaker or Photoshop anymore.

I think at the very least, Adobe should take into account former employee Jon Ferraiolo’s suggestions. Since the Adobe SVG Viewer is the only realistic and mature option for SVG content in Internet Explorer for the conceivable future, removing it as a download in January 2008 could only be taken as an openly hostile move against the SVG development community. Even if IE8 moved fast and included some support for SVG it would not be truly ready for primetime by the time Adobe removes its download.

If we don’t receive any concessions from Adobe on this, what is the development community left with? Develop an IE browser plugin out of Mozilla? A Batik-based browser plugin? Do we look to Amanith or Renesis?

Personally I’m going to keep my eye on Dojo2D since it’s been in my mind for some time that I need to start moving up the stack in terms of web development anyway.

OpenLaszlo Experiments With SVG

Henry Minsky contacted me about his work creating a SVG kernel for the OpenLaszlo project. I encouraged him to take make his experiments public. Looks like promising stuff for only two days worth of effort!

GWT Supports SVG

Robert Hanson gives everyone a clue to how to get the Google Web Toolkit to support SVG.

KevLinDev Updates For Modern SVG Support

Kevin Lindsey gives an overall thumbs-up for Opera 9 support of SVG, updating his site’s experiments so that they work in Opera 9.

SVG Cards Finally Updated

David Bellot finally updated his SVG Playing Cards at the end of June. I used a very trimmed-down version of his original SVG cards in my games Solitaire and Freecell. I’ll be interested to see how modern browsers can render this new version of cards.

Dojo on SVG

dojo-svg, a library/module of the Dojo toolkit has been advancing. Further news along this front is that Dojo-gfx will be a “universal” front-end graphics application that can use SVG or VML underneath as needed.

Firebug Creator on SVG

Joe Hewitt, creator of the awesome Firebug extension for the Firefox browser has been doing some experimentation with SVG. There are some things in particular that he doesn’t like about the way SVG and XHTML mix. I don’t agree with his conclusions, but I do agree that coordinates in SVG take a little getting used to if you’re coming from the HTML and CSS camp.

Treebuilder Renaissance

Holger Will has been going strong ever since his return to web development in SVG. His website is a wealth of information and experimentation in SVG, including recent entries for progress bars, bar charts, SVG fonts and tutorials. All within the space of just one month! How does he find the time?

The videos I checked out were:

• The Future of Internet Explorer
• Chris Wilson’s Talk on Web Standards

The Future Of Internet Explorer

The “Future” talk is mostly a panel discussion and question/answer period on ideas for things that IE should focus on for future releases, including nebulous things like how often should they release. There were a couple interesting suggestions from key web development folks though, here are the paraphrases:

Eric Meyer: The next major version of IE should be the first browser to support all CSS3 Selectors and the CSS3 Backgrounds and Borders module.

Molly Holzschlag on preserving backwards compatibility at the expense of improving standards support: This makes sense for some things, but software will change and web developers have to deal with it, that’s what we’ve signed up for. I agree. But I don’t have a million-dollar website to maintain.

Not a lot of tangibles here, but it was an interesting discussion nonetheless.

Microsoft and Web Standards

The Standards talk was more interesting to me. Chris makes some good points about why “open standards” are not always a magic answer, citing “design by committee” as the main reason. It is certainly possible to build a tighter, more focused specification if it’s developed internally. But Chris also makes the case that sometimes these proprietary standards can end up becoming “de facto” or even “de jure” standards. Microsoft’s XMLHttpRequest object is a good example of this (see this new W3C spec). Heck, so is Netscape’s JavaScript actually (see the Ecmascript specification).

Chris ends the lecture period by offering three points to spark the Q&A segment:

• there are lots of formats that make up the web, not all of them are open
• open standards have always formed the interoperable core of the web
• over time interoperable core increases (HTML, XHTML, CSS, XSLT, SVG)

After this, the Q&A period begins, where the first question out of the gate (at approximately 28:00) is “What are your plans for SVG?”. Chris’ paraphrased response was to the effect that Microsoft does not pre-announce software, though they are becoming more open with communications (I agree). Chris made it clear that they have heard the request many times, that they do think it’s becoming an important part of the “interoperable core” of open web standards (as evidenced by his inclusion on the slide). The bottom line: At this time, they cannot state anything other than “not in IE7″ (which we already knew).

Now for my guesswork: I do think it’s promising that they are currently working on multiple versions of IE and have a long-term roadmap for IE. The message I get from Chris’ talk and slides is that Microsoft is committed to supporting open standards, and they consider this important. However, they also see a strong benefit in driving their own proprietary formats for purposes of innovation. In other words, they know they can’t get away from open standards, as much as they’d like to.

Thus, if I had to guess: The next major version of IE after Version 7 will support XHTML (application/xhtml+xml) with some form of native support for SVG (at least the 1.1 Tiny profile to be compatible with all the other major browsers). At the same time, this probably won’t happen until the Windows Presentation Foundation (WPF) and its “lighter” cousin WPF/E have been released broadly.

A seemingly easy solution in the IE7 timeframe would be to have IE7 bundle the Adobe SVG Viewer with its default install.

Anyway, watch the video and tell me what you think!