WPF/E requires a Javascript Master?

You know I haven’t dug just a whole lot into WPF/E.  I did spend about 4 hours yesterday giving a hard and quick look at it though.  What did I get out of it?  Well, how is something that requires and ties into javascript the way it does ever going to compete with Flash?  Not only that, but you have to have the client install something that will render the xaml (it installed something, this is what I assumed it was, for the vector graphics and animation and whatnot).  WPF/E resources on the web are lacking in info from what I’ve found, and the expression series of tools website doesn’t have any good information either.  All the demos and tutorials are too remedial to make an informed decision about the products and technology.  I spent 2 hours on a tutorial on Expression Blend, and at the end of it, my synchronization of databound elements wouldn’t stay in sync like they were supposed to, which was the entire purpose of doing the demo.  I could have done the same thing in VS in about 5 minutes and made it work fine.  The only advantage was that I could slap some nice coloring and layout stuff onto the page with Expression Blend.

BTW, Expression Design is pretty damned slick.  You can create full vector images just like if you were using Photoshop, and export them out to XAML.  I thought that was impressive.  The demo on that was nice too.

So I downloaded about all the demo’s and websites I could find on WPF/E, and every one of them is filled with a TON of javascript.  How is that easier than anything else I’m doing?  Seems like going backwards to me.

I also got the trial of Expression Web and downloaded the starter kit.  I thought there was going to be something cool in there, but turns out, there is nothing (that my untrained eye can find) that has anything to do with WPF!  Its just a plain Asp.Net 2.0 website!

Is WPF/E really a viable solution?  Is it going to get widespread use in the future?  My first impressions after spending about 4 hours with it is no, at least not for enterprise applications.  Its use is primarily for media, vector graphics and animation – period.  All interaction with these elements requires javascript, and what appears to be a lot of it, and that’s a big downer to me.  I admit I know nothing about Flash except that it looks cool and requires a plug-in to run in my browser.  From a user perspective, WPF/E will be the same thing.  However, from a developer prospective, are you going to quit using your Flash model and switch to WPF/E?  Is it really going to be better?  Javascript and untyped form data… oh joy.  Cross platform is a plus though :)

I went through quite a bit of WPF/E stuff yesterday and I have to say, that’s probably as far as I’m going to go with it for quite awhile.  The technology doesn’t fit what I do, because I don’t build Amazon or YouTube or anything of those websites that would benefit and look snazzy with this type of ability that WPF/E provides.

Those of you have do have more than 4 hours of “getting to know you” time with WPF/E, feel free to set me straight on this.

This entry was posted in .Net Development, WPF. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

14 Responses to WPF/E requires a Javascript Master?

  1. chuck says:

    WPF/E = cross platform/cross browser.

    It’s not cross platform. MS is only doing Win and Mac. Won’t run on Linux. MS said 3rd party will make Linux. Maybe so but when? I don’t want to invest the time if Linux support isn’t going to be available at RTM.

  2. box says:

    people… just can’t someone freaking tell me what is the METHOD/TECHNIQ/WAY or whatever you want to call it (coz i can’t seem to google it) for converting or transforming or JAVASCRIPTING the XAML file made with BLEND so that I finally publidh my finished WPF… thank you ! lol

  3. sahilmalik says:

    Ray –

    XBAP = IE only.
    WPF/E = cross platform/cross browser.

    And like we had discussed, my personal view is, (ClickOnce + WPF) > XBAP :-/


  4. aludanyi says:

    I believe WPF/E won’t really compete with Flash, it is a technology for enhancing the presentation layer for web applications (ASP.NET). Flash is mostly used for static web design, and not so often for dynamic web applications (I mean dynamic in a sense of data intensive user interaction). It isn’t a better Flash, it’s market is only in a small part in overlapping with Flash’s market. Anyway if you wish to master Flash you have to be an ActionScript master, so no big deal JavaScript is essential to every presentation layer developer (and AJAX make this even more important), WPF/E is just another area one can use his JavaScript knowledge, without learning ActionScript required for Flash.

  5. Damien Guard says:

    “Well, how is something that requires and ties into javascript the way it does ever going to compete with Flash?”

    Flash uses ActionScript which bears more than a passing resemblence to JavaScript therefore nulling most of this point.


  6. jkimble says:

    One thing I can mention to ya… Check out the Script# (http://projects.nikhilk.net) plugin for VS… A script# project builds JS code from C# and has interface libraries for WPF/E… I’m not saying it’s the answer, but at least at the end of the day you are only dealing with C# and WPF/E…

  7. rlewallen says:

    And I can see that JS isn’t a nightmare for those who love to do it and design those WPF/E targeted applications. I speaking merely from my personal opinion. No doubt designers and scripters are going to love working together to build some very nice WPF/E interactive applications. The underlying question there is can you convert the Flash developers? Can WPF/E take over as the mainstream interactive application type? How do you approach the conversion process of Flash developers to WPF/E developers?

  8. rlewallen says:


    I can see the lightweight model for the first 2, but its certainly not lightweight for the developer. I’ve seen samples of WPF/E that had a total of 200 lines of xaml, yet 2000 lines of javascript. How does this compare to Flash?

    Scenario 3 is certainly where my interests lie. I’m interested to see what you ship out in the next CTP, but aren’t you just moving closer to an XBAP type application at that point? XBAP – install Fx 3.0. WPF/E – install WPF subset. Once you add in the support for .net languages and control based encapsulation, how much does the WPF/E subset differ from that of WPF?

    I’m certainly looking for more resources, so point me in the right direction for answers.

  9. scottgu says:

    WPF/E targets a number of scenarios. I generally bucket these into three categories:

    1) Media
    2) Interactive Content
    3) Rich Internet Applications

    For the first two you actually want a lightweight, JavaScript programming model that is easy to integrate within HTML sites. WPF/E provides this and delivers a really easy way to add video, audio, vector graphics, and animation within HTML and AJAX based sites. For people doing this, writing JavaScript isn’t a nightmare – but rather really useful glue. :-)

    Judging from the discussion above, I think you are primarily looking for scenario #3 – which is more rich internet applications (and primarily for enterprise development). WPF/E will in the near-future add support for a controls based encapsulation model, and allow you to use any .NET language (C#, VB, etc) to program against it. I believe this will give you what you want in terms of having a very flexible developer platform.

    Stay tuned for more details this spring…


  10. rlewallen says:

    I agree Ryan, a unified tool would help out a great deal, but for me, personally, there better be some serious JS code generating going on when I want that vector model to be interactive. Seriously, who wants to sit and code all the stuff with JS? Its a nightmare.

  11. Ryan Stewart says:

    Hey Raymond, I think one thing WPF/E is lacking is a tool that is built specifically for that platform. You can use a combination of Blend and whatever JS editor you want (Visual Studio) but it’s tough to really build an application that way. Hopefully Microsoft is working on a solution that makes it easier to develop WPF/E apps end to end without having to be a JavaScript master.

    Also, managed code, which won’t be in the first release, should help the developer side. And they’re planning on keeping the footprint small, which may be what is taking it longer.

  12. Karthik says:

    That really sucks. I was hoping WPF/E would finally give us the Flash-like interactivity that our business users are craving from their web applications. The fact that it was more Enterprisey by being connected to .NET was one of its main selling points for us. But if its just a rehash with lots of javascript that also requires a browser plugin then we’ll stick to ASP.NET and AJAX.

  13. rlewallen says:

    How will managed code play into WPF/E? That’s going to add weight to what is supposed to be a very lightweight client driven model. From what I understand, that’s going a bit against the grain of WPF/E.

  14. Marc says:

    Rumor is that in coming CTPs support for managed code comes in. That’s when things get really interesting.

Leave a Reply