Why WPF is not ready for LOB
Hi,
From what I read the capabilities of WPF, it makes sense to do any new development in WPF instead of Winforms for desktop applications. Still, whole lot of people (MS inclusive) so far suggesting WinForms for LOB... What does the community think?
thanks
All Replies
- The community is divided, just like the experts are. Some things WPF is right for, some things it's not yet right for. The best thing you can do is analyse whether it's right for your specific project. If there was one answer, you'd already have it.
I can be a WPF snob so I'd tell you WPF is ready to goto the moon...
I honestly believe the toolset/framework is there and ready for LOB, but I think Tim is right about doing some tests to see if WPF fits the bill for your app.
The only warning I can give you is with HW performance. I wouldn't expect WPF to run well on ancient computers or Intel/onboard GPUs.
-Jer
I've been involved with a fairly large LOB built with WPF (250 screens).
It's absolutely ready for it. Everything we did not have from the start (like datepickers and so on) are available now through the community and 3rd parties.
I do not see any reason not to use WPF for a LOB, except for indeed the HW. However, if you can control your environment, I would go for it.
- Hi,
Microsoft is well aware of the need for LOB controls for WPF applications, and though I am not allowed to name a date, I can tell you that we will have some very soon. In the mean time, you find 3rd party providers (Infragistics, XCeed) who have LOB WPF controls in their catalog.
WinForms is obsolete, and don't forget that WPF is a technology progressing VERY fast, so information given even a couple of months ago is to be taken with care today. The message is changing. I would definitely recommend at least considering WPF seriously for any new Windows desktop development.
Greetings,
Laurent Gaja,
WPF is as far ahead of Forms as C# is ahead of C. WinForms is a creaky veneer on GDI+. It may be syntactically better that MFC, but it really is just the same old gas.
The WPF architecture has some problems and early adopters can expect to hit a bump or two as they iron out these issues, but here's a basic fact about software development:
When using object oriented coding, the shape of your application evolves from the shape of your base classes. You can think of it like a snowflake. The shape of a snowflake is determined at the sub-microscopic level when the first few atoms start to crystallize.
If you choose Window Forms, then your architecture will be locked into the base libraries that come with Forms. Having gone through this exercise myself, I can tell you that you can't just swap a couple of classes and methods and make your Forms application into a WPF application. To take advantage of the WPF architecture, and there are some fantastic things there, you really need to throw away the Forms application and start over.
The longer you develop with Forms, the more code you will have to throw away.
I'm in total agreement that WPF is PRIME TIME for LOB! WPF is hands down the best platform for LOB with no equivocation.
I have written an article on ASP.NET and WPF for LOB that you can read here: http://karlshifflett.wordpress.com/2007/12/20/reasons-for-choosing-wpf-over-aspnet-for-very-large-project/.
Most of the hesitation I've seen is due to the lack of first rate RAD GUI tools from a LOB perspective. The ability to drag and drop objects and have a tool generate code is not there yet.
But I would strongly argue that this is not a limitation by any stretch of imagination. We are developers. If the tools do not yet have a feature you need, then write one. If you watch my blog, over the next week or two, I'll be doing a demo of a tool I wrote to do exactly this; dragging an object from a list and have it build out the UI for you. Very easy to do. My blog is here: http://karlshifflett.wordpress.com. I'm also in the process of designing a Visual Studio Add-In to assist developers with the data binding code and will post this on my blog and Code Project. Very easy to write these tools.
Expression Blend is a SUPER GUI tool. Very easy to learn and once you cross over the designer - developer line, you will start to feel the love and become productive with this tool. Blend does need some work from an LOB and RAD perspective, especially in the data binding area. But, they are working on it. So the tools will only get better.
In the mean time, use WPF, learn the platform and deliver awesome LOB applications!
Want to learn about WPF and LOB, and then attend our free Code Camp in Charlotte on May 17th where Microsoft MVP and WPF Master Josh Smith and I will be doing an entire day track on WPF and LOB.
Code Camp: http://karlshifflett.wordpress.com/2008/04/06/may2008codecamp/
Josh Smith's blog post on WPF for LOB without RAD: http://joshsmithonwpf.wordpress.com/2008/04/21/why-use-wpf-if-it-is-not-rad-yet/
In all fairness, I don't want to come off like a cheer leader; all, "ra ra ra, sis boom ba."
The WPF platform is a monster. The RAD tools are not there yet. But this platform is by far the best GUI platforms I've ever worked with and fell in love with WPF the moment I first looked at it in April 2007. I loved WPF so much, that I got my company and our customers to adopt this as our platform of choice for a huge product we are delivering.
Each platform has its own unique challenges, WPF is no different. Once you start to learn and write applications, it will become very clear that your decision was a very good one and one you'll be so glad you made.
- Above all, be wary of anyone telling you windows forms is obsolete. It's not.
- Hi Tim,
I very respectfully disagree. Maybe it's not totally obsolete now, because of the big number of WinForms designers out there, but with the same thinking we could say that VB6 is not obsolete. At the last MVP summit, I was in the Client Application Development track, and Microsoft told us plenty about Silverlight, WPF and not a word about WinForms. Just curious, did you attend the summit? If so, did you get any message about WinForms?
There is a future for WinForms developers because of the number of applications that must be maintained. For any new development today, WF should be seriously considered as a replacement, or as an extension, of WInForms development. For people working in big projects, who need to think 2 to 5 years in advance when we choose new technologies, WinForms is not suitable any more.
Looking forward to hear counter arguments in the sake of a stimulating discussion
Laurent - There are a lot of great points raised on this thread. Now my two cents...
Some people still use MFC to create their GUIs. Some people use VB6. In five years from now, some people will still be using MFC or VB6. In ten years from now some people will still be using WinForms. Why? For any number of reasons.
* The company's developers don't want to learn the new platforms
* The company's developers are not willing to work without RAD tools built into VS
* The company does not care about attracting the elusive alpha-geeks into their cubes by putting "<The Hot New Tech>" on a job desc
* The company does not want to rewrite their existing apps to use the new platforms
* The company's CIO is afraid of change and read in CIO Weekly that MFC is what you should use for GUIs
* Etc.
WPF is a great choice for creating LOB apps. With the help of 3rd party controls to fill the gaps, there really isn't too much missing. As time goes on, and Microsoft devotes an increasing amount of resources to WPF improvements, the story will only get better and better. But, does WPF make sense in your corporate culture? Well, that's a different (and much more difficult) question. - Hi Josh,
I couldn't agree more (what a surprise, huh?) except maybe for the part about the alpha geeks. VB6 and WinForms are still in use, will remain in use for years to come, but that doesn't make them non-obsolete (VB6 more so than WinForms, granted
Actually, I was really surprised last year to hear Microsoft tell me that MFC is getting renewed attention in Redmond, and that they even recommend considering it in some cases. Of course it makes sense when you think of it, since MFC has capabilities that WPF will likely not have before a long time.
However, I never got this message for WinForms anymore, which is why I respectfully advise against it. That said, my company still has a lot of WinForms development going on for existing products, and it's fine by me.
As for RAD tool in Studio, why do you need it when you got Blend..... yeah I know That was just in jest.
Have a great day,
Laurent Laurent,
Yes, I was in those sessions. I'm the "Cider" guy that Mark Boulter pointed out. Windows forms is no longer being developed by Microsoft, but that's largely irrelevant. As a platform, it is complete. It's as much of a wrapper around GDI/GDI+ as it can be, enough for an enormous third-party control market. This is the reason most LOB applications are developed using windows forms.
Will WPF catch up and even exceed its popularity? Absolutely! But it's not there yet. There is still probably at least a hundred times as much development happening on windows forms as there is in WPF, and to call it "obsolete" as if it shouldn't be considered is ill-advised.
Asking which is best on a WPF forum was a bad idea in the first place
Tim
- Tim & Laurent,
If I may interject...
I agree with both of you. Tim is dead-on accurate about the fact that right here and now WinForms is certainly alive and kicking. Usage of WF dwarfs that of WPF by orders of magnitude. Laurent is 100% right that for those of us planning new applications that will take years to complete WinForms can be seen as effectively obsolete since by the time the project is over, WF will have already bought white golf pants and moved to Florida (i.e. it will be retired).
I think the important point here is what you are building and how far into the development you are already. For those of us firmly entrenched in WF already, it is certainly not obsolete yet. For those of us looking to the future, it does not make much sense to cling onto WF when WPF is the new rising star.
josh - I had started to write a reply to Tim (sorry that we didn't meet in Seattle, BTW), but Josh says pretty much what I wanted, just that he says it much better.
I should have mentioned that I work in a firm where the typical project lasts 3 years, and in these conditions starting a new project with WinForms doesn't seem like the best idea. That said, as I mentioned already, we still have a number of WinForms devs, and they're not going out of work anytime soon.
Greetings,
Laurent I definately agree here, its not the technology that isn't ready. WPF can bend to your will in impressive ways that most developers couldn't even imagine.
The real problem is touched on by Josh, that most of corporate-ville is perfectly happy with battleship grey, and until support runs out for VB6 int 2015 they'll be plugging away with any old *** that keeps the contracts coming in.
Personally, I dont know any other group within our company (and its the 2nd largest software co) that is plugging for WPF. Out of the 30 or so developers in the cubicles around me, the vast majority are what Josh's <alpha geek> developers would call 'day coders'. As long as their DB queries run ok, and their unix batch scripts get through system testing, they're happy. In fact , and this is perfectly true, many of them still do all their work in a green screen putty session, writing standard C using VI. yes- VI!. They don't have to, and i've demonstrated other ways of working, but no one is interested. There are a couple of .Netters on another floor, but they're still using 1.1 and 2.0 is relatively alien, like most, they've moved up from VB6.
I think that when you're on a list like this, or you subscribe yourself to the latest tech blogs, you end up with a distorted view of what's actually going on in development. (me included, I came from 20+ years of games development, so seeing people perfectly happy editing in VI was a real culture shock.)
You tend to see the ultra-techy-ultra-cool stuff so much that you think its the norm everywhere else, when it isn't.
As a technology WPF is absolutely ready for LOB apps. (I'm doing one for the UK govt so it must be
). I'm by myself because we cant find any other devs that know WPF. and I mean *any* WPF. WPF is a technology that discounts the majority of day-coders that dont like techy stuff or would be frightened off by having to write their own calender control or use an IDE. (heh, they'll faint at the sight of Blend!) The reality is that this accounts for probably 90-95% of 'standard' developers that work on LOB apps.WPF is easily capable of LOB apps - but you're discounting 95+% of the developers that make up the drag and drop brigade.
Jeff attwood has a great article about this very subject, educating 80% of 'normal' developers.
http://www.codinghorror.com/blog/archives/001002.html
I think appliying Jeffs ratios to WPF, thats more like 95% to 5%.. but i'd like to be wrong!, I'd love to think the strong community we have here will help demonstrate that WPF is in fact LOB ready, even though it may take a bit more effort, that it will be worth it in the end
Happy WPF'ing!
Rob
Rob.
- I love it when the MVPs slug it out. Fascinating thread. For my part I don't plan to do any new development in WinForms. Our current WinForms app (shipped earlier this year) is already considered as legacy, and I'm now well on the way to a much slicker, faster, prettier, cleaner (architecturally and visually) and smaller (by lines of code) application in WPF. And I still haven't even started looking into the "black turtle-neck" application yet (you known which one I mean)...
Thank you all for your thoughtful responses.
The main reason I posted this question is because we have a VB6/COM application (8 yrs old) that we are retiring and rebuild in .NET. It is a huge application, so development might take atleast 1 year to complete.
The current IT program leader supporting this app is familiar with VB/COM, good technical guy but never upgraded his skill to .NET. So he is resisting using any .NET feature like WPF, because he doesnt understand/know it.
Being architect for the upgrade, I am pushing to use WPF and his response was he read it is only for eye-candy like application for graphics, etc., so we dont need it. I totally believe that it should be built using WPF for user interface, WCF for service gateway (he agrees with WCF) and WF for application orchestration.
Hence I posted this question to validate what others think about WPF Vs WinForms.
Hi (again) Gaja.
Yes WPF is more than capable of upping the ante where eye candy is concerned, but from an architectural point of view, its a much richer and more extensible platform than than winforms, and that will only improve with age.
The data binding engine allows you to create a data driven UI, and reams of code dissapear because much of the code can be expressed more concisely in Xaml. Something that would have taken large amounts of code in win forms takes next to nothing to code up in xaml. Of course you then have the added value of it being more robust because there's less code to screw up
Secondly (and depending on the size of your codebase) is WPF's ability to maintain a clear separation of concerns, between the applications data, and its representation on screen. Judicious use of Commands, two way data binding, property notification changes and Dependency properties all add value allowing you to maintain a codebase that has a completely separate UI layer which can then be handed off to someone else easily. Something which is almost impossible to achieve in win forms because of the tight coupling between interface and app code.
Are there things missing ? of course - (is anything ever truly 'done'?) but is it useable and can it be used for LOB apps? most here would give you a resounding yes!
Does it suit your circumstances? Being realistic, this is difficult... How many of your developers are able/willing to dive into .net 3+/WPF (and possible WCF/WWF) that's a pretty tall order if even your leader isn't au-fait with .net techs, especially when you only have a year to learn this stuff *and* deliver an app. Net3.5 has even more advantages like LINQ providing huge gains for develpment in terms of robustness and development speed, but that's yet more tech to learn, and it's not the easiest thing to grasp and again, it allows you to program in terms of "what you want" instead of "how i'm going to do it", so there's yet more stuff to learn if needed.
Be careful here, like LINQ , WPF does require a bit of a paradigm shift from traditional forms programming - and if your guys haven't done any OO before, then shifing to OO based .Net code may be another hurdle. Learning on the job and having deadlines don't always make the best bedfellows.
Anyway, let us know what you end up going for!
Take care, & good luck!
Rob .
I think Rob has hit the nail on its head here. If this is a large project with a number of developers, you're simply not going to have a situation where they all know WPF. And you certainly can't incorporate learning WPF into the project because it's huge, and to know it inside out takes a long time and a lot of investment. Finding developers who know windows forms, though? Much easier.
Your development manager is clearly not afraid of getting the most (time-wise) out of technologies if you're only just moving away from VB6. That's the great thing about Microsoft, they'll support you for a long time with your choice of technology. The amount of support in terms of developer knowledge, third-party controls, code snippets, and resources in terms of example code for doing pretty much anything in windows forms, is enormous. There's only been a non-beta way of toying with WPF for around six months.
Don't get me wrong; I know how exciting WPF is and personally I'd write most types of new application in WPF. But business isn't about excitement, it's about making money and minimising risk. If you manage to involve excitement as well, you've won
- Hi
I think it's not being adopted because.
1. It's hard to learn xaml.
2. It's hard to learn xaml.
3. Did I mention that developers don't have time to learn xaml! Some of us just need to produce code so that we don't get fired. Our bosses want results. And if you work for a large corporation all they really want is the software to work. They could really care less about whether or not it's pretty.
4. The xaml needs to be invisible just like the forms in years past. The only reason you can see them now is Microsoft said we don't have time to put everything in here that we need to on the front end so let's make these guys think it's cool to edit the xaml code directly. Yea, that's the ticket.
Although some of it is drag and drop it's a far cry from being usable without editing.
5. Don't have a budget for a visual designer and couldn't convince the company to hire one. I tried.
6. Developers make sucky UI's.
7. It's disconnected. You really need Visual Studio and Expression blend. That will always be a problem. Until the two are married I will hate this.
8. It' is most definitely not a RAD environment.
9. Some people don't care about pretty. They just want functional.
10. For desktop applications it sucks. And Microsoft has forgotten the desktop developer. They are only interested in pleasing the web page developers.
11. No grid. The free ones suck. Who.... I mean who would release a compiler without a grid. Give me a break.
Really I could go on and on, but right now WPF sucks. It really does and I wish that all you WPF cheerleaders would put down your pom pons. Wake up from happy land and join the real world. It takes a lot of money to switch to WPF from and company point of view. And the developer has to answer the question. "And why do we need this"? Other than it being pretty and the fact that Microsoft will probably kill everything else it most honest answer I could give. I can only hope that Microsoft pulls their head out of their extremely large a** and really gives us something to work with that doesn't require hiring a visual designer. Give me a break.
Rob I have to weigh in my 0.2 cents here ;-)
1 - 3: Xaml is just a declarative way to access the API. It was created to simplify working with the API and I (and the rest of my team) feel it succeeds very well. I do have some problems with Xaml, mainly the verbosity. However, to say it's hard to learn: I really do not see it. You are just setting properties and creating objects. Once you have the mindswitch, it's very easy to read and write... imho.
4: Although Blend is a great product, I never use it. I always edit my xaml directly. With intellisence now working, that has indeed become much easier. Maybe I'm just one of those guys that took the time to read a book or two and get with it. I am betting I'm faster at creating a non-trivial UI that most with winforms. I can still remember the day that one wrong move in the designer would fux0r up the generated code in such a way it became impossible to work with. Yeah, that was the ticked.
Your points mostly seem to rely on eachother, so I'll just skip points 5 -10: I'm very sorry you work for a company that could not hire a visual designer. I do.
11. The listview with View.Grid is completely capable. I've heard more people get worked up about this, but really, I do not see it. It has headers, grouping, filtering.. We had no trouble configuring the grid to behave exactly like we did. Maybe WPF is just so powerful that no 3rd party controls are necessary.
Let's not turn this into a troll post, please? I felt the conversation was really helpful until now.
I think r0741m summed up every WPF myth out there pretty nicely.
1.) XAML is easy! It was actually the first WPF piece I was able to pick up. It's just a serialization of CLR objects.
2.) XAML is easy! Knowing HTML + DOM, it is pretty much the same concept
3.) Boy I'd hate to work where you do. Just produce code so you don't get fired. WPF is NOT about making things pretty, its about making UI development FAST and reusable.
4.) XAML needs to be invisible like HTML needs to be invisible. Would you prefer a massive amount of generated code like in WF?
5.) Why do you NEED a visual designer? WPF is quite capable w/o one and is not a requirement.
6.) Yes they do. And they suck even more in WF.
7.) Blend and VS work very nicely together. But if you aren't concerned about pretty UI, whats the beef?
8.) It surely is a RAD enviroment. I'm sure you can drag and drop a few components faster in WPF, but I can have a working and functional UI done first.
9.) Why does it have to be pretty again?
10.) I think you are completely disconnected from microsofts intentions with the desktop. You'd think they care deeply about a desktop that is at least 1/3rd of their business.
11.) Yes no grid, but ListView is more than enough for most peoples needs.
It seems most critics of WPF are the ones who don't understand it. There most certainly is a learning curve and for sure it takes time/money to migrate over to any technology, but maybe (just maybe) you should be educated on it before you decided its "bad".
-Jer
WOW, the post is getting interesting every day...
BTW, I forgot to mention we have only one developer that works in our team. He is almost revolting for WPF, he doesnt want WinForms. He is reading books and going on 3.5 training. To supplement other development resources we are hiring a staff augumentation company to bring developers, so we do have a choice of bringing people having familiar(?) WPF or WindowsForms skills.
1. It's hard to learn xaml.
2. It's hard to learn xaml.
3. Did I mention that developers don't have time to learn xaml!
Learning XAML is extremely easy assuming you are already familiar with XML. XAML is probably the simplest part of WPF. People confuse XAML with the WPF API, which is why XAML might seem to be so large and formidable. If Microsoft chose CSV as the de facto WPF serialization format, instead of XAML, people would complain that CSV is too hard to learn.Jer
Boy you attack like I slapped your Mom. Do you sit naked with a xaml book and a ***? Wow.
The original post was about why it wasn't being adopted. I offered my opinion. But I must respond.
These comments I made where not myths. They are real. They are my own experience and frustration from learning yet another language of which I lost count around 10. My point is languages come and go, but instead of getting more RAD they are getting less RAD. There is no one in there right mind that would say that your could create a program in WPF faster than a Winform. That would a as ludacris as someone saying that you C++ is faster RAD than say VB6 was and if you said that you wouldn't be in touch with reality.
1, and 2. You are right xaml isn't hard. What I should have said was it was un-neccesary.
3. I don't know where you work, but most places hate to waste money. And if you've spent the last 12 years developing code in VB6 like I have, only to have to convert most of it to Winforms and C#. I think you would probably be a little upset at yet another best thing that's supposed to be better than the last greatest best thing. Try selling that again. That's why a lot of companies are farming out development to India instead of the U.S. There ready for this to be someone's problem and not theirs.
4. I really don't care about the hidden code if it works well. It's code I didn't have to write! And besides Xaml is no speed demon.
5. If I didn't wan't it to look pretty than what is the point of using WPF. Only I'm not a Designer so mine is going to look like banta fudu.
7. I don't want to use two programs to write software. And if you think that Cider is working well than you clearly haven't used it much. The interface sucks.
8. RAD environment?????? Are you kidding? Is that crack pipe good...? You’re funny. You should tell jokes for a living.
10. I'm disconnected? I used this stuff everyday, unlike most of the WPF cheerleaders who make a living selling books about new things and people like you that won't say anything negative about Microsoft even when it sucks.
11. Listview is more than enough for most applications! Are you kidding! Your one of those people who answer the phone with a technical problem and they say, "why would you want to do that". How could you possibly know that Listview could meets the needs of most people! Just because YOU DON'T understand or can't see it doesn't mean that everyone else is stupid.
RobYou know I shouldn't have said that xaml was hard. I should have said it was completely un-neccesary. It complete goes against a wysiwig environment.
Rob
- Rob,
Your insults apart, you make a few good points. Some people will never understand the beauty of WPF. Some of them are managers, and will not use it until it becomes mainstream (that will happen, but it's not now). Some are developers, and these are welcomed to make a carreer with other technologies. Thankfully, there are many of them where WPF will never be needed: Server-side programming, for example, maintaining WinForms based apps, or even MFC apps. There is no shame in not being able to learn a new language, everyone has his limits, and it doesn't mean that you're any less of a programmer. I suggest that you relax, take a deep breathe, and start questioning why you give so much attention to WPF when it's so clearly not for you.
Happy coding,
Laurent - I suggest that you relax, take a deep breathe, and start questioning why you give so much attention to WPF when it's so clearly not for you.
I get the feeling Rob Martin's interest in this thread is more ego-based than WPF-based. Seriously Rob, if you don't like WPF then don't worry about it. WinForms isn't going anywhere, so why make such a big stink over nothing? Plus, insulting people on an MSDN forum is inappropriate. It really degrades the quality of the thread for everyone else who is just looking for a mature conversation about a topic that is of interest to them. Laurent
I must admit I've got a little irritated about WPF. But because you’re obviously think WPF is great I'll tell you why I care.
The reason I care is because people like you follow Microsoft like lemmings. You would happily walk over the cliff and kill yourself on the rocks below never questioning whether it was best decision and because of that WPF will be adopted and since I've made my living writing software since the early eighties, I've seen languages come and go, but are we any better off? I really hate adopting something that is pointless, but if everyone else does that leave's me alone with no support, no help, no cards, no interfaces, no drivers. Etc. At some point you have to go on, even if it isn't really a step forward.
The original poster asked about why WPF is not ready for LOB. I was offering my opinion and your condesending remarks where un-neccessary.
Rob
Josh
Come on. If you had to re-write 3 very large programs. Would you re-write them in Winforms? It wouldn't be the smartest thing to do. I may be forced into using WPF but I don't have to like it. And I didn't start the insulting. I just reponded to an one. And I thought we were. The original poster asked for an opion, I gave mine. Just because you didn't like it does not make it wrong!
- Hi,
Just for the records, I come from the Java world, so definitely not a lemming just a pragmatic adopting promising technology when I see it.
It comes a time in a programmer's life where they become tired of learning. I notice that often in my firm too (BTW we're the biggest .NET programmer shop in the world, so big corporations do in fact adopt WPF). Usually when that happens, they feel unhappy, frustrated and tired. This is a good time for them to think of going do some management work, some of them go to system test, there is always a good job for these guys.
Maybe it's time, Rob.
Greetings,
Laurent r0741m wrote: Josh
Come on. If you had to re-write 3 very large programs. Would you re-write them in Winforms? It wouldn't be the smartest thing to do. I may be forced into using WPF but I don't have to like it. And I didn't start the insulting. I just reponded to an one. And I thought we were. The original poster asked for an opion, I gave mine. Just because you didn't like it does not make it wrong!
I never said you were wrong. Opinions, by definition, are neither correct or incorrect. I don't mind having some contrasting views expressed. That's what it's all about! I'm just asking that we all follow the rules and keep it "above the waist."Laurent
I don't know how old you are but really, stow your comment away for a few years. Say, 10 or so. Come back to it and re-read it. I think you might have a completely different view. Once your software has been trashed a few times.
Obviously I've touched a nerve and the MVPS of this thread really only wanted opinions to the original poster that where positive about WPF. God forbid anyone give an honest opinion. Forgive me for messing up your happy thread. You guys continue blowing smoke. Forget I was ever here.....
Rob
Rob,
I don't think people are blowing smoke. Basically in regards to capabilities of the framework, it would be naive to suggest that Winforms is more powerful than WPF. I understand where you are coming from, I think we all do in here. Right now WPF is still very much in the early adopter phase. It's sometimes difficult for people who have been buried deep in the framework for the past 2+ years to realize that many development shops don't even begin to look at a new technology until it is released. For us, it's almost like having cold water thrown on us when we give a speech at the local .NET user group and see three or four hands raise up when we ask, who is familiar with WPF?
We have used the platform and tackled the learning curve head on and are at the point where we definitely see the raw power that WPF brings to the desktop. This definitely excites us to the point where we cannot comprehend a scenario where WPF is not THE FIRST choice.
Unfortunately, a few veiled jabs have been thrown back and forth, but trust me when I say that we are not trying to look down at you. Believe me, I understand, sometimes you're doing as much as you can to stay afloat and management doesn't see the benefit in allowing you to research and expand your skills. In the long run both you as a knowledge worker and the company suffer because of their lack in foresight.
Yes learning WPF is a daunting task. But it is also rewarding. Taking the challenge on strengthens not only your skills with WPF, but it also makes you look at other frameworks with a different mindset. I don't think there's anyone here who doesn't understand that WPF is not the choice for everyone right now. However, given the opportunity, taking the winforms track over WPF would definitely be a career-limiting decision.
Hey, I'm an MVP and my replies are certainly not in the WPF fanboy section. Quite the contrary. I make a living writing user interface control software for both windows forms and wpf, and I'm in a very good position to assess the market for both. I'd still prefer to write a new application in winforms for some areas because WPF needs to become faster (or hardward to catch up) and I'd prefer to write in WPF for other areas.
I do agree that if you're coming from a winforms world, XAML should be unnecessary. We've come from a world when we dragged and dropped to create interfaces and never had to touch any of the serialized code that resulted, to a world where suddenly we're expected to care about this code, and care bigtime. At first glance, that appears to be a step backwards - and it is, in many ways. The fact that XAML is pretty powerful mitigates it somewhat, but not entirely. Not until we can configure all the databinding goodness of WPF in the visual designer anyway.
There certainly are plenty of cheerleaders around here but that doesn't make them wrong. These threads are great because we all have different points to make and they're all correct.
I am Don, I run what was the first WPF/Silverlight User group in the country here in Michigan, called Michigan Interactive Designers.. We are now in our second year here and the response to our group has been fantastic. We are a group of folks who supports Expression Studio, WPF, and Silverlight. Unlike most .Net Groups, including our local developer one.
We have plenty of designers and companies around us who know WPF and are doing WPF.. Including interfaces in WPF for LOB applications. Most of our folks know how to test and code for graphical performance on these applications so the GPU/CPU requirements are minimized.
Something I don't really understand about the developer community is their lack of wanting to use WinForms Integration on WPF or for putting WPF inside winforms which you can do as long as you watch the Z-Ordering and know the limits. The now cancelled Acropolis CTP really made enterprise applications possible that mixed both WPF and Winforms and WPF. Why it was cancelled I never got the full story, but it's worth looking at, as proof that it's really possible to do this effectively. Sure there are some other issues with it, but as proof it's quite up there. There was also a financial applications in WPF contest that won quite a few accolades.
My view on this whole thing is the Visual Studio Developer community (and I hear this a lot) is still spooked with WPF, because of the sophistication of XAML and the fact that Microsoft left some very ubiquitous controls out of there, so UI building required a bit of knowlege about graphics (though graphics designers probably would not consider it a lot) instead of dragging a control and just setting properties. I hear a lot of developers say "well I don't know about this user experience thing" and I want to code and not be a graphics designer. If I had all the winforms controls it would be great, they have default styling and I can do UI stuff as a no brainer..
That's all well and good, but when your application starts competing with applications from other platforms, the Windows one sort of looks so 10 years ago and people cringe when they have to use a Winforms application because it's not asthetically pleasing. Developers are also resistant still and don't understand the work flow of letting a designer help them. They worry about version control, and a whole bunch of other things which are more paranoia than fact.
WPF and Silverlight take us new places and it will take a while. Someone saying it's not ready isn't really saying the technology isn't really ready (it is, and SP1 of WPF will even shine brighter), however you need to talk to a designer. Not everything in WPF has to be animated or do a special effect that doesn't run well on old hardware..
If you need WPF people please check out http://MichiganInteractiveDesigners.org we have and know of plenty of proficient people all around the country ready to work with you. This is not the time to stay in "the box" with your thinking and look outwardly. You won't find these people at .NET coding groups or from your usual contract house/recruiter. There's a reason for that, most designers won't touch these people because of their pay practices, and beyond things like event handlers most UI folks don't code anything but UI.. So you have to figure out where these folks are if you want to hire them, we know and can help you..
Most of the comments by folks here don't represent the actual situation in the market, but people needing other folks that are around and available and they are seriously in DEMAND..
As for WPF missing things, have you checked out the free XCDEED datagrid? There are a lot of third party add-ons now to fill in the gaps while we wait for SP1 of WPF. All in all people don't want to have to learn new they don't like change too especially programmers.
- Hi Don,
Acropolis was cancelled as a product, but not as a concept. Most of it is flowing into WPF and Silverlight and next releases of these 2 technologies will make LOB for WPF easier than it is now. It is still pretty confidential at this time, but Microsoft works fast on improving the technologies, and on adding Acropolis flavour to them.
HTH,
Laurent Mike
Thank you for your comments. It's refreshing to hear someone that understands the problems of taking older applications into a new platform. It really isn't all hearts and flowers, and if we as developers don't let others understand the problems they will face the platform will not get better.
My tone has been yes, been negative. But sometimes seem to be the only way to bring out the things needing to be discussed.
Thanks again for your comments.
Rob Martin
Tim
Thanks for your response. Thanks for being objective.
Rob
Eitherway, we are planning to buy Infragistics Netadvantage controls for Winforms or WPF, depending on where we endup. This should clearup the DataGrid issues in WPF.
I am going to keep this post open till we make a decision and post it here, so all the contributors know where we ended and why we ended there.
A major market for Windows Client applications in my place is the small business/shops sector where Foxpro apps ruled once. Later it was VB6 and now slowly getting into WinForms. And WindowsXP is replacing Windows95/98/2000 platforms. It will surely take another 10 or more years for this sector to adopt Vista/WPF as for them it offers nothing more than sexy looks.
I agree. It's not faster. It's not easier to use. It just look nice.
Cool Wayfarer wrote: It will surely take another 10 or more years for this sector to adopt Vista/WPF as for them it offers nothing more than sexy looks.
I am not sure, what you mean by Vista/WPF. You can build WPF apps on XP, and get the functional benefits. I can run almost all the samples that I downloaded on XP and Vista without much difference.
Certainly, I am not looking to use WPF for eye-candy/sexy looks. I am recommending the use due to the richness in databinding, separating the designer from developer, etc., From my standpoint WPF is more than just looks. You have to invest time in understanding the difference.
- Okay, we finally had some MS people break the stalemate about WPF Vs WinForms within our company. The MS person we discussed said WPF is not ready for mainstream, basically "not stable" to build our LOB application on it. So our journey will continue on Windows Forms for forseeable future.
Wow
Have been discussing the very same thing with MS people but obviously haven't got to the answer that you have just yet. Still struggling. Can you elaborate on any specifics, especially on the "not stable" part.
Thank for getting back to us.
Rob
Hi Rob,
The MS person said, it is not ready for the primetime because of the maturity, toolset gap and not stable. Unfortunately I did not attend that meeting, I had another conflict. The people attended the meeting were for WinForms, so they did not probe more on the specifics (I guess).
Thanks,
Gaja
Gaja
If you hear anymore about the specifics I would like to know before I hit the same problem. It really could help make alot of our minds up about things.
Thanks
Rob
I would meet some of the MS guys on Friday 23rd. Will post the details as soon as I get em.
- This is the exact reply from MS people...
"The plan is not to leverage WPF at this point but to get the client moved to .Net as a top priority. A bit further down the road, customer would look at WPF more aggressively."
I assume this is because, our Program Leader that went to the meeting would have said, our project plan is to move our application from VB/COM to .NET as fast as possible, so adding WPF stack would unnecessary delay. Needles to say, our Program Leader dont want to use WPF, based on his one day reading on .NET and WPF he *learnt* WPF is for eye candy type application, which is not we are shooting for. So he basically got the answer he wanted...
Pl mark if answer solves your problem | Visit http://gajakannan.com/netarch.aspx for .net ref Arch - GajaKannan said:
This is the exact reply from MS people...
"The plan is not to leverage WPF at this point but to get the client moved to .Net as a top priority. A bit further down the road, customer would look at WPF more aggressively."
I assume this is because, our Program Leader that went to the meeting would have said, our project plan is to move our application from VB/COM to .NET as fast as possible, so adding WPF stack would unnecessary delay. Needles to say, our Program Leader dont want to use WPF, based on his one day reading on .NET and WPF he *learnt* WPF is for eye candy type application, which is not we are shooting for. So he basically got the answer he wanted...
Pl mark if answer solves your problem | Visit http://gajakannan.com/netarch.aspx for .net ref Arch
I suppose this makes sense, in that you don't want to bite off more than you can chew (ie. if you have two separate, big developments/learning curves on the table, you should tackle them one-at-a-time). If it were my project, however, I'd certainly still keep one eye on the WPF/UI landscape. The databinding model and the UI development paradigm is radically different in WPF -- if you assume that everything's going to be done the old VB/WinForms/ADO way you may paint yourself into a corner.
For me WPF is a no-brainer -- I can get more done with a smaller, smarter team and end up with something that differentiates me from my competition and can be revamped or branded quickly and without breaking the development budget.- Edited bywbradney Monday, June 02, 2008 6:33 PMtypo
- I agree with you wbradney. I would have still used WPF, because getting to WindowsForms/ADO is like using Framework 2.x not 3.x. Obviously there is no reuse from WinForms to WPF. Using the databinding model in WPF I could get things done faster than using WinForms/ADO.
But the project was run by a person that has not kept upto date with .NET but has most opinion about what to use in .NET (Basically he wanted to use only the things he knows and understands)
Time will answer if that was the right choice made by the program leader.
Pl mark if answer solves your problem | Visit http://gajakannan.com/netarch.aspx for .net ref Arch - Actually the interop story between WinForms and WPF is a pretty good one -- you can host WPF in a WinForms app or vice versa without too much trouble, and this would certainly get you some added incremental value in the short-medium term without too much development effort. Beyond a certain point, however, in my experience such an app starts to feel like it's lashed together with duct tape.
For me, if you're starting from scratch or are moving from VB6, you might as well leap-frog WinForms and ADO-style databinding on the client and seriously start looking into POCOs, Linq and WPF. Your R&D time will be in the budget already, so there's no point learning yesterday's technology.
That's my 2 cents. - WPF, in my opinion, is definitely ready for LOB apps. The reason being that the framework is very rich in how it is structured. If you take the time to learn XAML, you will quickly learn the vast potential it has when it comes to building a UI. Yes, the learning curve is steep, but the potential is unlimited.
In the beginning I too was disappointed because I was so used to developing graphically using drag and drop facilities. When Microsoft sent me the early beta versions of the .NET framework and Visual Studio, I too was a little worried, I quickly concluded that Microsoft was going in the wrong direction. All of the applications I've developed are LOBs, so I suddenly found myself asking if I had to learn to become a graphic designer in order to respond to my clients' needs. Wasn't it enough that I had to learn C#, WCF, LINQ? Most of the books about WPF at the time were about how to draw snazzy buttons that spin. Add to that the fact that Visual Studio lacked the necessary controls to build LOB apps I was doubly disappointed. I realized that building a LOB app would take longer. So I went back to VB and WinForms.
But we need to realize that WPF is still in its infancy. Microsoft is making sure that the framework is ironed out before it adds the bells and whistles in Visual Studio. The first WPF book I purchased didn't even talk about databinding in WPF, features like the ResourceDictionary weren't even around then. Recently I looked at Visual Studio.NET SP1 and I saw that it has more of the features I need.
It's only a matter of time that the WPF tools will be everything we ever wanted it to be. The IDE's will make WPF development so much easier and we will eventually be dragging and dropping LOB controls again. For those of you who don't like XAML, you have nothing to worry about. The future IDE's will generate it for you, Visual Studio does it for you right now. Most of us are upset now because we have to resort to 3rd-party tools to get the controls we need. As a LOB developer I know that this could be a problem because not all clients use the same third-party tools, so we're stuck having to learn a lot of 3rd-party tools.
From what I see, this debate is simply the usual debate we all go through when a new technology comes along. Now that I have a few WPF projects under my belt, I can confidently say that it is ready for LOB. And I'm slowly starting to see the value in WPF because I'm already imagining myself not wanting to back to VB or WinForms. Yes, I did run into some specific problems with WPF and some were solved with work-arounds, but I remember years ago I had to do work-arounds in VB6 as well.
- I hope your right. I've been struggling with it since January and right now it takes duct tape, and bailing wire. And oh, pay no attention to that scratch. It will buff right out.
- Hi Guys,
My name is Gary and I have been coding in Windows since Windows 1.0 (that's not a typo) so I am certainly not a Microsoft basher. I made most of my living writing code using Microsoft technologies starting in C/Win16 &32, then C++/MFC and now using C#. I am now retired and living in Medellin, Colombia. I dabble in coding so I am working on an application of my choosing and have been trying to come to grips with the user interface programming issue for myself.
I think that the question may have been asked backwards. Not "Why WPF is not ready for LOB" but "Why LOB is not ready for WPF". By this I mean that I would assume that after this 2nd or third release of WPF it is most likely to be "up to the job". But what about the developers? They are given little thought when decisions are made to change platforms. I know some of you will say that Microsoft agonizes about threatening their developer base (and I believe they do) but then they continue on creating things that may or may not be beneficial to the development community. Some are winners, some are not.
Developers spend a good amount of time honing their skills on a particular platform. That is how they get things done. However, the pace of change has become such that they feel threatened whenever Microsoft introduces a new platform or technology. I have known many developers who got left behind over the years because they either did not want to learn, did not have the time, or were comfortable in their skills to get the job done the way they always had. Some of them would ask me where I learned the newer technologies and I would reply, "I just bought a book and read it", as well as trying to code samples from Microsoft. I offered to teach them what I had learned, but they never seemed to get around to it.
I was one of those people who wanted to learn the latest and greatest tech to get my job done easily and more quickly. I went to Quick C for Windows as soon as it came out, then Visual Studio (its successor) when it was in beta. Gone were the dialog resources to develop the user interface. Visual Basic brought the new drag & drop paradigm but I didn't like the language so I stayed with C losing productivity compared to VB programmers for years until .NET came along. MFC seemed like a pretty good productivity booster when it came out, so I switched to that. My last great shift was to .NET when it was in beta. I just loved the idea of writing web apps in code not HTML. I then completely switched to C# OOP using WF and never looked back.
Now the twist of WPF (not really a paradigm shift) is a significant learning curve. My problem with it is that it does NOT offer all the same capabilities as WF and in the same way. Developers like to get incremental improvements in coding platforms without losing any of the skills they have already learned. If Microsoft had finished the development of WPF before foisting it off as the latest and greatest thing, I think it would have gotten a warmer welcome. To ignore the dual Visual Studio/Expression Blend development environment and the loss of drag and drop versus XAML typing is to completely drop a productivity loss into the development process. Neither management nor developers will accept this.
Let me give an example where Microsoft could give everyone in the LOB development process a boost. Standardize the look and feel of user and business apps the way Apple has. Have a standard Windows look with the new ribbon bars, graphics elements to choose from, and the look of office apps where you could leverage all that and start an application very quickly. Don't hold off releasing these things until Office X has wrung out all the value. No company wants to go off and buy third party UI elements to get started and then have to switch back to Microsoft later. Right now in WPF there are too many examples of this to list here. Back in the primitive MFC days you could generate an app very easily using VS and be coding real functionality in a day. You could also throw it away and start over from scratch without causing a management crisis.
Another place to increase productivity is in the area of Visual Studio installer applications. Bring all the different ways of packaging an application together in VS and provide a framework for developing these with mostly boiler plate or generated code. Maybe dump the database style of .MSI installer and provide something more generalized.
Anyway enough of an old man's rambling. Good luck and remember we need to get some value out of learning a new technology before moving on to the next one. We only just learned .NET and WF seven or so years ago.
Gary Hoffer - I must admit this is an interesting thread (took me a while to read it). Anyhow, I'm a professional software developer, been doing it since before Windows, using .NET since v1.0 beta yada yada yada.
WPF is definately something that grows on you and takes a fair amount of time to get to grips with it (compared to WF). One thing that really didn't help was the piece meal way Microsoft released it (WF arrived pretty much complete). I think the real issues are simple:
1. Do you have the need and motivation to move to WPF (if WF is good enough and you know it well, why change).
2. Do the new WPF features offer a compelling advantage? Data binding, skinning, new event model and transforms are quite a big deal to me.
Some disadvantages:
1. The tooling is still weak.
2. Takes a while to learn (mentioned before).
3. The default theme is ugly on XP (the Silverlight one is very nice). I know you can get other themes, but still....
4. .NET 3.0+ doesn't run on W2K (a big deal for me).
Another important thing is that LOB applications are increasingly becoming browser based and ASP.NET MVC/Silverlight is a compelling combination, and since Silverlight 2.0 is pretty much a scaled down version of WPF (and getting closer with 3.0) learning WPF and/or Silverlight 2.0 isn't such a bad thing (2 birds, one stone...).
My reason for preferring WPF in spite of its shortcomings is simply that it offers a more complete solution for regular LOB applications, browser based applications (Silverlight, not XBAP) and more graphically intense applications (with the advantage of allowing really flashy LOB applications).
One other aside - end users actually do like good looking software (as long as it's usable). - I started reading this thread in May, when I first started learning WPF. I've also only been using .NET 3.5 since April. Previously, my GUI development experiences included various Borland GUI toolkits, QT3 and QT4, LTK (LISP toolkit), GTK+, Swing and SWT, as well as Win32. So far, I've spent a lot of energy learning the strengths and weaknesses of the platform:
- C# vs. VB vs. F#
- WPF vs. WinForms vs. ASP.NET Classic vs. ASP.NET MVC
- Becoming deeply acquainted with Microsoft Research
- Learning the under-publicized features and shortcomings of .NET 3.5
At a high-level, Microsoft product managers and community members have combined to do a great job informing the public about the differences. Yet, high-level rubrics don't tell you what the opportunity costs are, both up-front and long-term.
I read a lot. I spend close to $5,000 a year on technical literature, read about 100 books cover-to-cover per year, and I make notes on everything I read. Technical literature is scientific research, and should be treated as such. Such habits give me the disposition of a pitbull, and a ferociously acute antennae for detail.
Most books, articles, forum discussions, and blog entries I read discuss the advantages of a technology, and fail to identify the weaknesses. Teaching developers only about strengths is wrong. Of course, the flip side of the coin is that you need to be an expert to understand and identify weaknesses. Having the breadth and depth of an expert is rare, and most experts are too busy getting paid a lot of money solving problems to find the free time to write about best practices. Look no further than Microsoft and Google, who crave hiring senior engineers with 20 years of experience developing high-tech solutions. The average career in high-tech is only six years.
Furthermore, being an expert is not enough: you need to be a gifted communicator. Most programmers will only read something if the author talks to them like they are human. Too many books are filled with impenetrable academic prose.
Talk to me like I'm four years old, and want to be the coolest kid at school. Live vicariously through my desire to be the first kid to ride a bicycle... without training wheels. Involve me, then let go.
Humans live in the real world.
The real world is full of complex interactions that design patterns and practices catalogs don't show examples of.
WPF so far has a number of features that encourage poor practices, and many minor annoyances that disturb the designer-developer facade. This doesn't mean "WPF is not ready", but it means WPF has a lot more work to do. Yet, there is very little community discussion on how to improve the designer-developer user story. There is almost no public interaction between the WPF project team and the community. The WPF Disciples concept started off promising, but its application-based membership promotes groupthink. WPF project team members and WPF authors have joined this group, and it's essentionally a think tank on Windows User Experience. Yet, it is a closed group, effectively invite-only.
Yet, open discussion is the best way to stimulate new ideas. The barrier to entry is low, and anyone can contribute.
I'm not the least bit worried about my forthcoming WPF project. However, sometimes WPF feels like a tool that wants to control me, and I want a tool that will let me control it. It is agonizing trying to understand why some decisions were made, and try to advocate design improvements. Design fragments rarely at one's finger tips. I've read Chris Anderson's blog going back to 2003, and even found Windows Vista Avalon forum posts dating back to when he first joined the project, and even had a good laugh at how even someone as smart as Chris Anderson was struggling to wrap his head around what XAML should be. I distinctly recall reading discussions between Anderson, Ian Griffiths, and other beta testers regarding the early iterations of XAML, how some were thinking about using XSLT to generate XAML to provide dynamic UIs, and how others couldn't find an acceptable answer for a quintessential design question, "Why compile data?".
I found reading the Windows Vista Avalon forum bits enthralling, as it gave insight into how WPF evolved from Avalon into its current state. All of WPF's current design flaws came into focus for me. I saw past the explanations provided by Chris Anderson in Essential WPF, and came away with a much deeper picture as a result.
Furthermore, in the past six months, I've read every single blog post written by Rob Relyea, even blog posts only available through the Wayback Machine (and come to learn that he has way too many development blogs and seriously needs to consolidate his valuable thoughts into one place). Every time Rob was asked a XAML question via e-mail or on one of the forums, he wrote a blog post about it somewhere. I saw how many of XAML's features, in particular MarkupExtension classes, were created and incorporated into the default prefix namespace and x: prefix namespace. Recently, at PDC, Rob Relyea gave an excellent talk where he discussed what was going to be added to XAML, and why. This was the capstone for my shadowing Rob's thinking, and it is pretty clear to me that XAML is moving in two directions, one great direction and one mediocre perhaps even bad direction.
The hard part was tracking these design fragments down and consolidating notes on it, becoming well-versed with the thinking and design positions of the various WPF architects (John Gossman, Mike Hillberg, Rob Relyea, Chris Anderson, Greg Schechter).
I'd say it was worth it. I understand the framework backward, forward, and sideways. Also, I learned in six months what some folks spent the past 6 years of their life dedicated to.
However, I've come away with the impression that WPF is not geared toward four year olds, that it's MSDN documentation underwhelms and that the best design fragments have to be hunted down rather than available at my finger tips. It also consumes way too much of my time, when I could be solving other problems.
A lot of architects are asking me if they should make the leap to WPF, and they want to sample my experience as a measuring stick. My conclusion is that Microsoft isn't going to support them in solving their problems, and that they'd better hire somebody who is a WPF Language Lawyer if they do choose WPF, or they'll feel like they are programming with their pants down. I've also re-iterated how important it will be not to skimp on the training budget for WPF. For most, it's a different way to program and a different way to solve problems. Although technology may change fast, Nothing changes slower thanhow people think. Breaking habits is expensive, and although WPF has many wonderful features, it is competing with other foundation libraries for developer learning time.
Ultimately, with WPF, Microsoft designed something pretty good that still needs much more improvement, and is clearly the direction things are going in. Microsoft's biggest problem is they've overplayed their hand, and developers are struggling to learn WCF, WF, and WPF all at once. It doesn't help that these frameworks fepeat some concepts with just enough minor differences to be extremely annoying (DependencyObject and DepndencyProperty are a good example).
- John
What a great post! Long, but good. I agree that there isn't a lot of interaction, and as you can see from my earlier posts I am not as you say "Furthermore, being an expert is not enough: you need to be a gifted communicator". a great communicator. Especially in post's. Something I'm working on. And you hit the nail on the head in terms of books. Usually all I need is a basic example. To often we are treated to the authors best example instead of an easy answer to a simple question. Sometimes, it seems as though the author is really interested in showing you how smart he is instead. I was discussing this exact thing with a friend a few days ago about how some article examples whether in a book or on a web page are more akin to the "magic" realm and leave me to ponder about how stupid I am that I didn't know how this was done and furthermore can't figure how in anyone came buy this knowledge. Nine times out of ten the information is very specific and can only be used in a small number of situations, thus rendering it useless to me.
Yes I believe your correct WPF Disciples is an invite only. Based on the responses in this thread I would imagine there is no constructive criticism either. Lot's of pats on the back though which is great but I fail to see how this improves public relations on the matter or helps a manager decide the correct path to take on their next project or an re-write.
Binding is a huge issue to me. It's seems that everyone is binding crazy and WPF is kind of centered around it. Although I see the need for it, there are definitely situations where you wouldn't want to use it and I wish this was taken into account when new controls are written. A few year back a control could either be bound or not, it was your choice. Take for example the new WPF DataGrid, it's great and I'm glad that we finally have one. I was asking one of the team members working on the DataGrid about how to use it without it being bound "he said, why would you want to use it unbound" I was so taken back by that question because of the closed minding thinking. For a simple page with input fields or a simple grid by all means bind away. But I've run into many, many situations that binding didn't make things easier, it made it more difficult and to suggest that the one crescent wrench in you tool box could be used in every situation is mind boggling.
My point is, constructive criticism is necessary, there just isn't any outlet.
Since SP1 WPF has come a long way. I'm actually getting somewhere now. My biggest personal complaint is longing for the time I couldn't change the UI. I've had to discipline myself not to change everything. Once you start down the road with a theme it seems that you have to change everything. It's like updating part of a room and saying "Yuk" at the rest forcing you to do all the room.
Rob - Its almost 8 months I started this post. Based on the discussions, my readings, microsoft's roadmap from PDC 08, experience from developing apps on not just MS platform, and other platforms like JEE...
WPF is not same as WindowsForms. Windows Forms was built to be used by developers "End-to-End". Hence the tooling for Windows Forms was good to support developers. WPF still lacks support for developers to "DESIGN" screens right out of the box using Visual Studio. VS 2010 demo and WPF story from PDC shows lot of improvements. But I have not gotten my hand on it to confirm if this, looks like MS is starting to provide the toolset for developers to design UI on WPF.
On the other hand, lot of people that are on the other side of the aisle waiting for enriched toolset for WPF are developers. But designing WPF UI is not meant for developers. Hence MS decided to even keep two different tools Visual Studio the staple for developers and Expression for designers that would design the screens and developers would wire up events and populate data to those screens. Much like web development were HTML could be built by a marketing company that does not know anything about development, that will be fit into serverside programming by developers using JEE or .NET. Although has been in practice for quite some time, there has been basic flaw in this model. Designers does not know programming and programmers does not know designing. I am currently working on a JEE project where this is more evident. Programmers complain about the htmls and javascript created by the marketing designers and designers complain that programmers are limiting their creativity by use of programming best practices. Microsoft has taken it upon itself to solve this problem by introduction of WPF by creating two different toolset from getgo... Now with the uproar from programmers they are trying to unify some common elements into both. The more programmers realize this difference and embrace use of designers and expression to design UI elements, the more they will embrace WPF
Pl mark if answer solves your problem | Visit http://gajakannan.com/netarch.aspx for .net ref Arch - My 5 cents - in this version WPF is not ready for LOB mostly not because of performance issues or backward computability, but because of very sharp learning curve. In the next version of WPF, dev team made a lot of improvements in those (but not only) fields, and my feeling, that you should hold your questions to the next release :)
Tamir http://blogs.microsoft.co.il/blogs/tamir
If your question was answered, please mark it. - Next release in th sense 4.0 or future? If you meant after 4.0, can you please spend 70 minutes of your time on this http://channel9.msdn.com/pdc2008/PC11/ and repost your suggestion?
Pl mark if answer solves your problem | Visit http://gajakannan.com/netarch.aspx for .net ref Arch - GajaKannan
Well it's cool and I think it has it's uses. But I for one hope that desktop applications stay on the desktop. I cringe at the thought of desktop applications being run out of IE. I understand the need for ease of deployment and I understand that for remote applications Silverlight could be ideal. I also know that as developers we have to choose a platform and UI and as for that I think that we have to really evaluate where our applications are going. Now, and in the future and pick the platform that best suit's that need.
Rob - Very true and agree desktop apps should stay in desktop. The reason I posted link to the presentation is that what ever it shows that can be done with Silverlight, you can do more than that on WPF. I am not suggesting to convert a desktop to RIA because it is looks cool. I for one would prefer functionality along with coolness. One without other is useless.
Pl mark if answer solves your problem | Visit http://gajakannan.com/netarch.aspx for .net ref Arch - That Silverlight model doesn't discuss ANY of the problems I deal with on a day-to-day basis, or problems ANY architects I know of are trying to solve.
People come to me and they are asking for kludge solutions to just make things "work", because of weird conditional logic "code smells" in WPF and Silverlght.
Jamie Cool is showing me that Silverlight 3 is about building on top of what doesn't work for LOB applications by applying Visual FoxPro/Visual Basic/dBase style application development techniques. Half the video is about style, not substance. It doesn't deal with any of my challenges. I guess getting data out of a data source is just a problem I don't have, and Microsoft keeps trying to convince me I have this problem, and I can't figure out why?
This is not simply a tactical error by 'Softies. At best, it is Fire and Motion. At worst, it is a strategical one that they will pay the piper for years from now.
Why can't the 'Softies get together and fix my BASIC problems, instead of forcing me to use Visual Studio to obfuscate my WPF/SL annoyances? Visual Studio doesn't work with our agile techniques -- it gets in the way. We currently have 6 developers working for 45 (and growing) clients. Personally, I recognize Microsoft has customers who will continue to buy licenses if you give them VB-style tools. However, not fixing basic broken features bothers those of us who know how to turn complex problems into simple ones.
My basic opinion is that tools like Visual Studio and Blend have it all wrong. For rich business apps they're solving the wrong problems. I'm fairly certain my problems, BASIC problems, if fixed, make it easy for everyone else.
- I re-read your previous message to make sure I understand your pain points. I agree with all the question you have raised except that WinForms lets programmer to be a screen designer as well, means they could build a very functional User Experience. Coming from a programmer roots I say yes programmers can do a good job in creating a user experience. On the flip side, WPF/Silverlight is targetted towards teams that want to use someone that is a designer by profession to build user experience and a programmer worry about back end piece of code, basically building entities. That is not a bad process after all for people that has been beating up microsoft to provide support to a development model like this. Which is a better development model is dependent on how our team is organized and operates. I certainly like the latter approach so I dont need someone that has software engineering background to become a usability specialist and designer.
Pl mark if answer solves your problem | Visit http://gajakannan.com/netarch.aspx for .net ref Arch - Very broadly, all I said was the designer-developer story needs improving.
I didn't list my pain points, so it's not realistic to say you understand them. :)
In a few weeks I'll be switching teams at work again, back to rich client development. I'll have a different company head I'm reporting to, and will be allowed to spend some time writing a couple "What's severely wrong about WPF" articles. I'll be publishing these primarily for the Microsoft architectural team to look over with their key partners. I'm not going to go too in-depth, either. Just enough to get the point across and lay out big "Why on earth did you do this, and can you please undo it?" questions on the table for Microsoft to answer. I wish I could go into details on WPF Architecture pros and cons, but I can't afford to spend too much time dawdling on forums when I have to make my company money, or people get laid off due to the economy. It should be important enough to say, "These are the problems you don't even know you have, and how they can hurt a $50 billion Chief Architect stockholder."
Some people are very good at pointing out to people problems they don't even know they have -- conceptual blockbusting, if you will. I don't get paid to write code. I get paid to solve problems 450 Microsoft programmers looked at before me, made a complicated mess of, and now desperately need a person with a simple-minded solution.
I'll basically ask you this:
What in Jamie Cool's talk makes you think Silverlight development is any easier? What problems do you have today that Silverlight 3 is going to solve? It looks like they are taking the same old broken model, putting it in a champagne gown and slapping lipstick on it.
The current firm I work at hired me because they needed somebody who had a clear distinction between solving a problem and solving the right problem.
- Wish you good luck on your quest :)
Pl mark if answer solves your problem | Visit http://gajakannan.com/netarch.aspx for .net ref Arch - What is LOB? Anyway, there are a few things that need WinForms or that WPF needs (the quick graphics, mainly) but I would like to start using it. I have a big project on WinForms, so I don't use it much.
- I thought I'd wake this thread up, because I've been considering whether to jump over to WPF with our next development, away from WinForms. Here's what I know:
negatives:
(1) It'll be much slower to develop with WPF, from a developer productivity point of view (manually editing XML? That's so 90's!)
(2) Blend - it's useless. No really, it's totally useless. How long did I spend trying to get my controls to dock in the right places or nest correctly? Pffff.
(3) Performance - well, I can't choose end user systems, so I have to go with the lowest common denominator, which is a ____ laptop.
(4) Learning Curve - learning XAML is easy, is it? Well, no, it's no easier than learning, say, IDL. I have a strong feeling I shouldn't need to know it. I left that all behind when I moved to WinForms from C++/COM.
(5) Have no experience of using it, so have low confidence I'll be able to get the right performance out of it for any project I take on. If I have low confidence, I'm less likely to recommend its use, because here in the real world we get paid to get things done. This is something of a virtueless circle: no experience = low confidence, low confidence = no use, no use = no experience, no experience = low confidence.
positives:
(1) Very flexible. I mean really very flexible. In fact so flexible I hardly know where to start.
(2) Separation of code and UI. Good in principle, although I have absolutely no idea how this is useful because I've never had to plonk a new UI onto an old engine, or replace an old engine with a new UI (well, ok, adding a ribbon maybe, but that's pretty easy whether your using XAML or not, if you've coded your WinForms application without any associated asshattery).
(3) That's all.
