"Considering that ActionScript is really just Javascript with some
rendering APIs, once SVG is ubiquitous (effectively taking care of the
rendering API), will there be much point to Flash?"
http://www.dekorte.com/blog/blog.cgi?do=item&id=3468
(Aside: ActionScript is _worse_ than JavaScript, as it is a kind of
JavaScript+Java-semi-static-typing hybrid. Anyway...)
What Steve's really getting at is SVG vs. Flash. Flash goes well
beyond rendering, into multimedia, interactivity, environment/network
integration, etc. SVG has some support for JavaScript callbacks and
not much interactivity beyond that. SVG currently only (mainly?) runs
in some browsers, with all the pro's and con's. (I think Adobe's SVG
engine used to run stand-alone. Maybe others do as well?)
Flash could be a good foundation for an SVG engine. SVG could be a
good foundation for a Flash-like replacement.
I'd like to see SVG advance into a more fully capable engine for
*interactive* structured graphics, and beyond that a more fully
capable platform for many kinds of applications. SVG could be our best
hope for moving beyond the browser per se.
Those foundations require a simpler language than JavaScript and a
better security model than the browser or even Flash. The
interactivity model should provide a mix of
declarative/constrain/dataflow as well as imperative (i.e. callbacks
and mutable data, e.g. display lists).
14 comments:
Not to disagree, but to clarify:
"ActionScript is _worse_ than JavaScript, as it is a kind of JavaScript+Java-semi-static-typing hybrid."
Ecmascript 4 is adopting the optional static typing and inhertance based classes from Actionscript, so the differences, for better or worse, will soon be moot.
"SVG currently only (mainly?) runs in some browsers"
The Gnome desktop for Linux uses SVG for icons, desktop pictures, themes, and games. Many vector-based drawing (and graphing, diagramming, etc.) programs either use SVG as a native format, or at least provide support for reading and writing it. Cell phones actually tend to have better support for SVG than desktops, to the point of having dedicated hardware acceleration for it, much like OpenGL. And for "some browsers" that would include Opera, all Mozilla-based browsers, and all Webkit-based browsers, and IE with an (old, but capable) plugin.
"I think Adobe's SVG engine used to run stand-alone."
No, I'm pretty sure it was just a browser plugin. Since Adobe acquired Flash they have been less than keen on furthering development of SVG. On the other hand, there are plenty of options for running SVG standalone (if by standalone you mean in an application besides a web browser), both open-source (such as Inkscape) and commercial (such as Illustrator).
For more SVG implementations, see http://www.svgi.org/
"SVG has some support for JavaScript callbacks and
not much interactivity beyond that"
SVG has all the interactivity of HTML and then some. It is scriptable and has a wide variety of event handlers. It supports declarative animation via a subset of SMIL (though this is one area the browser implementations have been lagging). It has (controvertially) support for socket-based communications.
"The interactivity model should provide a mix of
declarative/constrain/dataflow"
There is a declarative model for SVG (using SMIL), although it has its limits. I wrote an article on that for IBM developerWorks a while back, if you're interested. I know for a fact that adding constraints was discussed for SVG 1.2 and had supporters passionately pushing for it, but it failed to make it in the spec. I think the feeling was that SVG had already grown rather large and complex, but that's just my own guess, I have no knowledge of how that decision was made. Dataflow would be interesting, and I could see how it could be layered on top of SVG, but I'd be interested to hear how you would see it fitting in with the SVG spec itself.
I'm sure there are things which Flash is, and will remain, better at than SVG, and vice versa. Still, I have been eager to see SVG succeed for a long time now and I'm very happy to see many implementations of it maturing rapidly. I already have a good toolset for working with many flavours of XML and HTML, SVG adds powerful graphics capabilities (and animation, interactivity, etc.) to that toolbox. I can't help but see that as a good thing.
SVG keeps growing, see for example the SVG link resource
The big advantage of SVG is how it seamlessly cooperates with other open web standards like XML, javascript, HTML, CSS, video, etc. Together they indeed eat away at what we need/use Flash for
(Thanks, Dethe, for the ECMAScript 4 context.)
"Flash could be a good foundation for an SVG engine."
The Macromedia Flash Player was used to render SVG for quite awhile, and I was surprised that the format wasn't popularized further this way. Here's an entrypoint:
http://wahlers.com.br/claus/blog/display-svg-in-97-of-all-web-browsers/
For declarative interfaces, have you looked into Flex? It uses markup, and is rendered by Adobe Flash Player.
jd/adobe
"For declarative interfaces, have you looked into Flex?"
Yes. Flex is nice. I'm actually using the Flex API from AS with very little mxml. The mxml is the declarative part, but that's compile-time, and I need runtime dynamic UIs for my current work.
So I fiddle with the diaplay list, adding and modifying the Flex components previously added.
"The Macromedia Flash Player was used to render SVG for quite awhile..."
Interesting. Thanks.
"Ecmascript 4 is adopting the optional static typing and inhertance based classes from Actionscript, so the differences, for better or worse, will soon be moot."
Yes, sigh.
"The Gnome desktop for Linux uses SVG for icons, desktop pictures, themes, and games. Many vector-based drawing (and graphing, diagramming, etc.) programs either use SVG as a native format, or at least provide support for reading and writing it."
Yes, which are all rendering-oriented and not interactive, I believe.
"there are plenty of options for running SVG standalone (if by standalone you mean in an application besides a web browser), both open-source (such as Inkscape) and commercial (such as Illustrator)."
Again, those are rendering, and I'm talking about needing a foundation for interactive graphics-based applications.
"I'm sure there are things which Flash is, and will remain, better at than SVG, and vice versa. Still, I have been eager to see SVG succeed for a long time now and I'm very happy to see many implementations of it maturing rapidly."
Thanks. Yeah, that's a good thing, but, yeah, not as well-rounded for interactive graphics-based applications generally. Yet.
"The big advantage of SVG is how it seamlessly cooperates with other open web standards like XML, javascript, HTML, CSS, video, etc. Together they indeed eat away at what we need/use Flash for"
Yes, but there's a long way to go for the easing the development of fairly complex interactive graphics applications.
"Yes, but there's a long way to go for the easing the development of fairly complex interactive graphics applications."
Ah, OK. Well SVG can get you part of the way, depending on what your interactive complex graphic needs are. This library actually uses SVG on browsers that support it, and VML in IE:
SVG VML 3D
Although if I really wanted 3D in the browser right now, I'd ask my users to install the FreeWrl X3D plugin.
The Canvas tag appears to perform better than SVG, but you lose declarativeness. Still, you can do some pretty complex graphic stuff (the following examples may only work in the latest cutting edge browsers, which at this time means Opera 9.5, Webkit Nightlies, Firefox 3):
Algorithmic Ink implements Context Free in Javascript.
Processing.js is an implementation of the Processing language in Javascript.
I guess I'm not sure now whether SVG isn't interactive enough (and in what way) or if you just don't want it in the browser. If it is not interactive enough, I would appreciate clarification on what you feel is missing/needed. If it the browser you want to avoid, one way to create a standalone would be to use Fluid (for Webkit) or Prism (for Firefox) to create a standalone app that embeds the browser's rendering engine. Maybe that's cheating (it's still the browser, just a dedicated browser), but then again Flex also embeds Webkit, if I recall correctly.
In any case, I'm not trying to impose SVG or convince you it's right for your project. I just wanted to add my 0.02CAD to some of your descriptions of SVG. It has come a long way in the last couple of years.
"In any case, I'm not trying to impose SVG or convince you it's right for your project. I just wanted to add my 0.02CAD to some of your descriptions of SVG. It has come a long way in the last couple of years."
Yes, thanks. I appreciate the update. I did some programming with SVG with Adobe's plugin several years ago, but have not followed SVG much since then except to try examples in Firefox's implementation.
"I guess I'm not sure now whether SVG isn't interactive enough (and in what way) or if you just don't want it in the browser."
I don't mind having it in the browser, but I generally think the browser's model needs a big overhaul regardless of SVG.
Interactively, SVG just is (or at least was) clunky in terms of updating it's display list. Also at the time as well, text manipulation, other than the rendering, was not there, or at best _super_ clunky.
Well, I have to agree that SVG's rendering could be improved. I don't really understand why the Canvas is so much faster, does the DOM really take so much overhead? Maybe it does.
As for text, there are a couple of things which are coming, but aren't fully baked right now. First, the SVG foreignObject interface is implemented you will be able to embed HTML (and it's text handling) into SVG documents. Also, Webkit and Firefox are both experimenting with how to expose a small subset of SVG's capabilities to HTML directly (rotating text, for example). In Webkit this seems to be taking the path of adding new CSS properties, while Firefox is testing the addition of some SVG attributes to HTML content.
What is good about this is that the developers of Webkit, Firefox, and Opera are all talking with each other, sharing ideas, testing different paths, and submitting their successes to the HTML5 effort. Since the HTML5 already includes specifications for how to mix SVG and HTML in a document, and these browser vendors are implementing it pretty quickly, there is some hope.
So we're not all the way there yet by any means, but in some ways it is the opposite of the browser wars. The vendors are making their experiments in public, marking them as experimental, and sharing results with each other. Of course there is still one browser vendor that makes the occasional inflammatory blog post and then goes dark for six months, but they seem to be the exception rather than the rule.
For several years it felt like someone hit the pause button for the development of HTML and the web. I don't feel that way anymore. Web development is exciting, and even fun, again.
"As for text, there are a couple of things which are coming, but aren't fully baked right now."
Hopefully things will get better. SVG has nice things like "paths" and so editing text that is displayed along a path should "just work" in a system intended to be interactive. Granted this particular feature is not needed in 90+ applications, but for truly detailed interactive graphics is an indicator of the kind of powerful apps that can be built.
"Of course there is still one browser vendor that... goes dark for six months, but they seem to be the exception rather than the rule."
The "exception" unless you count the number of installed seats they have. Then they kind of rule, which then determines how you have to distribute your application. And so a developer of interactive graphics applications *has* to note that that vendor's browser *does* run the latest Flash on 90+ instances they have in the field. And so...
"For several years it felt like someone hit the pause button for the development of HTML and the web. I don't feel that way anymore."
I hope you are right.
Post a Comment