Is WPF dead: the present and future of WPF
pragmateek.com
pragmateek.com
For example, we have a very heavy desktop application that needs to run on Windows 7 PCs with IE 8. When we started developing this application a year ago, the cost to do it in HTML5/CSS/JS given the maturity of the tools at that time, compared to WPF, made WPF the obvious choice. In a few years when local web databases and synchronization frameworks have improved (we just saw a really neat one a day or two ago here on HN) and all the machines have been replaced with Windows 10 and IE 11, an offline web app would be the right choice. But we can't (or, don't want to) delay development until that time. So, for now, WPF is the right answer.
But anyone who thinks WPF is still a first-class citizen or that Microsoft is going to come back in marketing support of it is probably kidding themselves.
Which is strange, since this is the only place where they still dominate and offer tangible advantages over practically all other fat client solutions. Java desktop UIs are dead (except from Eclipse, which is a walking zombie despite their e4 efforts), and there are not many other options if you want a solution that supports bidirectional data binding.
The recent trend of using web applications inside a Webkit/Chromium container has a strange attraction, as convoluted as this solution is.
Truth be told, though, the development process was pretty straight-forward and I don't have anything negative to say about that aspect of the project (though our application was pretty straight forward). The only downside was we deployed the application at a university, where about 90% of students and staff were running OS X and unwilling to install Silverlight on their machines, which made sense; the iPhone 4 was already out, and responsive, cross-platform access was already considered MVP by most product managers at the time.
* Alienate users with a platform that's not compatible with their OS by default (OSX, Linux)
* Alienate users with a platform that's not compatible with the multiple platforms you may be targeting (Tablet, Phone, Laptop, Desktop)
* Require an extra step (e.g. Silverlight plugin) for users to run the app at all
I have(as many others) made the transitions from building WPF/Silverlight applications to HTML/JS and im astonished over how eager the community is it solve the same problem over and over again. It seems like everyone just goes ahead and reimplementing their own solution instead of improving whats already exists. Every week someone releases a framework, tool etc. thats exactly the same as the five alternatives already existing and often the only difference is that it`s "implemented by us". And I will not start with NodeJs, 40 frameworks for spinning up an http-server. Congratulations.
So my two cents, long live WPF, the mature framework for creating Windows applications for many, many years to come!( at least in enterprise ;) )
I wouldn't say that is true. For example even renaming a Window/UserControl in Visual Studio doesn't work correctly. There are a ton of things that could be improved about WPF, not least (off the top of my head):
* Use Direct2D instead of DirectX9. The renderer used by WPF has been shown to be very inefficient compared to Direct2D.
* Multiple selection is a hack.
* Can't bind data grid column properties.
* BasedOn="{StaticResource {x:Type Button}}" -- eurgh
* How fucking difficult it is to save an image?
* How fucking difficult it is to get an image's pixels (how do you work out Stride?)
Is that why the capability of a user's video card had an appreciable impact on the performance of a WPF-based app that's little more than a text viewer and editor, at least as of 2009 (see http://community.logos.com/forums/t/6200.aspx)? Is the WPF renderer still suboptimal on today's graphics hardware? I'm thinking in particular of Intel's integrated graphics starting with Sandy Bridge. And does Direct2D have a better software fallback?
Direct2D vs DX9 is probably a valid point, I have never faced any issue with this.
The rest of them I don`t think I follow you on. Two trivial image tasks, one ugly syntax and two issue I can`t seem to have encountered.
It should be noted that I always have used telerik`s awesome UI components together with WPF. Which both features and documentation are top notch.
http://grokys.blogspot.it/2010/07/mvvm-and-multiple-selectio...
(unfortunately the images seem to have expired, grr)
Now, WPF may be ahead of the HTML/JS from a technical point of view right now. But the community is a completely different thing. That's what differentiates things today (not to mention the bag of cash Google is pushing into web standards) and really is the only thing that matters when it comes to the success/failure of a technology.
I think you're right that WPF will last a good deal longer. There's too much software already written for Windows/.NET, but "many, many" years is a stretch.
I'm not innocent of this - I moved from Textmate to Sublime in the hope of exciting new features, and because many people in the community did the same, I have a healthy ecosystem available to me. The point still remains that there is very little wrong with Textmate, in the same way that WPF may still be completely viable.
The new cool is the new cool. People go where the work is and go where their peers are.
Those constraints are usually as follows:
- Our developers cannot use anything not written and distributed by Microsoft, and can use only our existing licenses.
- The end users will not have full administrative control over their workstations. They might not be able to install a Java VM, Flash, Silverlight, or even a browser other than the version of IE that came with their OS.
This sort of environment is depressingly common in the government contracting sector. When your choices are WPF, WinForms, ASP.NET, Excel macros, or Access database, the first option seems pretty attractive. And this is especially relevant when the documentation from Microsoft promotes a model-view-viewmodel design pattern for WPF applications. That's a great way to get people who haven't read a single paragraph about best practices since graduation to step boldly into a new decade, even if it is not the one the rest of us currently live in.
Cache link: http://webcache.googleusercontent.com/search?q=cache%3Apragm...
The complexity of the design was overwhelming and yet pointless. Architected to space it was. Take a look at the signature and inheritance diagram for the "Rectangle" class.
http://msdn.microsoft.com/library/system.windows.shapes.rect...
How can they possibly extend upon that without making it uglier!? Just leave it in maintenance mode like with all the other failed MS GUI frameworks.
That said, now that I'm on my own, I'm not switching to it. The legacy windows-only apps I support I'm sticking to WinForms, because I don't want to spend effort on learning yet another Microsoft ecosystem API. I'm actively getting out of MS-only work now.
Unfortunately, there are no UI toolkits that I would call "good". They all have some weird idiosyncrasy to them. It's like they all start out with a great idea, and then beef it in the face halfway through completing the full set of controls that would be useful to most people. It necessitates 3rd party control libraries of vastly variable quality, and makes it extremely difficult to tell clients "yes, we can do that, and it will be done by XYZ date".
So, lacking a better alternative, I'm going all-in on HTML5. It's the closest to "ideal" of what I want for a UI toolkit. I've about decided that I really, really don't want my UI to be anywhere near my application layer. A node-webkit-style deal might be bothersome to some people, but for my ideals, it's exactly how I want to arrange my applications.
I'd just like it very much if Node weren't my only readily available option. I like Node for small things, and I use it in a few projects, but there are some other projects where I'd really prefer to be writing the backend in C#, or C, or anything with a wide variety of libraries that aren't mostly just a weekend project for a CS grad somewhere like half of everything on NPM often appears to be.
There are endless lists of technologies that do the exact same thing.
What matters is XAML and data binding and it is pretty much alive.
Just because the XAML and .NET classes used by WPF are a little different than the XAML and .NET classes from Silverlight or XAML and .NET classes from WinRT, the concepts are always the same ones.
On Mac we had classic (carbon) and then AppKit (which is arguably the same UI toolkit since the 90s on NextStep but still doing ok.. although feeling a little dated compared to UIKit).
Linux is a cluster of UI systems but at least X is stable.
Consider this a mistake, and learn from it: don't depend on any vendor's altruism, always look to diversify your knowledge and options, avoid vendor lock-in at all costs. I believe Apple will be a much bigger drama when this happens.
I was thinking of going the web application route but I get the sense that a Windows executable is the way to go here, with its faster/more responsive interface. Major features needed: Embed and modify web pages in tabs (recreate a web browser), social "ticker" or feed, lots of cross-connections between different types of content (KB articles and tickets, for instance).
Should I go with a WPF application? I would have to teach myself XAML and C#. It would be limited in scope so that's good but it could still take forever.
Make a browser plugin in HTML/CSS/JS?
Make a full page Angular app?
In all these cases I'm going to have to learn something new, learning about Windows development may help me get ahead at my company more than other technologies, but if this project takes too long then it won't be worth it.
Any thoughts?
But those are hefty requirements for a small in-house project! Spending a lot of extra programming time on production values is what you do when you're trying to appeal to the mass market. If nobody outside your team is ever going to use the program, that kind of effort doesn't pay off. Who decided the feature list and designed the user interface? Do they realize the cost and schedule implications?
Not a crazy feature list, and like I said I am learning how to do this from scratch so it's kind of a 20% time hobby that I hope turns into something usable in a reasonable amount of time (3-6 months).
It just works. Some niche markets still prefer to use desktop applications.
Now, if you've only heard a little bit about Qt, you might be tempted to think you only need it if you need cross-platform, but in my experience it's actually better than any of the Microsoft frameworks even purely on Windows. (A simple test: write a Hello World program in Winforms, WPF and Qt, then try doing some simple drag operations with the mouse, moving the window around, resizing it. Last I tried, Qt was the only one that updated the window correctly, without flicker. This remained true even after I tried the recommended solutions in Winforms and WPF to reduce flicker.)
The fact that Qt gives you the option of going cross-platform if you ever need it in the future is just a nice bonus.
It's still _supported_ and there are a ton of vendors still shipping components. Abandoned/EOL/Discontinued is something like FoxPro or Apple's Rosetta emulator. It's not even deprecated.
Is there any single UI framework that a dev can invest in for Microsoft's various platforms and have confidence that they won't be moving to some other UI framework in 12 months?
They seem to be in disarray moving forward in this area.
Could I do it in a web app? Probably. But it would take a lot more work for me and I'd be battling compatibility with IE7 (yes, we're still on IE7) as the corporate web minimum spec.
WinRT felt half-baked when I used it about a year and a half ago. Furthermore, I doubt Win8 is on the docket for quite some time.
WPF hasn't been the 'cool thing' for quite some time (ever?), but both I and my users seem to really enjoy what it's doing for us. And that's good enough.
But if you've already got a captive audience able to run anything .NET 4.0 and above (incl. async/await via Bcl.Async libraries) with the rich experience of WPF, why bother shoehorning a web application as a solution?
Our users are in a manufacturing environment, on a well-known environment. It's practically like developing for a gaming console. And in that light, WPF seems to be a good fit.
We're able to produce a standalone desktop application and a web app using the same code and have it looking/working exactly the same, on different platforms.
A shame, because it's probably the best UI framework I've used. I liked it much better than HTML.
Also, one unfortunate aspect of the .NET community is a lot of people know next to nothing about anything outside the MS ecosystem and have a blindly dismissive attitude toward it (at least until MS latches onto it like they have with Angular and others).
If you want to do Linux development, might as well just do it instead of using a crippled version of C#.
Anyway, why not Windows? If you're a C# guy you're probably familiar with it, there is no longer the client penalty (given that you can make a SPA or whatever for most LOB apps), and the cost of licenses is likely small compared to labor, especially if you're already a Windows shop.
He doesn't say it was a meeting with actual developers. Just because a sales/management guy says they are working on it doesn't make it true.
Microsoft has a history of this. MFC, Winforms, WPF, and now WinRT
Microsofts now is more open to the open source community. That does not mean that 'old' mature frameworks are dead. It's all about choice.
XAML, for certain, is here to stay for quite a while. I recall talking to Carl Franklin about how Windows 8's UI layer is written in XAML. Given that, I think it's fair to say that the time you invest in XAML won't be wasted if you're a Windows developer. WPF may fade into the background, but WinRT will continue to mature and broaden as a platform (esp. as Windows 10 opens the door to cross-device compatibility)
And wait until they lose interest in WinRT too like they have done with every new technology quickly.
But for fat applications, what's your alternative? Java is, at best, parity with something like WinRT but can't leverage the benefits that MS can bring to users with its native platform (assuming a big, MS-centric enterprise). WPF, as we've already said, isn't going to get any more of the pie. Let's not kid ourselves about Winforms or platforms that haven't even embraced data binding.
In the meantime, you can't cross off Xamarin as a means to bring these WinRT applications to even more device types.
http://msdn.microsoft.com/en-us/library/ef2xyb33
WPF main advantage over Winforms is XAML vs tool-generated designer class IMHO. Most of the other concepts have their equivalents in both technology.
• databinding (which it shares with most other things coming from MS; I think even VB had it; interestingly enough, it's somewhat absent everywhere else)
• decoupling behaviour from visuals
• somewhat related to the last point: templating
Especially the last two are what makes WPF awesome. Databinding is just the glue that's needed for the other two to work awesomely. Being able to say »I want this to work like a ToggleButton but look slightly different« (and keeping all the behavioural logic in place without needing to reimplement it) and »I define how my data will look like in terms of the same containers and controls that I build my UI with and (usually) have no performance disadvantage« are the things that are really nice. I take a collection of things, databind them to a ListBox, use a DataTemplate to control how each of them looks and am able to use normal controls in said template that can interact with the data and are not just images pasted onto the UI (like in Swing or Android). And all that without the need to write a single line of code that moves my data from code to UI (or back).
http://www.codeproject.com/Articles/17188/Inversion-of-Contr...
Where things start to get complicated are the objects that you create with XAML... (which is where the WPF framework comes into play.)
Five or six years ago, I prototyped a system using XAML/WPF to build an HMI system for an industrial process control applications. The system served up XAML from a server that got loaded by a client to construct UI objects. It then inspected the Binding objects that the XAML created and started subscribing to the appropriate server-side data points. It came together within a couple days and really ran quite well.