Don’t worry, Flash isn’t dead yet, but it’s clear that the tides are changing these days, with more devices entering the market that do not (and cannot) have Flash installed. Frankly SWF is no longer the reliable format it once was. Yes you can reach 90+% of the desktop browsers, but what about the millions of mobile web users?

So lots of people have had the same idea: Adobe needs to update its tools to output in Open Web formats. Simple, no? Instead of Save As SWF, Save as Web App, right?

“But wait!”, I hear some Adobe lovers cry. Rendering across browsers isn’t consistent! The DOM is a mess! There are tons of CSS layout bugs! SVG/Canvas support across browsers is uneven at best! There are many features that aren’t even supported in some browsers yet!

Hogwash. OpenLaszlo foresaw this transition years ago. GWT does the same thing.

You Adobe folk are bright engineers. You just have to make it work. Exactly like you made it work, and continue to make it work, across Windows, OSX and Linux graphics systems. The rendering layer is at the browser now, not the operating system.

There are lots of JavaScript frameworks that help to smooth out the script and DOM bumps. There are tricks you can do until SVG/Canvas feature X is consistently supported. Someone already figured out how to render SWF files using SVG+JS, for goodness sake.

And guess what – two of the major browser engines are open source – which means if a particular feature is missing in those implementations you can put an engineer on it for two months so that in the next version of the browser, it will be there for you.

You just need to think ahead.

As I’m sure you are.

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!

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?

One of the interesting things about web applications is that they can change from one visit to the next. Depending on your point of view, this can be either incredibly frustrating or delightfully surprising. If you need to rely on effective execution of an application for critical business reasons, then changing the application willy-nilly is not a good idea. What’s key for RIAs is that changes to the UI should seem intuitive and not too jarring.

When I first started using Pandora, I made a couple suggestions for improvements on the Pandora Blog. I’m happy to see that the album title is visible and that there is now a “progress bar” indicating how much of the song has been played. Both changes were done in a way that do not change the way you interact with the main UI.

They’ve also added a new popup menu that slides up when you mouse over the song. This allows you to rate the song with one-click (before this involved two clicks). This is great, because I actually use this feature occasionally. My only complaint is that I would have switched the order of Thumbs Down/Up (I accidentally gave a thumbs down to a song I liked). I’m sure I’ll get used to it.

I’ve made it clear in the past that I love Pandora. To me, their UI just has that organic feel to it. It seems to know what you want to do and is happy to let you do it. Ok, I’ll stop gushing now…

The application uses OpenLaszlo, which “compiles” to Adobe Flash at the moment. I notice that when I right-click, it states that it uses Flash 8. Does that mean that Linux users are not able to use Pandora? Here’s hoping that OpenLaszlo hurries up and implements its DHTML support.

As for Pandora’s advertising model, displaying an ad off to the side is very considerate to its users, but it might not be very effective. Often, I’ll just let Pandora run in a browser tab and never visit it. However, if I’m thinking about it, I’ll occasionally go back to the tab to rate a song I like or dislike. Even when I do this, if I’m using Opera, I can tear off the Pandora tab and size it to just the size of the main Pandora UI (meaning the ad is not even visible). I wonder how effective Pandora is at selling music… Anyway, I predict within a year that we’ll have audio ads in Pandora as it rides the Crap Wave. I’ll still probably visit though.

Obviously I haven’t spent enough time looking at the Web Applications 1.0 (HTML5) spec, so this was an eye opener for me. Once we get over the graphics hump in the browser, the silent (no pun intended) stumbling block for producing a quality gaming experience in the browser is audio. Ironically this is something I planned to blog about soon so this news is rather timely (and thankfully, avoids some embarrasment on my part).

Some folks (like my cousin, Scott) have got around this current browser limitation by making JavaScript audio libraries that sneakily use Adobe’s Flash underneath.

Personally, I was eagerly awaiting browser implementations of SVGT 1.2 (which has not yet been released as a Candidate Recommendation) where audio and video media can be embedded/triggered. As of today, no browser has made mention of supporting SVG 1.2.

On a somewhat related sidenote: Some have questioned what audio is doing in a graphics specification in the first place, but members of the SVG Working Group have stated words to the effect that “SVG” is just an acronym and the specification is now extending beyond the realm of just “graphics” and into the realm of a more complete RIA specification for mobile devices (as well as desktop browsers). In my mind, it begs the question of what the Web Applications Formats Working Group will do and how the WHATWG’s HTML5 fits into the picture (if at all).

Hey, at this point, I don’t care where/how it’s implemented, just give me the cross-browser capability for Pac-Man to make “gobble” sounds.

If I have to cast a vote, I say browsers should go with the HTML5′s audio object because SVGT 1.2 will be a long time coming. So I think it would be great if other browsers pick up on this and provide support for the audio object. The capabilities look a little crude at the moment (play a sound, loop a sound, stop a sound and only via script) and the spec does not specify a required format that browsers must support (WAV format is mentioned in the examples).

If enough browsers pick up support for for audio and graphical capabilities this would be a way for OpenLaszlo to get DHTML targets at parity with Flash-based output targets. Something I’ve been thinking heavily about lately.

Congratulations to Opera on being first to implement this. I bet it catches other browser developers by surprise…

What Is Laszlo? Laszlo is an open source, object-oriented, XML-based user interface language. That sounds like a mouthful, but you can think of it as similar to Mozilla’s XUL, Microsoft’s XAML and Adobe’s MXML. Laszlo is supported by Laszlo Systems.

The file format (LZX) is written in XML, where you declare your User Interface objects/widgets/views. LZX uses JavaScript to provide the functional bindings/scripting for the applications using one of three techniques: 1) Global script using the <script> tag (similar to HTML, SVG 1.1), 2) Methods using the <method> tag (similar to XML Events, SVG 1.2), these methods are local to the individual XML objects that have been declared and 3) using constraints (this technique is somewhat like a cross between declarative and procedural programming). An example of constraints in use might be:

When the window width changes, the button’s width will also change. This is an example of a constraint. One challenge in Laszlo programming is to understand when to use global scripts, when to use methods and when to use constraints.

Laszlo also has a <drawview> tag that acts something like the HTML canvas tag, allowing vector graphics to be procedurally generated while allowing functionality (event listeners) to be bound. It would be nice if a future version of Laszlo would support declarative vector graphics as well (embedding SVG elements directly in LZX of course).

I also wonder if LZX could be integrated with CSS. A lot of work went into CSS and it would be a shame not to try and leverage that across the web developer base. The challenge is that CSS came from the need to separate the presentation/design from the content. There are many benefits to this, not least of which is that the designer skillset is different than the developer skillset.

Currently presentation can be mixed heavily with content and functionality in LZX, though these can be delineated by carefully dividing your application into libraries that contain design elements (classes, fonts, other resources) and keeping these libraries separate from the actual application (i.e. the LZX files that actually instantiate these objects). Personally, I don’t believe separation of content, presentation and functionality need be perfect in an application. What’s really required is for the designers, content producers and developers to have a sound software architecture that avoids excessively strong coupling between the disciplines, but that still allows them to work closely together. The best apps are those that appear seamless in terms of content, functionality and design.

Anyway, the move towards different compilation targets for Laszlo is great news. I see this as a bold strategic move in the web client development space. Personally, I think it’s the next wave – we have been moving away from the document-based approach of traditional HTML programming for quite awhile now. Using a higher-level language that gets compiled into something “lower level” is not a new concept, even in the web development space. Anyone who has programmed a non-trivial web application using PHP plus SQL plus XSLT plus XHTML plus CSS plus JavaScript plus SVG will realize that we need to move up the stack.

As for other compilation targets, we know that Laszlo has future plans for the Windows Presentation Foundation (WPF). I hope that SVG will one day be in their sights as well. In the past, I’ve been leery of looking into OpenLaszlo simply because LZX compiles only to Flash format, even though they are open-source and even though I think the idea of Laszlo is quite sound. This illustrates to me how easy it is to become an “open standards” zealot and put the blinders on. The fact that the W3C Web Applications Working Group is looking into one of the existing four XML UI markup technologies (XUL, Laszlo, MXML and XAML) is promising.

To give you a taste, here is a simple “Hello, World” LZX application:

Go here to see this application in use. Drag the window around. Resize it. Wipe the drool…

Currently, LZX files are compiled into Macromedia Adobe SWF executables before deploying on the server. But I really get the impression that even Laszlo Systems recognizes this as a somewhat unfortunate (or limiting?) association. As they strongly state: “Laszlo isn’t Flash”. They want to support different backends, to make their technology less vendor-lock-in and accessible. Unfortunately, at the time of the project’s inception (and even today) the only viable platform to actually deploy against was (is) Flash. Other future backends might be CLR, XUL, SVG, etc.

Subsequently I discovered Pandora and then learned that it was built with OpenLaszlo. The user interface for Pandora is clean and quite to the point so my impression for OpenLaszlo went up another notch, though at the time I was still blindly dreaming of SVG and hating Laszlo for being Flash. At the time I did not understand that the two could (and should!) exist side-by-side.

I then learned that the W3C recently put together a Web Applications Working Group. Their charter is to reuse an existing technology like XAML, XUL, OpenLaszlo, or MXML and marry it with such technologies like CSS, SVG, XForms, and SMIL to create an uber-web app platform. This will be great, because Lord knows we don’t need yet another technology in this space. Only problem will be: Which one to choose?

Microsoft is never going to willingly play nice with XUL or MXML if it already owns a strong competing technology. But the same applies the other way for Adobe. And are any of these company’s going to hand their technologies over to W3C? Furthermore, XAML isn’t fully baked yet (my understanding) and XUL hasn’t seen any major successes outside of Firefox/Thunderbird. On the other hand, OpenLaszlo is a relatively small company and has got a few years of successful deployments in various sites (like Pandora). And it’s Open Source, which means it’s got to be a “good thing”, right? Right? Sooo… based on my five minutes of internet research, I think OpenLaszlo has got the best shot

Ultimately what would be cool is if one day a web developer could deploy a bunch of XML, LZX, EcmaScript, SVG and SMIL, either in separate files or combined in a multi-namespace XML document (i.e. “compound document”). The browser would know how to interpret all XML grammars natively. The web designer would use LZX to define the application at a high-level, XHTML to describe semantically structured and linked text, uses EcmaScript to describe the application’s functionality, uses SVG/CSS to define its visible presentation (or its “skin”). The browser would know what a <window> or <button> object does in terms of its functionality, it would hook up JavaScript event listeners to the widgets, it would have default bindings to know how to “skin” them, but they could also be styled via CSS or custom painted via designer-supplied SVG.

Now here’s the even cooler part, upon first loading, the browser could “compile” this web application into some native format and keep it around in a cache if it wanted (i.e. Internet Explorer could compile it into cached .NET/CLR objects, Apollo could compile it into cached SWF objects, Mozilla could translate the LZX into XUL… This means the browser wouldn’t have to re-interpret the XML document(s) from the server unless some change had been made and execution could (theoretically) be just as snappy as with regular desktop apps. The browser now really does become an operating system, complete with windowing system and compilers…what a concept.

This last point was an important one, because it also means that companies like Microsoft and Adobe that need to make money on this technology in order to survive can update their expensive authoring tools to generate LZX+SVG+… content that will work optimally in their technology while still supporting the common platform.

Now we need a cool and unused acronym and a slogan for the XHTML+LZX+EcmaScript+SVG+SMIL format to get web developers’ imagination stirring. How about “You can do more with XLESS”? Ok, before I get flamed – I really am joking about that one… Besides, I think the W3C already has the WICD acronym ready for this…

But all in all, it’s a very exciting concept …

Opera

First, a little over a month ago we got a preview of Opera 9 and it turns out that their SVG implementation has taken a leap forward to support filters, patterns, scripting, text on path and many advanced SVG Full features. When it is released I believe it will far surpass Firefox’s 1.5 implementation. Some folks have told me that Opera is targetting full SVG support and plans to support CDF in a big way, which is fantastic news.

Mozilla Firefox

Which brings us to Firefox 1.5 being released last week with the first native, scriptable SVG implementation in a major browser. While this is genuinely good news for SVG as a web standard and reception by newbies to SVG has been favorable (even though confusion results from all the non-conforming SVG content out there), reception by SVG enthusiasts has been a mixed bag. Some people even think that Firefox shouldn’t have turned on their SVG implementation by default.

Unfortunately, tentative roadmaps for Firefox show that Firefox 2 will be based off of the 1.8 branch, while Firefox 3 will be based off the 1.9 trunk. At present, any improvements to SVG support in Firefox are limited to the trunk (text on path, filters). This means that improvements to Mozilla’s SVG support (other than perhaps bug fixes) will appear some time in 2007 (over a year away).

Adobe

Next, Adobe completes their acquisition of Macromedia and gives us a couple hints at what their stance on SVG is:

How does Adobe’s acquisition of Macromedia affect Adobe’s support of SVG (Scalable Vector Graphics)?
    Both Adobe and Macromedia have been part of the W3C working group that defined the SVG-t specification. While Flash and Flash Lite have gained critical momentum with customers and partners worldwide, particularly in the fast-growing mobile market, we recognize that both SVG and Flash have had success globally. As a result, Adobe will continue to support the display of popular graphics standards, including SVG-t and Flash, to meet the needs of customers and partners worldwide.

and

What are Adobe’s plans for Flash Player and Adobe Reader?
    Our long-term plan is to develop a “universal client” by combining PDF, Flash and HTML in a single, integrated runtime. Of course, we will continue delivering the Flash Player as a small, efficient runtime for content and applications on the web, and Adobe Reader for viewing and interacting with PDF documents and forms. The integration of these technologies into a unified framework creates a ubiquitous platform that runs on virtually every device, and dramatically expands the opportunities to create compelling solutions.

Ok, speculation time (with apologies to John):

The first quote specifically mentions only SVG-Tiny. Any answer from Adobe which doesn’t even mention their Adobe SVG Viewer, which supports SVG-Full and is still currently the best and most popular way to view SVG content in the majority of browsers, can only signal bad news. The mention of SVG-Tiny is significant because Macromedia already supported SVG-T so this just tells me they are keeping that support alive within the Flash Lite platform.

The second quote is interesting because they mention an “integrated runtime” support HTML, PDF and Flash, but no mention of SVG. David Mendels has confirmed that this “integrated runtime” will be a standalone piece of software codenamed Apollo, which means that Adobe is now planning to enter the “web browser” market. Will it support SVG?

A couple more facts: Adobe has been vocal about their frustrations with the pace of the SVG Working Group in the past. Adobe failed to attend the SVG.Open this year.

So what I read from Adobe is that they are giving up on SVG-Full but are forced to keep SVG-Tiny support around because of its wider deployment in the mobile arena. Not good news for the SVG community if true. It’s a blow to the knees of “SVG on the web” just as native implementations are starting to show up.

Now I can’t logically fault Adobe for putting their shoulders behind “Flash”, since it is by far the more mature implementation and by far more widely deployed platform. And they get to control the pace of the specification. Flash is logically a better competitor to Microsoft’s XAML next year.

Kurt makes the case that Adobe’s exit from the SVG space could be a good thing as it opens the door for browser and other plugin developers to step up. While this is true to a degree, I worry that the space is getting tight.

I guess it should be made clear: This is really a battle for the future of web client development. Sorry for the excessive drama. Web applications are taking the next step in terms of user interface and people want to make money off of this. There are many sides to the battle: Microsoft with XAML, Adobe with Flash, Sun with Java, W3C with SVG and the Rich Web Client Activity, there’s even the open source OpenLaszlo (which is based on Flash, if I understand things). My own belief is that there are too many competitors in this space. The web took off because there was one easy-to-implement standard: HTML.

Renesis

Finally, we learn from the EvolGrafiX team that their Renesis plugin has been delayed by months because team members have quit. Furthermore it sounds like if the plugin is ever actually released, it will only support SVG 1.2 Mobile. I don’t know… GoSVG.net has been online for over seven months and aside from a (rather impressive) video we haven’t seen anything from them. Is it vaporware? It sounds like even their presentation at SVG.Open didn’t have an actual demo of their software… I think Renesis Pre-Alpha should be released, just to give the people some faith – it doesn’t need to be a “Flash-Killer” at this point.

Final Words

What I’d really like to see is some upfront show of corporate support on some major sites and here are my suggestions:

1) Google Maps should now start using SVG for Mozilla and Opera in the same way they are using VML for Internet Explorer. Send the path data and let Firefox 1.5 and Opera 8 render it.

2) Flickr should create Image Badges in SVG.

Support for SVG from Google and Yahoo! would be a tremendous vote for SVG’s continued existence on the web – and that would be a nice Christmas present. I’ll put it on my list to Santa…