7 ms·

Is WPF dead: the present and future of WPF

97 points by anilmujagic 12y ago

0x0 12y ago
Page not found? Cache link: http://webcache.googleusercontent.com/search?q=cache%3Apragmateek.com%2Fis-wpf-dead-the-present-and-future-of-wpf%2F http://webcache.googleusercontent.com/search?q=cache%3Apragm...
dotsamuelswan 12y ago
Same topic. Different Author. http://greglevenhagen.com/is-wpf-dead-no/ http://greglevenhagen.com/is-wpf-dead-no/
- ripter 12y ago
  "I was just in a meeting with Microsoft and they’re definitely working on the next version of WPF. Obviously, I can’t disclose specifics, but the fact is they are gathering feedback and actively working on WPF." 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
mu_killnine 12y ago
As a developer for my company's internal LoB tools, I really enjoy WPF more than Winforms. I feel very empowered and, as a Microsoft shop, it seems to be really great for meeting a specific aesthetic and function for my users. 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.
- TheMakeA 12y ago
  If you have the choice to deploy a WPF app, couldn't you ship something using chromiumembedded to get the benefits of a web app without worrying about browser compatibility? In the past, I've even dropped a CEF WebView into WPF and had the UI in HTML/CSS/JS.
  - mu_killnine 12y ago
    Perhaps. I am not familiar with the project. 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.
    - emodendroket 12y ago
      I have pretty limited experience with desktop stuff (mostly Winforms) but with the SPA frameworks now it's about as expressive and deployment issues go away (which is nice in a small shop where you can't just foist them on someone else).
  - jenscow 12y ago
    This is what I'm doing. 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.
robbyking 12y ago
I actually wrote an application using WPF, and what's worse is it was relatively recently. The project was an audio/visual control application, and our CEO (not CTO) made the decision to use WPF because "the Mac fad was in its final days." (Never mind the obvious, platform-neutral rebuttals.) 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.
- mu_killnine 12y ago
  I am writing a WPF app now, I don't think that's necessarily a bad thing. The issue I see with your example is that WPF as a platform went against just about everything your user needed. * 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 That's why the LoB example is such a powerful testament to how WPF may stick around. You've got 'trapped' users (for better or worse) who will likely be forced on the Windows platform.
zbowling 12y ago
I thought this pretty apparent a few years ago? Has everyone still been on the bandwagon and still developing in WPF heavily? I sure Microsoft is not going to kill it but it's not the active area of focus with RT. It's unfortunate. Friends that develop components have had to go from VB6 (native ActiveX/OLE C++ components) to WinForms to WPF to Silverlight (then back to WPF) and now RT. No one UI system to rule them all. Always uncertainty that it will change. Hell it changed a lot from CE 6.5 to WinMo 7 to WinMo 8. 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.
- wolfgke 12y ago
  WinAPI is stable.
malkia 12y ago
All I can say is - Sticking to Qt5 for now.
- maxxxxx 12y ago
  If I had to start a new desktop app now I would also go for Qt. I am tired of MS rolling out new frameworks and abandoning them a few years later.
  - Scuds 12y ago
    In Visual Studio 14 CTP4 you can still File -> New VB / C# Project -> Windows Forms in same as you could ten years ago, but with the next generation CLR in the new IDE. 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.
    - maxxxxx 12y ago
      Sure you can. But you are locked into a framework that reached its peak a few years ago. It's like writing HTML that's compatible with IE6. You can do this and it works but you are stuck in the past.
steven777400 12y ago
WPF is dead in the sense that Microsoft doesn't want to be promoting a non-cloud, non-mobile technology. WPF is alive in the sense that it is the best solution for meeting certain customer needs today. 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.
- _random_ 12y ago
  Enjoy it while it lasts, Bootstrap/HTML and JS are so lame after XAML and C# :(.
  - jenscow 12y ago
    In my opinion, Dart makes JS less lame (via dart2js). It's the closest you'll get to C# in the browser.
    - MichaelGG 12y ago
      Or just write in F# and compile to JavaScript. That's better than C# in the browser.
  - tonyedgecombe 12y ago
    I just started a new WPF application, I don't think it is going away any time soon.
- _pmf_ 12y ago
  > WPF is dead in the sense that Microsoft doesn't want to be promoting a non-cloud, non-mobile technology. 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.
ZanyProgrammer 12y ago
A lot of the criticism I've heard stems around the steep XAML learning curve. OTOH I've only done WinForms and ASP.NET stuff, so I haven't had first hand experience.
- mu_killnine 12y ago
  That's a pretty fair criticism. But once you've gotten it, it's very powerful (incredible data binding!). And I think we need to be sure to separate WPF from "XAML". 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)
  - maxxxxx 12y ago
    Good luck finding a company that uses Win 8 so you can actually deploy a WinRT app. And wait until they lose interest in WinRT too like they have done with every new technology quickly.
    - mu_killnine 12y ago
      My guess is most companies will skip Win8 like they skipped Vista. Windows 10 looks to be what enterprise will rally around. 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.
      - Thieum22 12y ago
        Winforms has data binding. http://msdn.microsoft.com/en-us/library/ef2xyb33 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.
codereflection 12y ago
It will be interesting to see if the editor in Visual Studio is re-written again (it has been WPF based since VS 2012). If a hint of that comes out, then I think we can safely declare WPF as dead.
- bdavisx 12y ago
  I think it was WPF based starting with VS 2010 actually.
  - codereflection 12y ago
    You are correct, it was 2010.
- bithush 12y ago
  I miss the editor from pre-VS2010. The WPF based one has so many problems with fonts other than Consolas and Courier New. Such a pain in the ass.
- CmonDev 12y ago
  The Visual Studio 2020 might be completely in-browser unfortunately :(.
amaks 12y ago
WPF is another victim in ever changing technological landscape in Microsoft. Who uses or even remembers these days ATL/WTL, MFC, OLE DB, ADO, DAO, ODBC etc. etc.?
- fleitz 12y ago
  Now you know why MSFT has the largest developer community in the world. There are endless lists of technologies that do the exact same thing.
- _random_ 12y ago
  Will anyone be mad enough to adopt the next living corpse of tomorrow - WinJS?
- mpthrapp 12y ago
  I still use ADO and ODBC (oh, and the BDE, remember that one?) on a regular basis. I wish I didn't, but I do.
  - dvere 12y ago
    Raises hand, still have a VM with Delphi 7 that is opened once a week or so....
    - mpthrapp 12y ago
      Only once a week? Can I have your job, please? I get to use that and 5 on a daily basis.
- pjmlp 12y ago
  Who uses or even remembers these days QuickDraw, QuickDraw 3D, WebObjects, Carbon, Qt for Java, Java Bridge, Nettalk, Hypercard, NewtonScript, etc
andwaal 12y ago
What is never really can grasp is the conclusion that no new versions equals a dead platform. In the case with WPF(and Silverlight to some degree) the platform is so mature, that one got all the features that is needed to create rich applications, while having a nice developer experience. It`s just done, no need for future versions and fixes, so one can start build things with it instead. 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 ;) )
- grokys 12y ago
  > all the features that is needed to create rich applications, while having a nice developer experience 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?)
  - peetle 12y ago
    One should not confuse the IDE with the technology, but I'd agree that the Visual Studio integration with WPF (although amazing in theory) feels constantly buggy - even after years of work.
    - grokys 12y ago
grokys 12y ago
Personal plug here: I've been tinkering with writing a GUI toolkit along the lines of WPF here: https://github.com/grokys/Perspex/ https://github.com/grokys/Perspex/. It's obviously very early days and this is as much for my curiosity as to how things could be done differently as setting out to replace WPF, but it may interest some of you...
logfromblammo 12y ago
Given enough constraints on the development environment, WPF can turn out to be the best choice. 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.
_random_ 12y ago
I am a Microsoft fan but my thinking recently is like this: why WPF => why Windows => why Microsoft? If crappy HTML5 and JS are their agenda, then what's the point sticking to their ecosystem?
- emodendroket 12y ago
  So you can leverage your/your team's existing knowledge of C#/the .NET Framework, which seems like a good enough reason. Lots of Web sites are still built on ASP.NET MVC. 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).
  - jenscow 12y ago
    With asp.net vNext able to run on Linux (officially), the question still remains: Why Windows => Why Microsoft? (apart from leeching their tech)
    - emodendroket 12y ago
      Mono is significantly behind in terms of features supported (essentially the equivalent of two versions), you'll run into interop problems with plenty of libraries, and from what people who have spent a lot of time with it have told me there are a lot of subtle incompatibilities and bugs that eat up a lot of your time. The tooling is also worse. 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.
GlennS 12y ago
I was told 3 or 4 years ago by a Microsoft MPV that WPF was effectively in maintenance mode with only a single guy working on it. A shame, because it's probably the best UI framework I've used. I liked it much better than HTML.
- ygra 12y ago
  Given that HTML is probably the worst UI framework that ever existed, that doesn't say much. However, WPF is so far ahead of every other UI framework I used (WinForms, Swing, Qt, Android, MFC) that its descent into maintenance mode is a bit sad. Also that no one bothers to look at what WPF did right when starting new UI toolkits and frameworks and we get more stuff that awkward and clunky to develop for that looks like all other UI APIs from the 90s.
moron4hire 12y ago
I've been doing Windows development for over a decade now. WPF was too different from WebForms (or less often, WinForms) to get most of the other developers on every team I've worked on to agree to switch to it. I wish we had switched way back when, because it is a much better design than (Web|Win)Forms. 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.
- rwallace 12y ago
  Well, one nice thing about using JavaScript and HTML 5 for the front end is it does, as you say, give you a lot of decoupling, which means you don't actually have to use Node for the back end; you're free to use C++ or Python or whatever you find best.
- rmsaksida 12y ago
  Why is Node your only readily available option? There's nothing stopping you from writing the backend in C# (or anything else) and the client code in HTML and JavaScript.
  - 12y ago
joseacta 12y ago
We make a software for licensing WPF applications, http://www.licensespot.com http://www.licensespot.com, and it's been growing pretty steady in the last few months so I guess there are still a lot of people developing and selling apps in WPF. It just works. Some niche markets still prefer to use desktop applications.
- ternaryoperator 12y ago
  Not even so niche. Businesses are still primarily PC/desktop oriented.
doczoidberg 12y ago
WPF is not dead. It is mature as Winforms is. 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.
rwallace 12y ago
If I was writing line of business software these days, I'd either go the web route and use JavaScript and HTML 5, or if it was something that preferred to live on the desktop, I'd use Qt. 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.
mwcampbell 12y ago
I think the best thing that Microsoft could do for developers right now is to backport a reasonable subset of WinRT to Windows 7 and provide it as a redistributable, even if we have to pay for it. I'd suggest backporting the XAML-based UII toolkit and at least some of the other APIs, but not the app container or store-based distribution.
triangleman 12y ago
I'm planning on developing a collaborative helpdesk application for my small team (perhaps 30 users), having only previous experience in standard HTML/CSS/JS/PHP/SQL development. 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?
- rwallace 12y ago
  Given your stated requirements, I'd use Qt. There's a learning curve, but no worse than with WPF or anything else. 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?
  - triangleman 12y ago
    Maybe I oversold the feature list... I'm really just trying to do an incremental thing, a "single-page app" that helps tech support agents keep track of their tickets and what's going on with the rest of the team. Because the ticketing system is web based I figure I need to embed the web pages into the app. Then I need to make DOM calls to the page to get some info out of them, or perhaps make various GETs and POSTs to get the info I need, displayed alongside the webpage. 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).
goalieca 12y ago
WPF died to me because of its complexity. I absolutely hated my last job doing development in that environment. 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.rectangle(v=vs.110).aspx 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.
forgotAgain 12y ago
There is another question beyond WPF being dead or not. 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.
rmsaksida 12y ago
I've had limited exposure to WPF, but I found it absolutely delightful. When you work with web development for so long, working on a desktop app feels very refreshing. The toolkit lets you focus (choice is hard); data binding is awesome; components are all readily available; there's rich IDE integration which mostly just works; you can easily offload almost everything from the backend; and with some good sense, you can drag & drop yourself to a reasonably good looking and usable interface in record time.
danbruc 12y ago
You can get quite far with the simple equation XAML + Control Library = WPF = Silverlight = Windows Phone UI = ... some of the runtimes are more powerful, some are less powerful, but they are really similar to develop with. I can see runtimes come and go but the way you build UIs on top of them does not look like going away soon. And - at least to me - this is a good thing, it is a great way to build UIs.
pjmlp 12y ago
WPF is only dead for those that cannot think out of the box. 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.
- CmonDev 12y ago
  What is the out-of-box solution for adorner decorators, then?
randunel 12y ago
I felt a similar betrayal that this author felt when Adobe started to drop support for Flash, stopping any development. Their claim of supporting every device with AIR went south not by dropping AIR support (which happened when they stopped Linux support), but by not developing the Flash platform as new devices and OSes poured into the markets. I have since successfully moved on, but I did feel weary for more than a year, unsure where I was heading. 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.

97 points by anilmujagic 12y ago

0x0 12y ago

Page not found? Cache link: http://webcache.googleusercontent.com/search?q=cache%3Apragmateek.com%2Fis-wpf-dead-the-present-and-future-of-wpf%2F http://webcache.googleusercontent.com/search?q=cache%3Apragm...

dotsamuelswan 12y ago

Same topic. Different Author. http://greglevenhagen.com/is-wpf-dead-no/ http://greglevenhagen.com/is-wpf-dead-no/

ripter 12y ago
"I was just in a meeting with Microsoft and they’re definitely working on the next version of WPF. Obviously, I can’t disclose specifics, but the fact is they are gathering feedback and actively working on WPF." 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

mu_killnine 12y ago

As a developer for my company's internal LoB tools, I really enjoy WPF more than Winforms. I feel very empowered and, as a Microsoft shop, it seems to be really great for meeting a specific aesthetic and function for my users. 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.

TheMakeA 12y ago
If you have the choice to deploy a WPF app, couldn't you ship something using chromiumembedded to get the benefits of a web app without worrying about browser compatibility? In the past, I've even dropped a CEF WebView into WPF and had the UI in HTML/CSS/JS.
- mu_killnine 12y ago
  Perhaps. I am not familiar with the project. 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.
  - emodendroket 12y ago
    I have pretty limited experience with desktop stuff (mostly Winforms) but with the SPA frameworks now it's about as expressive and deployment issues go away (which is nice in a small shop where you can't just foist them on someone else).
- jenscow 12y ago
  This is what I'm doing. 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.

robbyking 12y ago

I actually wrote an application using WPF, and what's worse is it was relatively recently. The project was an audio/visual control application, and our CEO (not CTO) made the decision to use WPF because "the Mac fad was in its final days." (Never mind the obvious, platform-neutral rebuttals.) 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.

mu_killnine 12y ago
I am writing a WPF app now, I don't think that's necessarily a bad thing. The issue I see with your example is that WPF as a platform went against just about everything your user needed. * 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 That's why the LoB example is such a powerful testament to how WPF may stick around. You've got 'trapped' users (for better or worse) who will likely be forced on the Windows platform.

zbowling 12y ago

I thought this pretty apparent a few years ago? Has everyone still been on the bandwagon and still developing in WPF heavily? I sure Microsoft is not going to kill it but it's not the active area of focus with RT. It's unfortunate. Friends that develop components have had to go from VB6 (native ActiveX/OLE C++ components) to WinForms to WPF to Silverlight (then back to WPF) and now RT. No one UI system to rule them all. Always uncertainty that it will change. Hell it changed a lot from CE 6.5 to WinMo 7 to WinMo 8. 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.

wolfgke 12y ago
WinAPI is stable.

malkia 12y ago

All I can say is - Sticking to Qt5 for now.

maxxxxx 12y ago
If I had to start a new desktop app now I would also go for Qt. I am tired of MS rolling out new frameworks and abandoning them a few years later.
- Scuds 12y ago
  In Visual Studio 14 CTP4 you can still File -> New VB / C# Project -> Windows Forms in same as you could ten years ago, but with the next generation CLR in the new IDE. 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.
  - maxxxxx 12y ago
    Sure you can. But you are locked into a framework that reached its peak a few years ago. It's like writing HTML that's compatible with IE6. You can do this and it works but you are stuck in the past.

steven777400 12y ago

WPF is dead in the sense that Microsoft doesn't want to be promoting a non-cloud, non-mobile technology. WPF is alive in the sense that it is the best solution for meeting certain customer needs today. 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.

_random_ 12y ago
Enjoy it while it lasts, Bootstrap/HTML and JS are so lame after XAML and C# :(.
- jenscow 12y ago
  In my opinion, Dart makes JS less lame (via dart2js). It's the closest you'll get to C# in the browser.
  - MichaelGG 12y ago
    Or just write in F# and compile to JavaScript. That's better than C# in the browser.
- tonyedgecombe 12y ago
  I just started a new WPF application, I don't think it is going away any time soon.
_pmf_ 12y ago
> WPF is dead in the sense that Microsoft doesn't want to be promoting a non-cloud, non-mobile technology. 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.

ZanyProgrammer 12y ago

A lot of the criticism I've heard stems around the steep XAML learning curve. OTOH I've only done WinForms and ASP.NET stuff, so I haven't had first hand experience.

mu_killnine 12y ago
That's a pretty fair criticism. But once you've gotten it, it's very powerful (incredible data binding!). And I think we need to be sure to separate WPF from "XAML". 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)
- maxxxxx 12y ago
  Good luck finding a company that uses Win 8 so you can actually deploy a WinRT app. And wait until they lose interest in WinRT too like they have done with every new technology quickly.
  - mu_killnine 12y ago
    My guess is most companies will skip Win8 like they skipped Vista. Windows 10 looks to be what enterprise will rally around. 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.
    - Thieum22 12y ago
      Winforms has data binding. http://msdn.microsoft.com/en-us/library/ef2xyb33 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.

codereflection 12y ago

It will be interesting to see if the editor in Visual Studio is re-written again (it has been WPF based since VS 2012). If a hint of that comes out, then I think we can safely declare WPF as dead.

bdavisx 12y ago
I think it was WPF based starting with VS 2010 actually.
- codereflection 12y ago
  You are correct, it was 2010.
bithush 12y ago
I miss the editor from pre-VS2010. The WPF based one has so many problems with fonts other than Consolas and Courier New. Such a pain in the ass.
CmonDev 12y ago
The Visual Studio 2020 might be completely in-browser unfortunately :(.

amaks 12y ago

WPF is another victim in ever changing technological landscape in Microsoft. Who uses or even remembers these days ATL/WTL, MFC, OLE DB, ADO, DAO, ODBC etc. etc.?

fleitz 12y ago
Now you know why MSFT has the largest developer community in the world. There are endless lists of technologies that do the exact same thing.
_random_ 12y ago
Will anyone be mad enough to adopt the next living corpse of tomorrow - WinJS?
mpthrapp 12y ago
I still use ADO and ODBC (oh, and the BDE, remember that one?) on a regular basis. I wish I didn't, but I do.
- dvere 12y ago
  Raises hand, still have a VM with Delphi 7 that is opened once a week or so....
  - mpthrapp 12y ago
    Only once a week? Can I have your job, please? I get to use that and 5 on a daily basis.
pjmlp 12y ago
Who uses or even remembers these days QuickDraw, QuickDraw 3D, WebObjects, Carbon, Qt for Java, Java Bridge, Nettalk, Hypercard, NewtonScript, etc

andwaal 12y ago

What is never really can grasp is the conclusion that no new versions equals a dead platform. In the case with WPF(and Silverlight to some degree) the platform is so mature, that one got all the features that is needed to create rich applications, while having a nice developer experience. It`s just done, no need for future versions and fixes, so one can start build things with it instead. 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 ;) )

grokys 12y ago
> all the features that is needed to create rich applications, while having a nice developer experience 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?)
- peetle 12y ago
  One should not confuse the IDE with the technology, but I'd agree that the Visual Studio integration with WPF (although amazing in theory) feels constantly buggy - even after years of work.
  - grokys 12y ago

grokys 12y ago

Personal plug here: I've been tinkering with writing a GUI toolkit along the lines of WPF here: https://github.com/grokys/Perspex/ https://github.com/grokys/Perspex/. It's obviously very early days and this is as much for my curiosity as to how things could be done differently as setting out to replace WPF, but it may interest some of you...

logfromblammo 12y ago

Given enough constraints on the development environment, WPF can turn out to be the best choice. 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.

_random_ 12y ago

I am a Microsoft fan but my thinking recently is like this: why WPF => why Windows => why Microsoft? If crappy HTML5 and JS are their agenda, then what's the point sticking to their ecosystem?

emodendroket 12y ago
So you can leverage your/your team's existing knowledge of C#/the .NET Framework, which seems like a good enough reason. Lots of Web sites are still built on ASP.NET MVC. 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).
- jenscow 12y ago
  With asp.net vNext able to run on Linux (officially), the question still remains: Why Windows => Why Microsoft? (apart from leeching their tech)
  - emodendroket 12y ago
    Mono is significantly behind in terms of features supported (essentially the equivalent of two versions), you'll run into interop problems with plenty of libraries, and from what people who have spent a lot of time with it have told me there are a lot of subtle incompatibilities and bugs that eat up a lot of your time. The tooling is also worse. 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.

GlennS 12y ago

I was told 3 or 4 years ago by a Microsoft MPV that WPF was effectively in maintenance mode with only a single guy working on it. A shame, because it's probably the best UI framework I've used. I liked it much better than HTML.

ygra 12y ago
Given that HTML is probably the worst UI framework that ever existed, that doesn't say much. However, WPF is so far ahead of every other UI framework I used (WinForms, Swing, Qt, Android, MFC) that its descent into maintenance mode is a bit sad. Also that no one bothers to look at what WPF did right when starting new UI toolkits and frameworks and we get more stuff that awkward and clunky to develop for that looks like all other UI APIs from the 90s.

moron4hire 12y ago

I've been doing Windows development for over a decade now. WPF was too different from WebForms (or less often, WinForms) to get most of the other developers on every team I've worked on to agree to switch to it. I wish we had switched way back when, because it is a much better design than (Web|Win)Forms. 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.

rwallace 12y ago
Well, one nice thing about using JavaScript and HTML 5 for the front end is it does, as you say, give you a lot of decoupling, which means you don't actually have to use Node for the back end; you're free to use C++ or Python or whatever you find best.
rmsaksida 12y ago
Why is Node your only readily available option? There's nothing stopping you from writing the backend in C# (or anything else) and the client code in HTML and JavaScript.
- 12y ago

joseacta 12y ago

We make a software for licensing WPF applications, http://www.licensespot.com http://www.licensespot.com, and it's been growing pretty steady in the last few months so I guess there are still a lot of people developing and selling apps in WPF. It just works. Some niche markets still prefer to use desktop applications.

ternaryoperator 12y ago
Not even so niche. Businesses are still primarily PC/desktop oriented.

doczoidberg 12y ago

WPF is not dead. It is mature as Winforms is. 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.

rwallace 12y ago

If I was writing line of business software these days, I'd either go the web route and use JavaScript and HTML 5, or if it was something that preferred to live on the desktop, I'd use Qt. 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.

mwcampbell 12y ago

I think the best thing that Microsoft could do for developers right now is to backport a reasonable subset of WinRT to Windows 7 and provide it as a redistributable, even if we have to pay for it. I'd suggest backporting the XAML-based UII toolkit and at least some of the other APIs, but not the app container or store-based distribution.

triangleman 12y ago

I'm planning on developing a collaborative helpdesk application for my small team (perhaps 30 users), having only previous experience in standard HTML/CSS/JS/PHP/SQL development. 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?

rwallace 12y ago
Given your stated requirements, I'd use Qt. There's a learning curve, but no worse than with WPF or anything else. 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?
- triangleman 12y ago
  Maybe I oversold the feature list... I'm really just trying to do an incremental thing, a "single-page app" that helps tech support agents keep track of their tickets and what's going on with the rest of the team. Because the ticketing system is web based I figure I need to embed the web pages into the app. Then I need to make DOM calls to the page to get some info out of them, or perhaps make various GETs and POSTs to get the info I need, displayed alongside the webpage. 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).

goalieca 12y ago

WPF died to me because of its complexity. I absolutely hated my last job doing development in that environment. 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.rectangle(v=vs.110).aspx 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.

forgotAgain 12y ago

There is another question beyond WPF being dead or not. 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.

rmsaksida 12y ago

I've had limited exposure to WPF, but I found it absolutely delightful. When you work with web development for so long, working on a desktop app feels very refreshing. The toolkit lets you focus (choice is hard); data binding is awesome; components are all readily available; there's rich IDE integration which mostly just works; you can easily offload almost everything from the backend; and with some good sense, you can drag & drop yourself to a reasonably good looking and usable interface in record time.

danbruc 12y ago

You can get quite far with the simple equation XAML + Control Library = WPF = Silverlight = Windows Phone UI = ... some of the runtimes are more powerful, some are less powerful, but they are really similar to develop with. I can see runtimes come and go but the way you build UIs on top of them does not look like going away soon. And - at least to me - this is a good thing, it is a great way to build UIs.

pjmlp 12y ago

WPF is only dead for those that cannot think out of the box. 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.

CmonDev 12y ago
What is the out-of-box solution for adorner decorators, then?

randunel 12y ago

I felt a similar betrayal that this author felt when Adobe started to drop support for Flash, stopping any development. Their claim of supporting every device with AIR went south not by dropping AIR support (which happened when they stopped Linux support), but by not developing the Flash platform as new devices and OSes poured into the markets. I have since successfully moved on, but I did feel weary for more than a year, unsure where I was heading. 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.