What's likely to be in the WPF/E 1.0 release slated for first half 2007?
Browsing these forums I've seen a few comments suggesting that the first 1.0 release of WPF/E will be in the first half of 2007. If thats true, can we assume that 1.0 will offer similar features to the February CTP - ie basically limted XAML and Javascript?
I've also seen the odd comment saying that WPF/E is not due until 2008. If thats true (which I hope it isn't otherwise Adobe are going to win the RIA war before its even started), is it likely that that release would contain far more features such as a proper XAML layout and UI widgets and a proper CLR?
I'm just trying to figure out what the Roadmap is for WPF/E as currently the CTPs seem to be at such an embryonic stage that there seems little point in trying to build anything with them. I've seen a couple of WPF/E demos that look promising - but then you notice thet zillion lines of Javascript building dynamic XAML on the fly - and if I'm going to have to use a tonne of javascript then I may as well stick with Ajax right?
[1019 byte] By [
Dudley] at [2008-1-1]
I don't think there are any official date on the release, so it could be any of those or in between.
>and if I'm going to have to use a tonne of javascript then I may as well stick with Ajax right
Ehm... AJAX is for requesting data asynchronous from a browser. WPF/E is for creating awesome UI's in a browser. I can't really see how these two can replace each other. It's more likely these will heavy compliment each other.
Whether you write a tonne of javascript or not is a matter of how object oriented you make your code. You should be able to create a set of standard controls that you can reuse over and over again, thus saving some code.
I know what Ajax is for thanks ;)
The February CTP of WPF/e provides things like the Downloader object which provides the ability to download content asynchronosuly using the XMLHttpRequest object - this is a similar thing to Ajax - however at present the Ajax toolkit from Microsoft has a far richer set of UI controls - so why wouldn't I use those instead to build my UI?
Sure I can roll my own UI controls in WPF/e but given WPF/e's current limitations (like a complete lack of Layout controls) its going to be quite a task to create "Awesome" UIs as you put it.
And yes - I have played with the WPF/e vista demo - very nice. But I would *love* to see how convoluted the javascript source code is to make WPF/e produce that demo. The rest of the WPF/e demos out there right now are pretty unimpressive to say the least.
The point I'm trying to make is that I think a lot of developers are looking for a system that will allow them to build rich UIs without resorting to HTML and javascript. WPF/e in it's current form provides nothing that hasn't been seen or done before.
I was hoping to try and find out what the roadmap is for WPF/e - ie whats planned to be in or out of the first official version. That way at least I can make a decision whether to pursue development with it or leave it for 2 years until it has matured.
I totally agree with you. These guys seem to be hell bent on providing an implementation of the one thing nobody freaking needs. Web Based Animation. IMHO they should have spent all this while working on the C# runtime, some basic controls, incorporation of the frame control, and left animation totally out. Nobody cares right now if their stupid activex control can move things around the screen, there's a billion ways to do that *** and they all work relatively well. The bank for buck factor is, can I remove javascript from my web development story? That's why every serious onlooker is interested. I just don't see the point of releasing something that doesn't seem to have any advantages over HTML + javascript. I've seen sites built using just javascript that can do all the things the WPF/E demos do?! The CTP doesn't even have a standard textbox and button so everything has to be created from scratch! Meanwhile, flex provides all the benefits of Flash and More. I just cant see anyone but complete fanboys adopting this cuz you might as well USE flash.
Why don't I use flash?
- I already have an MSDN subscription and don't really want to buy another toolset to create Flash
- I already know WPF, ASP.Net AJAX, and Javascript, not really interested in learning action script and Flash
- Not sure what the Flash/ASP.Net story looks like, maybe they work great together, not sure
Why do I bother with WPF/E?
- Xml based, so it is very easy to get started. Can build everything in notepad if you want to.
- Familiar toolset. Already have VS, already know javascript, already have ASP.Net servers set up
- Works great with ASP.Net AJAX
- I can view the source of any WPF/E demo and reverse engineer it to learn how things are done
- Missing things like textboxes, but I can use regular textboxes
Am I a MS fanboy? Of course!
Does Flash have more features than WPF/E? Of course!
Don't forget WPF/E has not be "released" yet. We are still in the CTP stage. MS has already stated they will be adding all the things that you're asking for. The point of the CTP is to get a better idea of what people want and how people will use it.
@Jerod Moemeka :
Animations are one of the few things you can't do efficient and smooth in pure HTML, so I can't see what you are so bent up about.
Furthermore, JavaScript isn't as bad as you make it sound. You just have to learn the proper object oriented ways of using it, and you will love it (5 months ago, I thought I would never say this, but I actually like JavaScript after I learned to use it correctly). Furthermore it works cross-platform, and you can create the same API for several controls with a different presentation layer (ex. Flash, WPF/E, ActiveX and HTML controls), without required the developer to use and learn a new API just because you decided to give them the option of a new viewer.
I don't want any predefined controls in there (especially if that makes the download smaller). I create them myself, which gives me the full control on looks, properties, etc. Of course I create these as JS objects so that I easily can reuse or extend them to my likings, or just download and rework other peoples control collections that they have shared with the community. Ex. The current HTML textboxes, checkboxes, dropdowns etc, look, feel and work all in the same way, and I'm pretty much locked in on that design, except I can change font and colors on them. That is a constraint on the HTML spec. WPF/E doesn't have such a constraint by having basic controls that I must build from.
Bryant,
okay I see where youre comming from regarding the CTP. I guess I was upset when I heard they were leaving out C#. But I'm pretty sure Flex uses xml and since WPF/E is an activeX control (same as flash) they would share the same integration issues. In fact flash also has an extensive API for integrating with their control and a swf can have event handlers in javascript (similar to wpfe).
PS - I'm pretty sure design houses and any web development shop already have flash. In fact any animations on the Microsoft website use flash. To me the activity of embracing WPF/E will not be as simple as moving from nothing to flash. Development shops already using flash will have to evaluate the use of WPF/E instead. Designers and developers who already know flash and are fluent with actionscripit will have to return to javascript (not that there's anything wrong with that)
Other Dude,
Please dont reduce this into another ridiculous argument about who's language is better. At no point in my post did I belittle javascript. I have nothing against the language. The point is I WANT to use c# and it was promised for release one of WPF/E. I'm happy you've come to appreciate and enjoy javascript and I'm sure you have reasons for wanting no controls but let me point somethings out and see how you feel about them:
1) To me 'smaller download' and the subsequent arguments are not adequate reasons to exclude standard controls. For one thing The WPF framework should be able to support the same type of styling that WPF supports. Similarly, the compiled binary servered by the activex should be intelligent enough to exclude anything that is not described in the XAML (as the flex alternative does)
2) Javascript, as elegant as you claim it to be when used properly, is not for everyone. As the leader in technology, I expected Microsoft to blow Adobe out of the water with a technology so advanced and forward thinking it would be a no brainer to choose WPF/E over FLEX/FLASH everytime. As It stands the actionscript runtime, which from it's version 9 inception, is a fully featured object oriented language supporting all the flash APIs runs fine for FLEX and has been doing so since the first BETA.
3) My rant was not in response to WPF/E as it stands now, rather it was directed at the news that C# would not be included in the first release (which was previously promised by Mark Harsh)
Dude,
Please dont reduce this into another ridiculous argument about who's language is better. At no point in my post did I belittle javascript. I have nothing against the language. The point is I WANT to use c# and it was promised for release one of WPF/E. I'm happy you've come to appreciate and enjoy javascript and I'm sure you have reasons for wanting no controls but let me point somethings out and see how you feel about them:
1) To me 'smaller download' and the subsequent arguments are not adequate reasons to exclude standard controls. For one thing The WPF framework should be able to support the same type of styling that WPF supports. Similarly, the compiled binary servered by the activex should be intelligent enough to exclude anything that is not described in the XAML (as the flex alternative does)
2) Javascript, as elegant as you claim it to be when used properly, is not for everyone. As the leader in technology, I expected Microsoft to blow Adobe out of the water with a technology so advanced and forward thinking it would be a no brainer to choose WPF/E over FLEX/FLASH everytime. As It stands the actionscript runtime, which from it's version 9 inception, is a fully featured object oriented language supporting all the flash APIs runs fine for FLEX and has been doing so since the first BETA.
3) My rant was not in response to WPF/E as it stands now, rather it was directed at the news that C# would not be included in the first release (which was previously promised by Mark Harsh)
While I agree with the frustration in regards to a current lack of basic controls, personally I believe it's only a matter of time before we see some basic controls. The reason why the "animation" stuff is important is because it really is a fundamental basis for a truly flexible platform. By "animation", I am including all of the shape based elements that are currently available. Mike Harsh has made a post that helps scope WPF/E. I think there are some really great things coming for WPF/E. The post is available here: http://blogs.msdn.com/mharsh/archive/2006/12/06/what-is-wpf-e-really.aspx
I also look forward to the CLR being included, however, there is a lot of possibility and flexibility with JavaScript. In addition, there is going to be intellisense and better debugging functionality within Visual Studio "Orcas" (http://weblogs.asp.net/scottgu/archive/2007/02/08/my-first-look-at-orcas-presentation.aspx). Also, the fact that JSON is going to be a part of Windows Communication Foundation within the Orcas release adds to the possibility with JavaScript because this will assist in making services easily accessible through AJAX.
Personally, I have "developed" with Flash and ActionScript and I would take JavaScript over ActionScript any day. I would much rather be developing with a standardized language such as JavaScript because you know there will be individuals to help you if you run into problems. From my experiences with ActionScript, I would deem it fairly buggy and I have little intention of using it down the road. Besides the scripting aspect, I like prefer the XAML approach over the Flash approach significantly.
In addition to the community aspect, the XML format that XAML provides allows for sharing and collaboration. You mentioned in your post the need to create everything from scratch, actually, I feel that I had no choice but to do everything from scratch in Flash. I've already experienced the learning opportunties that the XAML provides. Once again, this is all based on my personal assumption that it's only a matter of time for some basic controls.
In addition, XAML also adds value by exposing content to search engines. Though there are ways to do this with Flash, I didn't feel that it was native to the format.
Hey guys,
regarding XAML and controls, do me a favor and research Adobe Flex before pointing out to me all the 'cool features' XAML offers that MXML already provides and more. Regarding Javascript, whatever happened to democratizing the web ?
I agree with your points on standardization, once again however, THIS IS NOT A JAVASCRIPT ARGUMENT. I get the feeling i'm being attacked by prefering to us C# over javascript. Again, I understand the benefits of Javascript, appreciate it's impact, flexibility and power, have orcas installed and am impressed with the makings of debugging and intellisence built into the tool, but ultimately PREFER C# running on a micro CLR for WPF/E development to Javascript. And I must say from browsing though tons of blogs since the technologywas announced, I am not alone on this one. The biggest BUZZ I witnessed was around the use of C# with WPF?E accross platform. It's nice that Microsoft is reinventing web animation but they are way behind the curve on this one. Your arguments make no sense cuz you can do everything you describe with the FLEX framework which is the technology WPF/E competes with. Not Flash, but FLEX. So while WPF/E boxes you into javascript development in the first release. Flex provides javascript development AND a full fledges type safe object oriented language if you so desire.
PS - Last post for me, thanks for the good discussion guys :-)
Hey "Dude".
You made it into a discussion about another language, not me. You wanted yet another language to work with WPF/E. All I was saying was that one language is more than enough, and this could just as well be JS as any other language. Don't get me wrong, I am a C# developer by heart and profession, but I'd rather have a full JS language to work with, than a stripped-down micro-clr C# language. The fact is that all browsers today already have a JS compiler built-in. Microsoft is really smart here... making the same for C# on all browsers and platforms is a way bigger task, than just using built-in functionality. Maybe Microsoft "promised" something, but if I'm not wrong, they were just sharing their intensions and ideas, which is something completely different. You say MS is behind the curve... well isn't it more important to get a release with all important features out sooner than never, instead of delaying it or stripping it down just to give us C# support? (and when are the VB.NET folks then starting to complain?).
I don't care about whatever buzz there might be... I care for the best solution, and the best solution is the one with the largest user-base, which again comes down to the biggest cross browser support and small downloads/quick installs. I can see all the benefits of C# code in WPF/E, but these all really come down to only compile-time errors in the end, and perhaps some performance gain.
Bottomline is that I'm sure Microsoft have their reasons for not giving us C# support in WPF/E (just yet?). The tools we need are more or less there, and C# doesn't give us much more.
Hi there,
I have been working with Microsoft technologies since VB6, NT, and SQL Server 6.5. Since then, I learned the folks at Microsoft usually bank on their technological bet. Usually, right? So now I am a happy Microsoft coder and architect, and I believe that Microsoft does intend to wake up, kick Adobe right there, and take back some market share in a market ignored for too long.
So, when my boss told me to go forth and write for the entire company (Transcontinental) a first in the industry Print On Demand web app I was pleased to walk up straight to the bookie and place my bet on WPF/E. And then I fainted. Looking confidently at your VP with the air of an expert you can confide an important project to is a skill I possess. Banking on an unproven technology with serenpedity is not a skill I possess yet unfortunately ;-D
I am sharing with you guys here what a customer like us, a 16000 employees company in the USA, Canada and Mexico, a printer essentially, wants to do with WPF/E (or put another way, what I intend to hustle my boss into agreeing to, with some help.
We want to use WPF/E to make online print ordering interactive (beside being just possible to start with). We want the customers, mostly businesses, but possibly individuals later on, to be able to not only upload a PDF, attach an excel spreadsheet, see a PDF preflight and order the business cards for everyone, for example, but we want more. Variable data color printing will be a first anyway. We want the customers to be able to create content not only from templates or from PDF they upload, but from scratch. And that is the kicker here.
And this is where I want WPF/E to shine. I want, as a customer of Microsoft, to have WPF/E to allow interactive content creation. I want my customers to be able to draw in layers different basic shapes (rectangles, ellipses), text, lines, brushes, with various attributes like gradients, colors, borders, repeating patterns. (That's where I stopped the day dreaming of my boss who just wanted Creative Suite in a browser).
I want WPF/E to allow interactive scenarios like the one I described. This is the future, the web 3.0. Interaction is based on animation so kudos for giving us animations.
But up till now, from the little I know so far, I don't know how to do in WPF/E the very crucial part of our scenario, namely the interactions between the WPF/E app and the customer. So perhaps WPF/E already allows interactions. I don't know. I haven't read enough yet. So now you guys know of one more way your customers will use this technology :-)
Best regards,
Antoine Dubuc
Analyst, Business Marketing Solutions
Transcontinental Direct Montreal
4491 des Grandes-Prairies Blvd.
St. Leonard, Quebec, H1R 1A5
Telephone : (514) 328-7070 x311
Fax : (514) 328-2537
www.transcontinental-printing.com
Transcontinental Printing G.P.
ps: http://orchus.spaces.live.com
