Mesh on WPF/E

Ok, Mesh got mad at me and posted his own thoughts in response:

Well, I tried to post in the comments on the site, but they didn't seem to take.

Here is what I think is a more accurate and relevant comparison between Flash Player 8.5 and WPF/E.

Programing Support
----
Flash : Heavy (ActionScript 3, MXML / Flex Framework)
WPF/E : Heavy (C# / XAML / .NET)

3D Support
----
Flash : None. Some limited hardware acceleration
WPF/E : None (don't know about hardware acceleration.

Declaritive Programming Support
----
Flash : Yes. MXML
WPF/E : Yes. XAML

Bitmap Effects Support
----
Flash : Yes. Medium - extensive
WPF/E : Assume yes

(Flash has pretty extensive bitmap effects and filters. I am not as familiar with .net on this)

Animation Model
----
Flash : Timeline and programatic. Both authortime, and runtime.
WPF/E : Trigger-based: timelines control the animation, but the timelines are controlled by triggers;

Timelines Required:
----
Flash : No
WPF/E : No

Cross platform Support
----
Flash : Extensive
WPF/E : Committed to Mac and Windows (MS doesn't have good track record with cross platform plugins / support).

Drawing Tools
----
Flash : Heavy
WPF/E : Low to Medium (I put low since the tools are not released, and there is not a market of designers using them yet).

Availability
----
Flash : Summer 2006
WPF/E : First half 2007?

You can find more info on Flash Player 8.5 and Flex at labs:

http://labs.macromedia.com

mike chambers
Here is my response:

I don't exactly agree with your comparison either, its obviously a little biased toward Flash.

1) The Flash runtime doesn't really have MXML support, MXML is something you compile into SWF. I assume XAML support in WPF/E is going to be runtime, not authortime.

2) Programming support in WPF/E is way better than anything in SWF. WPF/E will support ANY .NET language as long as it meets a few requirements. IL is far more powerful and flexible than what the ActionScript bytecode model allows. Additionally, you will be able to use both VS.NET (which is undoubtedly the BEST dev environement there is), Sparkle, or even notepad and a command line compiler to create your stuff.

3) Cross Platform Support: Mac and Windows is enough for a 1.0. There is nothing really preventing MS from providing Linux, Windows Mobile, etc. support down the road, but you can't expect all those in 1.0. If a Linux user really wants to use it, they can install WINE (and most Linux users are advanced enough and have enough time on their hands to do such things if they haven't already). Probably a moot point anyway, since Andrew Stopford points out that "Linux and Solaris support partnered with third party to do." Outside of the desktop, you really are dealing with a different beast and probably need different designs anyway, but Macromedia's support isn't exactly the best thing since sliced bread in that arena.. last time I checked, there still isn't a player for my Windows Mobile 5.0 phone, and its been out for quite some time.

4) Drawing tools: Drawing tools aren't really as important with WPF/E, because it is about creating applications. With Flash it is a huge deal, because Flash is about creating pretty movies... that said, it's not like Sparkle is a piece of crap.

Some things to consider as well:

5) The SWF format is far more closed to 3rd party devs, as it requires getting the specs and building your own SDK or buying one from a 3rd party. Since Macromedia doesn't have SDKs available for SWF generation and takes forever to get the specs out, Macromedia is always two steps ahead of any 3rd party content producers.

6) If you are going to point out the availability of drawing tools and people with experience using them as such an important part of your comparison, then you should be fair and add the availability of Microsoft dev tools and the legions of Microsoft programmers that are out there. As this is about creating applications, not drawing cute little movies, an army of developers is far more significant that the comparatively small number of Flash UI designers. Not only are there legions of MS devs, but there are legions of MS devs that will be using the exact same IDE that they will be able to use to create WPF/E content. The similarity between WPF/E and WPF is hugely important, as it means that developers could provide both a rich web client and a full desktop client while reusing a lot of the same code (or transition from a web to desktop client for that matter).

7) Video support: Both support video, but with WPF/E supposedly supporting WMV across platforms, that could really be great for content providers if MS decides to add DRM capabilities in WPF/E 2.0. MS DRM is proven and trusted by a lot of media companies that would never think about offering their content as FLV. This is not to mention that there are a free tools directly from MS to create WMV content, but things like On2's video codec or Sorenson's H263 codec were not written, owned, or designed by Macromedia, so they can't really guide those technologies and don't have free tools for creating them. Why do we really need a completely different proprietary video format from a different company every other Flash release? If Macromedia is really serious about video, why can't Macromedia bite the bullet and hire some people with brains to write their own video codec instead of licensing everyone elses?

8 Comments

  • ------------------

    > It supports a sub-set of WMV with no DRM (this from the WPF/E) session at Mix last week.

    ------------------



    Yes, at least in version 1.0 But, I would be suprised if we didn't see some form of DRM coming in the 2.0 or 3.0 timeframe.



    ------------------

    > from what I saw at Mix, it is compile time (i.e. the plugin won't dynamically render XAML), although I could have interpreted some stuff incorrectly.

    ------------------



    That would be suprising to me (I guess it is possible due to the size constraints of the tool)). I don't see a big technical reason why they would need to do that--at least as far as the XAML is concerned. You will definately need to compile your CS or VB files to create the IL for the code behind the XAML though. I'll see what I can dig up on this.





    ------------------

    > Well, when targetting the Flash Player, you can use the Eclipse based Flex Builder, Flash Authoring, or even notepad (since we are releasing a free SDK that contains the Flex Framework and command line compilers).

    ------------------



    Yes, this is a very cool new developement. I thought it was great when I heard about it. Still, compiled Flex output is like "Flex-Lite" since you can't use a lot of features once it is generated if you don't have the server behind it. My impression of WPF/E on the other hand is that it isn't designed to be run on top of or coupled with a specific app server, but is a strictly client side technology. Maybe they will figure out a way to tie it to ASP.NET or something, but I don't like the implications of such tight coupling with an app server to take full advantage of the platform.



    ------------------

    > Of course, there is also nothing stopping MS from dropping support from those platforms either (as they recently did with Windows Media Player).

    ------------------



    Nor is there anything stopping Macromedia from dropping support for those platforms in the future. It's all about revenue and whether or not those platforms make sense. If they make sense for Adobe to pursue, then they probably make just as much sense for Microsoft to pursue. With all BillG's talk about handheld devices, I'd be very suprised if we don't see WPF/E runing on them in the 2.0 or 3.0 timeframe.



    ------------------

    > Well, I was just using the comparisons in the original post. However, I don't agree with your statement that design tools are not important (it don't think Microsoft would either). I think design tools are incredibly important to creating applications. This applies especially to the richer application experience Macromedia / Adobe has been pushing for a couple of years, and which MS was heavily pushing at MIX.

    ------------------



    Not saying they aren't important. I'm saying they aren't as important with WPF/E. Although both Flash and WPF/E will be able to target those kinds of rich media apps that Flash is used for, I think the big difference is that WPF/E will attract a lot of more traditional app developers who are 90% business case and 10% experience rather than 90% experience and 10% business case.



    ------------------

    > Flash can do that (arguably better than any technology), but as you also know, the Flash runtime can also be used to run applications. That is what the Flex Framework, Flex Builder are targeted at, application development.

    ------------------



    Ok, I will admit to using hyperbole on this one :).



    ------------------

    > I think part of the problem is confusion over what people mean when they say Flash. It can mean quite a few things.

    ------------------



    Well, this confusion is really Macromedia's fault, because the player is named the same thing as the authoring tool, so when you say Flash in terms of development people generally assume Flash+Flash authoring. Not much they can do about that now unless Adobe rebrands the authoring tool or something (now would be as good a time as ever).

  • #3 is a biggie, its not good enough to ignore linux and co.

  • Hi Jesse,



    " Still, compiled Flex output is like "Flex-Lite" since you can't use a lot of features once it is generated if you don't have the server behind it. My impression of WPF/E on the other hand is that it isn't designed to be run on top of or coupled with a specific app server, but is a strictly client side technology. Maybe they will figure out a way to tie it to ASP.NET or something, but I don't like the implications of such tight coupling with an app server to take full advantage of the platform. "



    This is really misleading Jesse. Output from the Free Flex 2 SDK and/or Flex Builder is completely client-side and 100% server agnostic. There is no tight coupling at all. There are no dependencies on the Flex Data Services at all. There are no features that are "held back" in the client because a server is required. Flex and Flash clients work great with no backend or any backend that can generate XML over HTTP or an XML socket or WebServices or a binary stream whether that backend is written in ASP.NET, C#, JSP, CF, Ruby, or whatever. No server from Adobe is required.



    If you want to do things that require a server, you need a server regardless of whether your client is WPF or Flash or AJAX or JAVA. Flex Data Services provides server side services such as Data Push that are appropriate on a server and optional. If you want data push with a WPF application, you will need some kind of server for that too. BTW, Flex Data Services is also client agnostic--it can serve data not just to a Flash Client, but to a Microsoft Excel client or an AJAX client or ultimately any client (including WPF!) at all that would benefit from its rich data services.



    Regards,

    David

    Adobe







  • > This is really misleading Jesse. Output from the Free Flex 2 SDK and/or Flex Builder is completely client-side and 100% server agnostic. There is no tight coupling at all. There are no dependencies on the Flex Data Services at all. There are no features that are "held back" in the client because a server is required.



    --------------------



    Really, what were you smoking the last time you actually used Flex? Correct me if I'm wrong, but last time I checked, you need to have the server if you want to render some SVG or some MXML at runtime, or take advantage of RemoteObject support to name a few things. Although you could argue that you can create applications that are 100% server agnostic when you precompile them, it definately isn't accurate to say, "There are no features that are 'held back' in the client because a server is required.". I have yet to come across a concise list of what can and can't be done without the services. It would be nice if Macromedia had a concise list available somewhere.

  • Hi Jesse,



    I smoked Flex 2.0 a bit, and you can create great applications that don't depend in any way on a server product from Adobe/Macromedia. You can do web service calls to any server. I must say I'm really impressed by the Flash 8.5 platform. I hope Microsoft comes up with a great contender, but I have to see it first.

  • The real issue surely is how can I as a .net developer be productive with flex David. Do I need to learn a new language to get the most from my platform or can I use a language I already know and use everyda? When I have a stack as rich as WCF to work with in WPF then while xml over http is good I have a lot more power and more ways of approaching a problem in my application. Flex is a great platform of that I have doubt but at the very end of the day I not only need to be productive but also get the management buy-in I need. We are getting away from the real issues at hand.



    Andy

  • Hello Everyone! I like watching BBC Football online.

  • SxYvMe Major thanks for the article post. Much obliged.

Comments have been disabled for this content.