Hi Rob,
Wasn't the original purpose of SVG to provide a single standard at a
time when Macromedia and Microsoft were creating VML and Sun and Adobe
were creating PGML?
That was the idea. Unfortunately, it never really made a breakthrough
amongst developers. We used SVG intensively in our last project, and you
can do very nice things with it. But the lack of 3D and multimedia make
that it's outdated. It would need a strong rework and additions, and
Adobe is not going to do it (so probably noone else will).
MXML seems to be explicitly a server-side technology that uses Adobe's
Flex product to generate a Flash object and therefore requires a Flash
plugin on the client to view. Flex supports SVG at the server, so
Adobe hasn't dropped support for SVG altogether. However, it makes
commercial sense that Adobe don't want to undermine their Flash plugin
with a free SVG plugin that obviates use of their for-cost Flex server
product.
MXML is Adobe's answer to XAML. I am not the best person to judge it,
having only read about it. I think that naming it "server-side
technology" is not accurate, though. It's going to be XML and JavaScript
running in the Flash plug-in, on the client.
XAML also seems to be primarily for use on the server with .NET, and
hence is tied to that technology. I can't see that it is a suitable
for web browsers at all.
Not at all. XAML is actually destined to run on the client (are you
confusing with ASP.NET?). There are two main possibilities:
- XBAP (XAML browser application): The application is served by a web
server to the client. IE receives the XBAP file and due to the MIME
type, starts an embedded host PresentationHost.exe). XBAPs are RIAs
(rich internet applications). Their singularity is that the full .NET
framework is required on the client. Because it uses the full .NET
framework, it allows writing the code-behind in C# (for example, using
..NET to make web service calls, etc...). The front-end is XAML.
Currently, XBAP applications are not able to interact with the web
browser (but that should change in next versions). You cannot really
compare XBAPs with anything existing yet, because it's not embedded in
HTML code (like applets are), but it's also not standalone (it's not
installed, and runs in a sandbox). It's a new concept.
- WPF/E (Windows Presentation Foundation Everywhere): This is a subset
of WPF (no 3D, that's the main difference) which runs in the browser in
a plug-in. If you really want, you can compare it with Flash or Java
applets. The front-end is XAML. The code-behind, in the current CTP
version, is JavaScript only. In the V1, it should also be possible to
use C# against a subset of the .NET framework. WPF/E can interact fully
with the web browser, using JavaScript as a medium. The XAML DOM is made
fully available to JavaScript.
Whichever solution you choose, WPF is clearly running on the client. In
fact, you don't need to install anything on the web server to serve XBAP
or WPF/E applications (for XBAP, you merely need to add 4 MIME types).
You can serve XBAPs or WPF/E components from non-Microsoft web servers too.
SVG can be used for server or client and is not dependent upon any
proprietary technology.
Except that with Adobe not distributing their plug-in anymore, there is
no viable solution to make it work in IE. People who know me on this
forum know that I am a big fan of cross-browser, non proprietary
solutions, but I also work for a firm selling products, and if I tell
them that I cannot support a browser that 98% of our customers use (I am
not making the number up, our marketing does ;-), it's clearly not a
viable technology.
SVG is supported natively by a number of browsers (though not IE or
Safari).
XAML (the WPF/E version) needs a plug-in to run in Firefox, Safari and
soon Firefox on Linux. It runs natively in IE. So it actually runs in
more browsers than SVG does, already.
The XBAP version currently runs in IE only (it was released in November
2006 only, and Microsoft is interested in making it run in other
browsers/OS too, but there are issues. For example, 3D is relying on
hardware acceleration). I heard that Mozilla was interested in making
XAML native in Firefox too, but I don't know if that's only wishful
thinking. Anyway, it's going fast.
Time learning it might be well spent,
Time leaning XML based languages, absolutely, but not SVG IMHO. XAML can
be seen as a further development of SVG, many concepts are similar, but
the abilities go much further. If working with Microsoft's products is
not acceptable for reasons I don't want to discuss, MXML is the best
alternative. SVG made its time, it was great, but now it's time to move on.
as XAML will probably
never make it into the mainstream web browser space (is it supported by
IE even?)
I recommend you take some time and review XAML abilities and support. I
see it as a huge breakthrough. I think you're underestimating the
meaning of XAML for internet applications (web and RIA).
and anyone using MXML and Flex is probably already using
Flash.
I am not sure what you mean. Flash and MXML, though they run in the same
plug-in, are not developed using the same tools.
Greetings,
Laurent
