Live data from Hacker News

Is WPF dead: the present and future of WPF

pragmateek.com

71–80 of 85 posts

Re: Is WPF dead: the present and future of WPF

#71

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.

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.

Re: Is WPF dead: the present and future of WPF

#72

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…

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.

I know, it's just that wiring up the two is significantly easier for me right now than for the other languages. Well, it's mostly just a matter of not having had the time to build out a workflow in C# yet.

Re: Is WPF dead: the present and future of WPF

#73
post #21

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…

You're right, and this opinion is technology-agnostic. Textmate vs Sublime would be a good example, in that Textmate languished while Sublime flourished. Now Sublime has an uncertain present/future, Atom [1] and projects such as Lime [2] have appeared. This still doesn't negate the fact that the original Textmate is a perfectly serviceable editor, and neither Sublime nor Atom truly offer a new, compelling day-to-day feature which would make a developer want to switch.

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.

[1] https://atom.io/ [2] https://github.com/limetext/lime

Re: Is WPF dead: the present and future of WPF

#74
post #69

Earlier quoted context omitted.

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 ot…

With asp.net vNext able to run on Linux ( officially ), the question still remains: Why Windows => Why Microsoft? (apart from leeching their tech)

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.

Re: Is WPF dead: the present and future of WPF

#75
post #24
post #21

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…

> 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 comp…

* terrible WebBrowser control

Re: Is WPF dead: the present and future of WPF

#76
post #19

Earlier quoted context omitted.

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.

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.…

Winforms has data binding.

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.

Re: Is WPF dead: the present and future of WPF

#77
post #67

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.

What is the out-of-box solution for adorner decorators, then?

Re: Is WPF dead: the present and future of WPF

#78

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.

The Visual Studio 2020 might be completely in-browser unfortunately :(.

Re: Is WPF dead: the present and future of WPF

#79

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 to…

> 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.

Re: Is WPF dead: the present and future of WPF

#80

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…

Is that for server-client or fat client applications? For the latter, Java today offers the WebView class (part of JavaFX) that's simply an integrated Webkit browser. You can build your UI for HTML5 and easily hookup with the main Java program. I wrote a brief overview last year, along with other options for fat client HTML5 frontends: http://news.kynosarges.org/2013/12/29/webview-the-other-java...
Post reply on HN