Contents
Introduction
As a WPF developer for years I was recently concerned by the new direction chosen by Microsoft on its client platforms with the rise of the brand new WinRT framework.
I was concerned for good reasons: I’ve suffered from the collateral damages of the Silverlight failure, and as the proverb says “once bitten, twice shy”.
Since 2009 I have put a huge personal and professional investment in WPF, using it to develop LOB applications in the financial industry, and now I’m even providing training on this topic.
So as a professional developer and trainer the future of WPF is critical for me so I’ve studied this issue more thoroughly.
In this article I’ll share my findings with you, in a completely objective and transparent manner, and I hope you’ll provide your own facts, so that the community can have a better vision of the future of WPF.
In the last part of this article I provide some strategies for businesses and individual developers.
Some reasons to worry
First I’ll start by presenting the signs that are worrying me, and should worry you too if you are a WPF stakeholder.
WPF team’s blog is idle
As every Microsoft technical team the WPF development team owns a blog where the team’s members share their expertise on WPF with the community.
The last article of this blog is dated from may 2011 so more than 3 years ago, precisely when WinRT was starting to emerge as the next big thing.
An idle blog could mean a lot of things but IMHO nothing good: probably the team was reduced to the bare minimum and animating this blog is not a priority, maybe the best members of the team have been moved to other projects like WinRT, and maybe this is intentional to send a signal to the community…
In terms of public relations an active blog is essential because it shows the technology is evolving and is developed by enthusiast developers proud of their work and willing to share it with the community.
Note that often the MSDN blogs are not very active, the Entity Framework team’s blog being one of the exceptions, thanks to Rowan Miller who regularly publishes new posts, and this is one of the main reason I like this technology: it is being developed by brilliant and committed people.
The official WPF toolkit is idle
The WPF Toolkit is a free and open source project developped by the Microsoft team and designed as the anteroom of the official WPF releases.
As an example the DataGrid was not present in the initial release (WPF 3.0 and 3.5) but was available in the toolkit, and was finally added to WPF 4.0.
The official toolkit played this role till 2010, but since then the project is idle, so seems like there is no more stuff in stock for a next release.
Sign of this inactivity: for the “WPF Toolkit” search Google ranks the official WPF toolkit second after a non official one (more on this one in the second part).
No more certification
The official WPF certification (70-511) will not be continued and it will expire at summer 2015.
This is a strong explicit sign given to developers that they should not invest more time in this technology and instead devote their time to WinRT which benefits from new dedicated certification paths.
Maybe Microsoft will step back and postpone this removal like it did with other certifications after the developers community complained, but that won’t change the fact WPF is no more the priority.
Personally I’m still hesitating to pass it because I have no guarantee the time and money (yes as an entrepreneur I pay my certifications myself) are worth it.
Instead I prefer to prepare for the WinRT certifications which should be there for some years.
No Windows 8+ integration
If you remember the release of WPF 4, a large part of the enhancements were dedicated to Windows 7 integration like taskbar items customization (jump-lists, progress, overlay…).
There is no such things in WPF 4.5 to allow full integration to Windows 8+ features like the charm bar and the numerous application contracts though there is some interop capabilities.
So if Microsoft has not invested in this integration it clearly demonstrates that WPF is no more a first-class citizen in Windows and it prefers to dedicate all its workforce to WinRT, and I think this is a reasonable decision.
No support for Windows RT
Microsoft, historically a softwares vendor, is diversifying its business by becoming an hardware vendor, mimicking its competitors Apple and Samsung.
To this end Microsoft has acquired Nokia to benefit from its long time presence in the mobile phone market.
On the tablets and laptops side, to compete with iPad tablets and MacBook Pros laptops, Microsoft has launched the Surface series.
There were 2 versions of the Surface 1 and 2 depending on the hardware architecture: x86 and ARM, the later benefiting from a dedicated version of Windows: Windows RT (not to be confused with WinRT which is a software layer).
But Windows RT does not support (at least officially) the older APIs like the good old Win32, hence does not support all the “wrappers” like WinForms and … WPF, so you can’t run your WPF applications on all the Surface versions.
And if Microsoft did not invest in this it’s simply because it tries to get rid of Win32 to replace it with WinRT which is specially tailored for the new IT trends.
The new Microsoft’s strategy
In february 2014 Microsoft named a new CEO, Satya Nadella, who comes from the cloud division of Microsoft.
He is replacing Steve Ballmer, who did not understood the new mobile market (first iPhone and Android) and is probably one of the reasons Microsoft completely missed the boat and is now fighting hard to get a place taking market shares to competitors (Apple, Samsung) percent after percent.
Contrary to his predecessor Satya Nadella’s global strategy for Microsoft is “cloud first and mobile first“, so exit the traditional desktop model, and again this is a very sane strategy.
But precisely WPF was designed for the “old” model: fat desktop applications, whereas WinRT uses a totally different model, taking into account the new mobile needs.
Of course the desktop and PC market is not dead, far from it, but it is not the predominant model anymore.
And Microsoft has taken this into account when building WinRT because you can now use the whole HTML/CSS/JS stack, including frameworks like Angular and Knockout, to develop desktop applications; a strong sign confirming that web technologies are really becoming ubiquitous (after Node on the server).
The Windows Store
In order to capture a part of the applications vendors revenues most of the platforms’ owners like Apple and Microsoft have created “stores” you must use to publish and buy applications.
And unfortunately AFAIK the Windows Store applications must be based on WinRT, so your WPF applications can’t be deployed through the store.
Note that this is not an issue for businesses that deploy their applications internally and don’t need a store, nor for big applications vendors like ERP who use their own commercial channels to sell their applications, but this is an issue if you are a small vendor who need the visibility of the store, before a competitor eats your market shares.
More and more people are using the stores instinctively to search for new applications so there is almost no way around them.
So if you intend to develop your brand new application in WPF you will have a hard time distributing it and even harder if you intend to sell it, so you should instead use WinRT.
Mobility
You probably consume a big part of your daily content through your mobile phone using web or native applications so you understand how important it is nowadays to be present on this market: you must provide a mobile version of your applications.
WPF has never been a platform for mobile development and is not a player in this market, and for years the answer was Silverlight for Windows Phone and it was the reference toolkit up to Windows Phone 7.
But using one toolkit per platform was not ideal, even though you could share most of the procedural and markup code.
WinRT is an answer to this issue because it is a common toolkit designed to ease development on all the Windows platforms which are more and more unified at the OS level with Windows 8+.
Note that for a really cross-platform development that also targets Android et iOS Microsoft does not provide any tool, so you have to turn to Xamarin which is a really promising project.
Costs of maintenance
If you’ve worked with Microsoft technologies for years you know that Microsoft spends its money sparingly, and for good reasons: first, as a company, it must make money to survive and nowadays shareholders ask more, so a penny is a penny, second implementing even a small feature is costly because there is a lot of steps involved; Eric Lippert gives an overview in this blog post: How many Microsoft employees does it take to change a lightbulb?.
So when the community asks for a bug fix or a new feature, it is implemented only if it’s really a big one:
– either critical like security breaches, so even a few numbers of impacted users will trigger the implementation
– or minor but annoying a lot of people
Developing both WPF and WinRT would imply answering to both toolkits’ feature requests and fixing both toolkits’ bugs, this is clearly not an option, especially as Microsoft is currently reducing its workforce.
Portability
What could have “saved” WPF would be some niches, e.g. as a portable technology to develop client applications, but unfortunately this is not the case.
There is a portable version of .Net (to be pedantic, of the CLI): Mono, which runs on Windows of course but also on Linux, Unix and Mac.
And Mono is not a toy technology, it really works, with it I’ve myself already built a Jenkins integration server on Ubuntu Server.
Mono supports most of the .Net framework stack but one of the few missing parts is WPF; if I remember well there was a project named “Olive” to implement it but it was never really started due to the huge work it represents, especially at the low level rendering layers.
The only UI technology Mono has implemented is WinForms, so ironically WinForms could survive WPF thanks to its portability.
The Silverlight syndrome
I once was a Silverlight developer and I’ve discovered that technologies can vanish quicker than I once expected.
Back in 2008/2009: RIA is a buzz word, Microsoft is branding its own framework, Silverlight, in businesses managers see it in Microsoft events and want it in their IT ecosystem.
So in 2010 and first quarter of 2011 we started developing Silverlight applications.
But somewhere in 2011 at one of the technical events, concerning the web, Microsoft stopped putting Silverlight in the spotlight, and instead started promoting the HTML5 ecosystem (with CSS and JS).
Officially the story had not changed for Silverlight, but I was quite suspicious, reported it, and our team decided to stop Silverlight developments, which by the way had not delivered the expected benefits (e.g. Silverlight was not plug-and-play because you needed to be administrator to install the Silverlight player :/), to instead concentrate on “traditional” WPF.
Hopefully most (maybe 85%) of the XAML and C# code was shared with WPF, so not too much was really lost, and we stopped while we were not too much committed.
And this was the right choice because in 2013 the death of Silverlight was officially announced, and more than one IT stakeholder were surprised because they had not seen the forewarning signs.
I don’t think things will be that violent for WPF, but when you’ve lived such a disappointment you stop being naive and tend to become distrustful, which in my opinion is a quality in the current IT context.
Some reasons not to panic
After reading the first part you may be starting to freak out but as often things are not completely black, they are gray, a more or less dark gray.
This second part will help you mix the white with the black, so keep reading…
Still an active team
According to Greg Levenhagen (Is WPF Dead? – NO!) there is still an active development team dedicated to WPF.
Greg does not provide any hard numbers so it’s hard to measure the development effort.
While it’s obvious Microsoft wouldn’t abandon a technology used by millions of people, having dedicated developers, not merged in other teams, is a good thing.
And still according to Greg this team is not only dedicated to maintenance of existing versions but is also preparing at least a next release (WPF 5?).
Without having the change-log of this version it’s hard to be too optimistic: probably this will be only a bug-fixes and performance enhancement version without any major features.
Still a development effort [Update 2014-11]
In november 2014 the WPF team published an article, The Roadmap for WPF, showing that WPF was still actively developed.
The team is mainly working on important issues like performances, which have been continuously enhanced since the inception of WPF, and tooling fully integrated into Visual Studio.
Maybe the more important enhancement is the full support of touch and high-density display.
Why is it so significant ? Because these are features of devices like tablets and phones, and WPF was dropped in favor of WinRT precisely because the later has been specifically designed for such devices.
This may not be a complete u-turn from Microsoft in favor of WPF but it shows that Microsoft has heard and taken into account the claims of the community.
For more information check this nice video with two of the WPF developers: The Future of WPF on Channel 9.
New tools versions
I’ve noticed a positive sign on the official tooling side of things: Prism, a set of tools and best practices for developing XAML applications, has been updated to version 5 and along with the WinRT version it does provide a new version for WPF.
As said in the first part, the official WPF toolkit is idle but another project picked up the torch: the Extended WPF Toolkit.
It is being developed by a well known extensions’ vendor, Xceed, so by WPF experts (and other Windows technologies by the way), and it is very rich with a bunch of additional controls, and most importantly the project is actively developed, latest version being from june 2014, so less than 3 months ago as of this writing.
Finally the two top MVVM frameworks, MVVM Light Toolkit and Caliburn.Micro, are active, new versions are 3 months old.
So the WPF tools ecosystem is still living and evolving which is especially reassuring for businesses because they are not left with a bunch of unmaintained projects.
Change in management
At the end of 2012 Steven Sinofsky, at this time President of the Windows Division, left Microsoft.
Why would it be a positive sign for WPF? Because Steven Sinofsky was famed for being a .Net hater and not playing well with the other teams (maybe the primary reason of his departure).
And this would partially explain, along with some real technical reasons, why .Net was not used as the foundation block of the next Windows versions whereas it is one of the best piece of software ever made by Microsoft.
From the outside it’s hard to evaluate the part of gossip and the real feelings of Steven Sinofsky and their impact on the design decisions for Windows 8+.
The OS market inertia
Another good point for WPF is the fact businesses and individuals don’t migrate immediately to each brand new OS version, and for a lot of good reasons: it costs money, it takes some time, it’s risky, and often it’s simply useless.
Migrating to a new OS is a really daunting task due to the need of ensuring compatibility of the applications: those provided by an external vendor like Microsoft with Office and those developed by the internal teams, and from my experience it’s a process that can easily take 2 years.
Currently (mid-2014) the market shares of WinRT on the PC market are quite reduced:
– Windows 8 + 8.1 : ~15%
– Windows 7 : ~55%
– Windows Vista : ~5%
– Windows XP : ~25%
So for more than 80% of PCs you can’t use WinRT and have no other choice than WPF.
And in some context this is worst for Windows 8+: in the companies I know in the financial sector in France this is simply 0%, the migration to Windows 7 is not even completed everywhere, and I know some still running with Windows XP because setup of applications is not trivial.
Considering the renewal cycle is about 5 years WPF should be the unique choice for a lot of businesses till the end of the decades.
The ALM inertia
As you probably know retiring applications is costly: first you have preliminary studies with a bunch of meetings to assess the impact it will have on the business, and you have to work hard to convince some users who will sometimes put the “operational risk” joker on the table; then you have to replace them with brand new application and you must ensure there is no regression, often running both the old and new versions side by side during a certain period of time before completely switching; moreover you may have to call up your DB teams to migrate the data, the network teams to adapt the firewall rules…
It’s why businesses migrate applications only when there is a valid business reason, and a brand new technical layer is not one, so the existing WPF applications, and there is a bunch, are here to stay, and it means WPF skills will be needed in the foreseeable future, just have a look at the number of WinForms applications still in the wild, and new ones are being developed every day, whereas WPF is available to replace it since 2006.
And from a technical point of view, while WPF and WinRT are really similar, they are not fully compatible: there are still missing features in WinRT 8.1 and some quirks: to map a namespace to XAML you use clr-namespace in WPF and using in WinRT, this is enough to break XAML compatibility and discourage any flimsy will to jump!
WPF is mature
The obvious important decrease of the development effort for WPF can be worrying but IMHO it is only following a natural path every developer has experimented: a huge effort to develop the first release, then still a sustained effort for the following release that benefits from the feedback of the community, and finally a minimal effort to maintain the application.
This is exactly the path followed by WPF with a first versions (WPF 3.0 (for me was more of a beta version) and 3.5) bringing a new way of developing Windows applications, then WPF 4 introduced some new controls moved from the toolkit, like the DataGrid, and performance enhancements, and finally WPF 4.5 introduced the Ribbon and still some performance enhancements.
So the more mature a technology is the less development effort it needs, and after 8 years WPF is a really mature technology, so the needs for new features and bug fixes are reduced.
And probably WPF has now entered the maintenance phase of its life-cycle so don’t expect frenetic development of it.
The LOB niche
If there is a domain where WPF can survive and even continue to shine this is LOB (Line Of Business) applications.
First because most of the expertise to develop them is based on .Net which is a mature platform that a lot of companies running Windows use to develop their LOB applications and won’t throw away but instead leverage as much as they can.
And some central .Net tools are not yet available for WinRT, e.g. ORMs like NHibernate or Entity Framework, which are necessary to most LOB applications to access their relational data.
Second for some big LOB applications like trading platforms there is no benefit to use WinRT because you don’t need and even don’t want, for security reasons, mobility.
And this kind of big applications even go against the official guidelines of Microsoft for designing WinRT applications: they should be focused with a minimal set of data on the screen.
Windows Forms integration
For more than 10 years a lot of businesses have created many WinForms applications, and new applications are still being developed with WinForms, despite WPF being there for 8 years as its replacement.
Of course businesses don’t want to throw away all these applications, components and expertise just to use new toys, they want to leverage their investment as much as possible.
And AFAIK WinRT is not yet able to integrate WinForms components, so using WinRT is not an option if you want to profit from your WinForms investment.
On the contrary WPF has been designed from the start to allow integration of WinForms: using the WindowsFormsHost you can embed WinForms components inside your WPF applications.
And better, you can even integrate WPF components inside a WinForms application using the ElementHost, so that you can migrate slowly to WPF avoiding the big-bang effect.
The learning curve
If you are a seasoned WPF developer without knowing it you are probably already a WinRT developers at say 80%, and if you are a business you already have 80% of the expertise to develop WinRT applications in stock.
The reason is that most of the fundamentals tools for developing WPF applications are the same for WinRT:
– same procedural languages: C#, VB.Net…
– same markup language: XAML,
– same way to link view to data: data binding, DataTemplates…
– similar architecture of applications: global structuring, resources…
– same design patterns and implementations: MVVM, INotifyPropertyChanged, INotifyCollectionChanged, ICommand…
So most of your investment in other XAML platforms like WPF and Silverlight can be leveraged for WinRT, reducing the steepness of the learning curve (remember the one of WPF when you were a newbie? ;))
WPF is rich
WinRT is not a clone of WPF and some features are not yet implemented, so if you are only developing desktop applications from a technical capabilities point of view WPF is still better.
But I put it as the last one because IMHO it is not really significant, and as WinRT will continue its evolution the gap will become smaller and smaller, but I guess some developers with really specific needs won’t be able to develop with WinRT and will need WPF.
But again the added value of WinRT is not in its intrinsic technical richness but more in the development model it offers with access to mobile platforms and the Windows store.
Strategy for the future
Whether you are a business or an individual developer you should seriously consider slowing down your technical investment in WPF, and start to build your expertise on WinRT.
Businesses
As a business you can’t stop your WPF developments as long as you have some older versions of Windows, including Windows 7.
As for your existing applications, don’t worry, you don’t need to migrate them to WinRT, unless you want to benefit from its new capabilities as deployment through the Windows store.
Indeed Microsoft should ensure support for WPF for the foreseeable future; backward compatibility is something Microsoft takes really seriously.
As an example while it may be harder to setup VB6 environments in new versions of Windows it is still possible and, hence setup, your applications should continue to work seamlessly.
Depending on your available IT workforce, you should devote time to technology intelligence and have some developers starting to think about WinRT: how you could benefit from it, typically to broaden your audience, how new applications should be developed, how the existing tools and code can be reused, what are the potential issues to anticipate…
For the applications that could benefit from WinRT for mobile and tablet you can start building some migration path, which is not that obvious because WinRT is missing many features from WPF.
Start to develop proof-of-concept applications to validate the new technology in your particular context and see for yourself if it delivers.
Developers
As developers we don’t want to have technical skills nobody needs, and instead we generally must build a large enough portfolio of skills to accommodate the more businesses and projects we can to reduce the risk of being left behind.
So if you are an experienced WPF developer and you have to choose between extending your WPF skills to become an expert or starting to gain new skills for WinRT development then IMHO you should choose the second option.
Of course you’ll probably be able to do both like me, but WinRT should be somewhere on your TODO list but not your priority either.
Or you could continue in WPF waiting for the market to lack WPF developers, like is the case for older technologies like COBOL and VB6, but I fear you’ll have to wait a decade before it happens, because, with the important development of IT in businesses, for any technology there is a lot of developers on the market, particularly for mainstream technologies like WPF, so I wouldn’t count on it.
Don’t be demoralized or upset by this nth brand new technology, this is the business model of our industry: it needs to create new things all the time (remember SOA that poured a ton of money from businesses to the pockets of IT companies, their employees, their shareholders and contractors) to sell them to customers just as Apple does with its iPhone 1, 2, 3, … and now 6 and soon 42, this is how it works and fortunately we, as developers, are on the good side of the barrier, we can make a living from this entropy, and objectively all these new technologies enhance the life of businesses and individuals.
Conclusion
I think that the sum of all these facts is pretty clear: WPF is past and present, in the near future it will be in direct competition with WinRT, but later if WinRT gets some traction and enough market shares then WPF may become kind of deprecated like VB6 or WinForms.
Above all don’t be in denial, and have a clear picture of what happens, do not eliminate the pessimistic facts from your mind.
Do not expect a revival of WPF, there is no such thing in IT (well OK COM is kind of back in WinRT ;)), WPF is objectively not tailored for the new trends, the brand new stuff is.
Of course the picture is not all black: WPF is not dead and obsolete nor dying and obsolescent, it has just reached its peak and might slowly fade as the businesses migrate their infrastructure to Windows 8+ allowing them to choose WinRT for their future developments.
Be pragmatic and transparent: use WPF while it brings value to your clients and warn them about these facts, and help them prepare for the future.
I’ve myself updated my training material by interleaving WinRT chunks in my WPF training, and adding a slide with a summary of these facts, highlighting them depending on their significance.
But IMHO you should not invest too much in WinRT either.
Why? Because the more I play with WinRT and think about it the more I see it less and less useful:
- if you develop a LOB application, your only target is probably Windows PC, and you need to be compatible with pre Windows 8 systems, at least Windows 7, so WinRT is clearly not an option, and you must use WPF,
- if you want to target tablets and phones you can’t forget about 90% of the market, iOS and Android, so WinRT is not an option, and you must use either the web stack (JavaScript/HTML/CSS) or native cross-platform frameworks like Xamarin (C#) or QT (C++).
So for most use-cases WinRT is not an option.
Moreover you should note that Microsoft is heavily investing in the later technologies.
It’s probably too early to ask yourself “Is WinRT (as a final developer platform) dead ?” but I would be quite surprised if WinRT manages to get some traction and becomes a major development platform.
IMHO WinRT is only a good platform for the Microsoft teams because it allows them to share code between the different flavors of the Windows OS, mimicking the effort of Apple; but for the final developer the use-cases for WinRT are way too limited: sharing some code between PC, tablets and phones but only for Windows devices.
Probably some businesses may need only that but I doubt there is many because nowadays applications are often accessed from personal employees’ devices (BYOD) which can be anything and probably some iOS or Android.
Thanks for writing on this subject. You’re spot on. What Microsoft learned from VB6 depreciation was to not announce the end of software in public. So instead of officially depreciate any software they downsize the group of developers, release some maintenance version and perhaps some fixes and slowly abandon the software and move on.
Unlike in the past the life cycle for software have dramatically been shorter and it seems to continue to decrease.
For individual developers who put time, money and efforts to learn to use various development tools the situation is quite challenging. The only advice I see is to learn a new language/development platform enough to ship reliable customers’ solutions but don’t dig deeper.
Thanks,
Dennis
Thanks for your feedback Dennis. 🙂
Knowing multiple technologies without being an expert in each is indeed a sane strategy but I don’t think it’s the only one.
Mine is to become an expert in a few technologies that are widely used. Of course it is far from perfect: I am overqualified for some services, and sometimes I have to renounce to good opportunities because I feel too weak on some subject.
My hope is that the current web stack (HTML/CSS/JS) will become the universal platform and that somewhere in the future we’ll be able to concentrate on only this one.
Well I don’t think this will happen tomorrow. 😉
Too bad the current web stack is so unpleasant to work with.
It was true 3 years ago but now you have :
– mature frameworks like AngularJS + Bootstrap
– powerful IDEs like WebStorm and soon Visual Studio
– a lot of production-ready libraries
– testing and profiling tools integrated in IDEs or web browsers
So IMHO now you can be really productive and develop seamlessly using the web stack and benefit from its portability.
I can only agree with You. Looking around the web stack has the highest possible ROI.
Thanks,
Dennis
I’ld like to offer my 2p here…
Will WPF one day become as obsolete as VB6? Off course. Is WinRT any different? Or any other currently widespread technology?
Here’s the thing, ALL dev technology deprecates over time. WPF still has years of life ahead. Easily another decade.
I know you didn’t declare “wpf is dead!” (eventhough you kind of announce it for the not-so-distant future), but lot’s of people do. How many years ago did we see articles like this concerning WinForms? Is WinForms dead today? Most people indeed will go for WPF when doing a desktop app. Yet, WinForms still is pretty much a viable alternative and indeed is used a lot more then most people think.
The only msft tech today that is truelly abbandoned (concerning this family of languages) is VB6. And even that took a long time. Silverlight is somewhat of an exception here. And probably msft is to blame for that. They announced pretty boldly themselves that the tech was dead. Which is why it died so fast.
STILL, I am aware of new projects being developed today using the language.
All this, just to say that every time someone announces such a death, I take it with plenty of grains of salt.
Having said that, let’s look at the future of computing. No matter what the current hype is, the desktop really isn’t going to go away any time soon. In fact, the entire buzz about windows 9, is that it will give plenty of love to the traditional desktop user. In fact, we barely hear anything about 9 and hybrids or tablets or whatever. It’s all about the desktop.
WinRT apps will run in windows on the desktop, true. But let’s be serious here… WinRT still has a long, long way to go in order to match the power, flexibility and feature richness of a mature technology like WPF. Not to mention the freedom one has in WPF world compared to the closed sandbox that is the WinRT app.
While it is clear indeed that just about any and all effort these days at msft is going into the whole cloud/store/WinRT stuff, the fact of the matter is that today, there is no viable alternative to WPF if your app requires the power that it provides. And I don’t see that changing any time soon either. I also feel like the whole WinRT platform is still in some kind of R&D stage. It doesn’t feel mature at all.
So to sum up…. in terms of WPF becoming obsolete (which, again, is inevitable, just like it is inevitable that WinRT will become obsolete one day as well), .. I think that won’t be happening for at least another decade.
And to close off, as a developer, the worst thing you can do imo, is to put all your eggs in a single basket.
Thanks for your feedback DogmaHunter.
I agree on all your points 🙂
The STL, Win32 and Boost take issue with your position.
It was clear from the beginning that WPF was going to be another Microsoft failure. It was never really needed – probably a bunch of new intakes that wanted to try something new and replace other established and OK Windows runtimes, not because it was needed but because they could (or some may argue couldn’t!).
Company made the decision to stick with the old tried and tested GDI+, Runtimes and MFC if using C++ instead of c#.. Nice thing is we can also support other operating systems if not using totally Microsoft technology.
With Microsoft technology avoid being a first adopter, in fact often best not to adopt at all – Wait awhile and you will realize it was the right decision not to adopt!
Thanks for your sarcastic feedback. 🙂
I’ve worked in a team that progressively adopted WPF quite lately (2010), coming from all WinForms (and was still developing a new application with it in 2012).
And while the initial effort was important due to the richness of WPF, it finally paid.
One of the best benefit is how it has changed the way of building the UI: with WinForms I was the only one to never use the VS designer because it generates bunch of useless code and make versioning your files harder and sometimes simply a mess, but with WPF everybody started to write XAML code directly as it is quite instinctive and was less in panic when the VS designer crashed.
Moreover WPF came with some patterns and best practices like MVVM so every project has a similar aspect: I’ve seen a lot of projects from different companies and industries and they often look the same: put your views here, your VMs there, set your DC this way, bind this way…
Finally the easy customization was really useful: we didn’t do any fancy animations or stuff like that but needed some minor visual adjustments, with WinForms it was a pain in the a**, often overriding OnRender, whereas with WPF we could do them in a clean and quick way (yes traders are often impatient people ;))
I don’t say that what was true for this team would be true for all other teams, but WPF can be a really profitable investment for a development team. 🙂
Microsoft tech early adopters have the advantage of having a headstart compared to the late adopters. Plus, it is to both Microsoft and the community advantage for early adopters to help improve the tech. I would say Window Azure is a good example. Now, that has to be balance with the risk of Microsoft changing direction and abandoning the tech. A would say silverlight is an example.
Pingback: Is WPF dead: the present and future of WPF | Pr...
Excellent article. I’d go a step further and say that WinRT is NOT going to be a major player in the future. As much as I don’t like JavaScript I think it’s the future. Microsoft has spent too much time following the industry instead of leading it. 10 years from now Windows XX could be a thing of the past also. Looks to me like the browser is the future for LOB and not Windows. Even C# looks to be headed for the back-end just like C & C++. The only MS tool we are currently using for new projects is Visual Studio with the Nodejs beta plug-in (and it’s really nice). A few years ago we were 100% MS house. Cheers.
Thanks Charlie for sharing your perspectives. 🙂
The success of WinRT will greatly depend on the success of Microsoft in the mobiles and tablets market.
And yes concerning these markets Microsoft is following trends, initiated by the competition, it has no control on.
As for LOB I think we are at a turning point: JS client frameworks, like Angular, are now offering most of what desktop technologies can offer like data-binding so they effectively become credible alternatives.
But there is some limits like interop with the Office suite.
Moreover there is few developers knowing both LOB development and web development, these are two worlds that are just starting to meet, so we are years from a massive adoption of the web stack for LOB application development.
“Moreover there is few developers knowing both LOB development and web development, these are two worlds that are just starting to meet…”
Beautifully said. This is why I’m currently on the fence and am reading your articles – I don’t want to learn web technologies beyond ASP.Net and webservices for what I do. If that’s where things are headed, however, then it’s something I’m just going to have to do. Back to research, thanks all for this great topic!
Investing in the HTML/CSS/JS stack is a safe bet, it’s the only one I expect to be there and flourishing in the long term.
As of now native mobile technologies have a lot of success due to the limitations of the web stack but as the latter evolves I see no reason it wouldn’t replace native platforms and become universal.
Personally I think WinRT is so fully gimped it will be impossible to save. I’ve ported one of our WPF apps over to it and it was one of the most horrible experiences in recent memory. I really did feel like I was back in the 1990s doing COM programming in MFC… the fact that it used XAML was kinda irrelevant because they forced you to use their boiler plate generated code and heaven help you if you try to deviate from it. I tried to use an MVVM pattern and create my own ViewModel as I would in WPF and all kinds of horrible things happened because their navigation was partially unloading resources on me. The only way we finally got things to work was to go back with the unchanged generated code. MFC was the same way, lots of code generated for you, and you better FULLY understand the inner workings if you planned to do anything other than say “I believe” and take what they had. Long and short of it is that I hated every minute of my WinRT experience. If MS decides this is the future, then once WPF finally goes to pasture I’ll switch to JavaScript or something, but I doubt I will ever go into the horrible WinRT world ever again.
Thanks John for sharing this experience.
Indeed WinRT is not yet a mature and LOB ready platform, and you’ve paid the price for being an early adopter. :/
On the longer term your decision to switch to the web stack is the right one, and a lot of .Net/WPF developers I know are going this way too.
Because we all want and need a stable, rich and interoperable platform to develop our future applications, and neither WPF nor WinRT have all these qualities.
I know only 3 platforms that can pretend to be this universal platform: the web HTML/CSS/JS stack (the king IMHO), Xamarin (for .Net/C# developers) and Qt (for C++ developers).
Well it’s mid 2018 now and Charlie’s words resonate deeply. Microsoft Skype, Microsoft Teams, Microsoft’s VS Code and Atom are all developed in JavaScript/HTML/CSS via Electron. These apps are massive memory hogs but this is apparently leveraged by their multiplatform-ness. Nowadays, a title ‘Front-End Developer’ implies knowledge of JS/HTML5/CSS3 by default and all these front end developers who were limited to the web can now also develop desktop apps practically straight away thanks to Electron. I’ve seen a number of these apps and while they, including Skype and Teams are far from perfect they are on a pretty good path. WPF is still the standard for large scale corporate enterprise desktop but I believe this will change too.
Indeed these are more nails in WPF’s coffin. 🙂
All these applications were better when they was native. Maybe they just decided to save some money hiring some jQuery programmers?
Your statement: “While it’s obvious Microsoft wouldn’t abandon a technology used by millions of people, having dedicated developers, not merged in other teams, is a good thing.” already happened to VB6.
They killed VB6 used by untold more millions with no easy migration path. I will never use anything Microsoft for development. Not that I think VB6 is the pinnacle of languages, it gets the job done and quickly. The rewrite of working code would cost my company a lot of time to get back what I started with. Big negative ROI on that task so I cross my fingers that it keeps working every “service pack” and OS release.
When I am finally forced to rewrite there will 0% Microsoft content. Just updating PCs from XP to Win 7 requires a complete install of apps, tool chains and everything. If you are going to support something for the long run, MSFT is not your friend.
Thanks for your feedback Dave. 🙂
VB6 has never been completely abandoned by Microsoft which at least takes care of ensuring the old applications can still run on new Windows versions, though it’s true the setup can be difficult.
I completely understand your disenchantment concerning Microsoft technologies but IMHO this is true whatever the technology, the proprietary vendor or the open-source community: sometimes technologies don’t match the current people needs anymore so they fade replaced by better technologies.
Well at least for open-source technologies it’s true that stakeholders can maintain the product themselves without relying on the good will of another company.
I’ve never been a VB6 developer but from what I’ve seen and heard .Net is way better as a development platform, and C# is a better language than VB.
Yes, WPF is dead. I didn’t go down that path because there’s nothing really useful in WPF from a conventional line of business app development perspective. There’s nothing it does that benefits significantly over Winforms and the learning curve is steep and unnecessary. Silverlight I avoided also. Have you noticed how Microsoft does not have ANY RELEVANT UI strategy right now? HTML5 is not a strategy. It is a “following along behind everyone else” non-action and is a disastrous path that gives up any and all GUI and application leadership. They’ve deprecated the desktop also, which is quite stupid, and are busily running around in “me too!” circles.
When is this going to end????
Thanks for sharing your opinion Grant 🙂 but I disagree on the added value of WPF.
As a former WinForms developer I’ve found a lot of useful features in WPF like XAML, generalized data-binding support, templating, easier customization…
As for Microsoft strategy times are hard for them because they’ve missed the boat of web and mobile, the main invoked reasons is a poor management that didn’t understood what was happening just in front of their window (pun intended ;))
The question is more “how is this going to end”, because in an open environment like the current web ecosystem there is some competition so only the best will survive.
With .Net/C# it was easy to be the best when you are the creator and owner of the technology; only time will tell if there is still some innovation abilities inside Microsoft: if so they will take a big share of the web IDEs markets with Visual Studio.
I think that Microsoft has some savoir-faire in this domain it could leverage, but for sure in the web environment it will be the end of easy money with customers having no alternatives.
And it’s probably a good thing because when you are an annuitant you don’t need to innovate and let your customers with old tools, IE has started to evolve only when some competition was created with Firefox.
Wait and see…
A great post, thanks for taking the time to put it together. I am in the position at the moment of choosing technology for a range of LOB applications and have been having this discussion with myself.
WinRT seems desirable in many ways but is still so very embryonic. I can’t really see how it could support a true heavyweight application – yet – so I feel compelled to use WPF and it makes me a bit uncomfortable.
Great read though – food for thought.
Thanks for your kind feedback Marcus. 🙂
You are right, WinRT is not ready for prime-time in the LOB market, and this is not its current target.
As of now WinRT is relevant only if you want to reach the Windows mobile market.
So unless your applications are not too complicated or the mobile market is a prerequisite you probably should use WPF.
Knockout js , written by a microsoft person is what wpf could have been. Simple , useful, intuitive.
Compare the plumbing for a button command for example.
With WinRT you can now use the whole HTML/CSS/JS stack, including frameworks like Knockout, to develop desktop applications. 🙂
So it’s a sign web technologies are really ubiquitous (after Node on the server).
Why do you keep specifying “after Node on the server”? Sorry, little new to the web-side of things.
I mean that JS is everywhere: on the web client side of course, then with Node on the server side, and now with WinRT even on the desktop client side.
Coding for 15+ years. I never work in the same arena more than a year or two. That’s enough to keep fresh with each tech change. Hell, don’t even stay doing mobile, eCommerce or web advertising too long. Once you’ve used a dozen or so languages, everything becomes the same.
This is a way of working in the IT industry but not the only one, becoming an expert in a popular technology is another sane one.
And I agree practicing many languages and technologies is excellent to put things in perspective.
I was surprised to encounter this article tonight, because I would’ve sworn I’d read four or five years ago that WPF was discontinued-and-deprecated by Microsoft. Maybe I misremember.
Chris I think the only sensible hypothesis to explain this is that you are a time traveler. 🙂
Another vendor that we continually see WPF updates is Telerik..
Thanks for mentioning a third-party vendor Todd. 🙂
and DevExpress too.
Bonne analyse, le constat est bien vu. Sinofsky, dans son mépris pour tout ce qui est .net, a été le principal responsable des affres de WPF.
Je doute en revanche que WinRT soit la voie du futur pour les applis LOB. Les boîtes qui ont lourdement investi en dév MS se dirigent plus vers des applis asp.net MVC avec le plus possible de composants open source (micro-ORM pour les données, js framework pour le client)
Merci du feedback Henri.
Au vu de son évolution rapide il est difficile de vraiment anticiper ce que sera WinRT dans le futur, peut être deviendra t’il finalement dans quelques années une alternative crédible à WPF…
Quant au remplacement par des applications web, notamment ASP.Net MVC, je pense qu’on est encore loin d’un mouvement de masse, en grande partie parce que le savoir-faire web n’est pas le même, et si en plus on veut avoir une expérience riche il faut partir sur du RIA avec HTML/CSS/JS/Angular et là c’est encore plus spécifique.
Autant quand le développement est externalisé il “suffit” de demander d’autres profils pour changer de voie, autant pour les développements réalisés en interne il faut dépenser pour se mettre à niveau, notamment en formations.
Taking a step back and looking at the whole desktop picture, my feeling is that Microsoft has been slowing abandoning the desktop.
I sell COM add-ins for Excel, and when you’re an small ISV you strive to reach as wide a market as possible. I would analyze my log files and generate data on the market penetration levels of the NET framework versions for my visitors (extrapolated from IE users). It wasn’t until a few years ago that I felt comfortable moving beyond 2.0.
The varying availability of various .NET framework versions, the soft dropping of Winforms, the hard dropping of Silverlight, the questionable future of WPF, and the introduction WinRT all point to an inconsistent approach to providing desktop development tools that span the Windows versions seen out in the world.
The kicker, though, is when they dropped setup projects from Visual Studio 2012. Microsoft’s new strategy is mobile / cloud first. The desktop is an afterthought, which is sad because it’s one of Microsoft’s core strengths, and instead of playing to it, they are trying to be a market follower in the areas that other companies excel at.
Thanks for your feedback Nicholas, I completely agree with you.
Times will be harder for Microsoft: the model where it was king, desktop, is losing ground, and it understood the rise of the newcomer, mobile, too late. :/
But there is still some niches where Microsoft is king like spreadsheets with Excel.
I wonder if there is any chance one day you could deploy your addins through the Windows Store…
Nice succinct article, sums up the situation very well.
We’ve been developing a massive system in Silverlight for the last 3.5 years, had only just begun to commercialise the damn thing when Microsoft started killing poor wee Silverlight off, slowly and painfully, like dragging an outlaw through the desert using a turtle that has a benzo habit.
It has been an exercise in frustration for us – Silverlight is essentially the perfect platform for our system as it works in a browser, has very low cost of ownership and supports both cloud and internal deployment models on a very wide variety of operating systems. The sophistication of C# / XAML combined with extensive 3rd party libraries (Telerik, ComponentOne, Xceed, etc) has enabled us to develop an application with very complex features.
I’m also a web developer of 10+ years and have plenty of experience with the browser stack, and the thought of trying to rebuild this thing using JavaScript / CSS / HTML scares the living crap out of me. Yes, we have already prototyped using Angular / Kendo / LESS / TypeScript, and for me, the reality is that web development is just not good enough yet – the number of technologies that you need to be proficient with to achieve highly complex results is staggering, and even then we still can’t do everything we can do in Silverlight just with XAML and C#.
WinRT is just not an option – if we limited ourselves to Windows 8.1 market share in the enterprise, well, we might as well just turn the lights off, sell up and move to Bermuda. That’s before even looking at the capabilities of the platform itself.
We’ve looked at WPF as a mitigation strategy, simply because it would not be an enormous job to enable WPF compatibility, even though it is certainly not part of our long term strategy because we ultimately intend to be a cloud-based service provider and WPF simply doesn’t fit into this world. If Silverlight was no longer an option and we were struggling then WPF could at least help us out while we transitioned to other platforms.
So right now we are sticking to our guns on Silverlight for the next 4-5 years, and in the meantime we really have no choice but to start re-developing the client layer using a browser stack, with the view that it will take many years to gain traction due to the sheer size of the project, the limited resources we have, and the fact that we have to try and replicate all the features of the current system.
Xamarin is interesting, but not really on the table at the moment as we are not marketing to mobile or tablet-based audiences.
As a Microsoft developer, I’m extremely disappointed by the way Microsoft is handling its UI platform strategy – they have really dropped the baby on its face here. I’ve loved seeing the innovation coming out of .NET releases, and how the UI story has advanced so quickly, with the introduction of XAML and associated platforms. I felt like it was a real paradigm shift, onwards and upwards from the cesspool that was cross-browser web development.
Yes, web development has improved immeasurably over the last few years but it’s still just HTML, JavaScript and CSS at the end of the day, evolutionary, not revolutionary – there are basic flaws with these technologies that will never go away.
I know that as a developer I have to go where the industry goes, and I’m fine with that – at least I already know how to develop on browsers, so it’s not a huge leap for me personally to return to it, but I am so frustrated that a perfectly decent technology with a great ecosystem has been gutted, and there is no decent succession strategy in place. That’s life, and my snowflake has well and truly been pissed on.
Sorry for the rant, you can tell I need to vent. I’m sure you understand how I feel.
Thanks Sam for sharing your testimony.
I completely understand how you feel because I’ve lived a similar situation, but less critical because our Silverlight commitment was not as important as yours.
A lot of developers feel regularly betrayed by this kind of turnaround: one day you’re said that “this thing is the future, you MUST use it NOW” and the day after “this thing is the past, here is the new thing you MUST use NOW”.
Some find it ridiculous that Apple produces a new iPhone every year or so, whereas others are happy to buy them all.
The same for Microsoft technologies, some are frustrated by this entropy (especially software vendors like you), others are happy to adopt them all (especially cynics: “Coooool! A new thing I can sell to my customers to get more money from them!” ;)).
As for your particular technical situation have you considered using XBAP for deploying and running your WPF applications?
XBAP gives you the deployment experience of ClickOnce and the runtime experience of Silverlight in the browser’s sandbox.
The issue is that AFAIK it only runs in IE and FF, and of course only on Windows.
And I strongly believe that what you live is a blessing in disguise because web technologies is really what matters now, you find them everywhere (even on the server with Node and the desktop with WinRT).
Now you can reach a broader audience and the technical experience you get is applicable to far more use-cases than XAML, and this time you know the technology won’t disappear next year because the vendor has created yet another thing.
The only issue you’ve discovered yourself is that the web technologies are not yet ready for prime time on the LOB market, but I strongly believe that they will be in 2 or 3 years.
Be happy to be an early adopter of web technologies for LOB 😉
We’ve looked at XBAP / ClickOnce deployment for WPF, it’s on the table as a number of options for WPF adoption, but the most likely one we will go with (only if we have to) is to deploy the client as a desktop application via our existing MSI package, as that is what our current clients are used to, and we had some concerns about how easy it is to get XBAP applications running in enterprise environments (certificates, IE 9 permissions, etc).
Concerning XBAP you have reasonable concerns, but some quick tests should be enough to evaluate the impact, especially if you need higher permissions than what the sandbox allows by default.
Pingback: Is WPF dead: the present and future of WPF
– Moving from Silverlight to HTML/CSS/JS, sucks big time. It is much harder to style, and inconsistency across browsers is still a major issue.
– For complex LOB apps, WPF to “Metro”, is a joke, can’t have multiple windows open, cant use multiple screens
– WPF to web browser HTML/CSS/JS is impossible if you need to integrate into other systems via COM APIs
The CEO was so pissed with the death of Silverlight, that he has barred MS tech from the next stack and the primary browser is now Safari. The backed will be moving to Node or GO or ??? anything but Microsoft.
– true, Silverlight, as Flex, was excellent to quickly develop web LOB applications, but finally the HTML/CSS/JS strategy is better: slowly but surely it has crunched all the competitors, and is quietly evolving to be LOB capable.
– true, WinRT is far from ready for prime time on the LOB market, and I fear the day it will then the HTML/CSS/JS stack will be too, making WinRT a useless technology, or only useful for some specific Windows niches :/
– true, especially for Office COM addins that are great tools to extend VBA apps
I completely understand your CEO’s reaction, especially if the Silverlight failure has impacted his credibility towards business. :/
For the backend Node is great to have a uniform stack with client apps in HTML/CSS/JS/Angular but the issue is the ecosystem: when you work with these new technologies you realize how powerful is Visual Studio, and how it greatly impacts your productivity.
This is only a question of years before the web stack has enough power (especially IDE and libraries) to run big LOB applications…
WebStorm (especially version 9) is already there IMHO.
Pingback: Die Zukunft von WPF … Investition in WinRT ? | Build Successful - Michael Morbach's Blog
“Whether you are a business or an individual developer you should seriously consider slowing down your technical investment in WPF, and start to build your expertise on WinRT.”
No we wont.
If someone wants to make an investment, M$ is not the place to put it.
M$’s moves are a complete disaster lately.
Win8 was a step back (in UX, in quality, in application reliability), so was the WPF discontinuity.
And most (if not all) Metro/Phone new programming tools don’t even work on Win7.
So, you have to use the crappy, unproductive Win8. That’s not gonna happen.
Now, even in Win10 seems promising to fix some things, my long experience is that M$ never fixes anything that annoys me.
Thanks for your feedback.
Yes I agree with you; the situation of Microsoft is quite critical and “copy what the others do” is indeed not a viable strategy on the longer term.
I’ve recently changed my mind about WinRT because the more I learn and think about it the less optimistic I am about its future outside Microsoft.
Probably WinRT is great for Microsoft’s developers to increase the productivity of the different Windows teams by sharing a common platform.
But for final developers I see less and less use cases for WinRT: useless on the mobile market because it can’t target Android and iOS, useless on the desktop because WPF is richer, more mature and compatible with all the Windows OS from XP.
I’m personally slowing down my investment in WinRT and seriously thinking switching to web where I’m sure my investment will pay for at least a decade.
I have never liked WPF. It is one of most complex platform to localize. Because XAML is so flexible you can have very complex XAML that relate to several other files. If WPF is going to go away I am just happy.
How I see this there are two ways to make LOB applications. The first is plain old WIN32. However I do not use MS tool but Delphi. It is a superior tool to make LOB application. MS can not drop WIN API support from any upcoming Windows version (see what happened WinRT table without WIN API).
Second is HTML5/CSS/JS stack that will come better day by day. Most of the logic will anyway stay in servers and thin clients (desktop, browser or phone) all access them using REST. I have see some pretty impressive UI developed on HTML5/CSS/JS. When I create anything that use JS it actually use Visual Studio and TypeScript. It is a great language!
It won’t even take long that HTML5/CSS/JS will be so powerful that there is no need to platform specific API such as iOS, Android OS or WinRT.
Thanks for sharing your opinion Jaska.
Yes WPF is quite hard to localize because Microsoft has not provided any good tool to do this task but the community has come up with really good solutions including the use of the good old resx and the newer resource dictionaries.
For LOB applications I’ve developed with Win32, WinForms and WPF and IMHO there is no debate: WPF is by far the easiest platform to work with once you understand it well (3 months is enough to be highly productive).
As for the web stack taking more and more importance I completely agree, there is simply no other alternative if you want to target all the platforms.
In less than 5 years I strongly believe that this stack will become as productive as the native stack with the added benefit of being fully portable.
Using the other technologies won’t make a lot of sense in the general case, though of course a lot of specialized use-cases won’t be addressed by the web stack.
Great article, thanks. I also have worries like you since I’ve been developing in WPF for the past 4 years and haven’t seen much coming out of MS on the subject during this time. I was just reading an article the other day on a rumour that a future windows app store will support windows desktop apps. http://www.wpcentral.com/deleted-microsoft-blog-post-claims-windows-10-support-desktop-apps This might possibly give a bit more push internally within MS to update WPF, since it is after all still their recommended UI platform for desktop apps.
Thanks for your kind feedback. 🙂
I’ve heard of this rumor too and this is really bad news for WinRT because the use of Windows Store was one of the main added benefit of WinRT against WPF.
Without that WinRT is just becoming less interesting and almost pretty useless. :/
So strangely seems like WPF may have a better future than WinRT…
Pingback: Is WPF dead: the present and future of WPF | Boardmad…a road slightly less travelled
I think the future technologies are the JavaScript libraries like KendoUI or AngularJs. You can combine these technologies with MVC and build awesome apps, that you can then optimize for mobile devices (responsive web design…). The world of desktop client applications seems to be already dead, making place for web apps and mobile apps.
I agree with you that the web stack is the future.
But the world of native desktop development is far from dead, and it’s the same for native mobile development.
I think that less than 5 years should be enough for the web stack to become as productive and powerful as the native technologies.
But there is a lot of native applications to maintain and businesses tend to reuse their native skills for new applications.
Thanks for a great article!
I found the following framework really helpful for those of us who still use WPF but need to produce apps that seem at home in Windows 8. I thought I’d share it (I’m not affiliated):
http://mahapps.com/
It’s like the WPF toolkit, but for Windows 8. Very useful! Apps like Github for Windows have this kind of feel.
I think you’re right – WPF is just in it’s “middle age”. There’s still plenty of activity out there. For example, the Reactive UI Extensions have support for WPF. See http://spin.atomicobject.com/2013/08/22/reactive-extensions-wpf/ and others.
Thanks for the kind feedback Graham, and for referencing MahApps.
There is another similar toolkit: Modern UI for WPF
And yes WPF is still alive and as mentioned in other comments I’m not really confident in the future of WinRT whose main benefit is portability … but only on Windows. :/
I am kind of new to WPF… I think I like XAML for many things … its layout control, the capability to nest elements, and etc. Data binding the data template is really the strongest point of XAML. However, what I don’t like is the code syntax. XAML itself is not too bad … but the .NET C# code is horrendous. The class names are just too long, the concept is simply too abstract … e.g., DependencyProperty and its related declarations, all these stuff are just not intuitive. In comparison MFC becomes so much simpler. I have to say even someday I master these things in my heart I will still be a .NET hater.
If you are new to WPF take some time to more deeply understand it, because as you’ve experimented WPF can be quite frustrating at first.
Not because WPF is complex but because WPF is rich compared to older and rawer (closer to the OS) approaches like Win32, MFC and WinForms, where you had less concepts to grasp.
As for longer class names this is not specific to WPF or .Net, but is a general trend in programming: since we now have good development tools, like VS with IntelliSense, we can use explicit, hence longer, names because we will not have to type them entirely very often.
As for DependencyProperties I like the way it is implemented in WPF because there is not too much magic in there, things are relatively transparent, contrary to more abstract implementations of the same features like the Flex framework which uses a black-box approach.
And as a whole .Net is not perfect for sure, but to judge it fairly you have to try other platforms like native C++, Java and Web (including Node.js on the server), and suddenly .Net will appear as yet another unperfect platform that does the job pretty well, not better and not worst than others. 🙂
I agree with what you have said.Let us be optimistic that more people will learn WPF and adopt it for LOB application , especially with a mature set of controls and components provided by third party vendors, who have taken the cause upon them-self and produced some remarkable component , that if used in a proper manner can produce modern and better UI that would have taken normal teams years to develop.Vendors like Infragistics, Telerik , Intersoft ,Devcomponent , DevExpress have enterprise class WPF components.And not to mention Xceed with the best WPF Grid Engine that can actually scale.So you cannot say that WPF is dead.Its there and good for what it is , replacement of WinForm and a modern UI.Try doing those with any other frameworks available?. These along with properly architecture applications will surely excel.
Well there are performance trade offs using WPF of other things in some areas.(e.g https://jeremiahmorrill.wordpress.com/2011/02/14/a-critical-deep-dive-into-the-wpf-rendering-system/ ), well one only need to be concerned about this if you want to use it for graphical performance.In this area WPF needs catching up with GPU in some way or other if .NET subsystems where enhanced.There are teams that have taken things into their own hands and reaped the rewards , have a look at the works of ab4d or NoesisGUI.
The Start Menu is making a come back. But the death of Microsoft will not happen since Laptops at least will not be replaced for productivity reasons.PC may be proclaimed declined,but not dead.
Yes WPF is still king on the LOB market and that’s a good thing. 🙂
Thanks for sharing the article about the performance “issue”, but this kind of low level stuff is not relevant for most LOB applications even big.
In my previous team we’ve built a really big one and the only issue we had was with the DataGrid which was damn slow when it had to manage thousands of cells with data-binding and triggers.
Optimizing both these points gave us decent performance.
As for the future of Microsoft it won’t be bright but IT has such a huge inertia that I’m really confident for the next decade.
Moreover a lot of Microsoft’s customers are captive and won’t be able to use tools from competitors even if better and/or cheaper.
hi, firstly am not an expert programmer , I have just learn a vb.net and sql so I can play around with LOB applications as I do for almost 5 years.
can you please explain what is
‘The official WPF certification (70-511) will not be continued and it will expire at summer 2015.’
I was in windows forms and when I wanted to know whenever wpf is the future all the comments and post almost , they directing me to use wpf for new desktop application. so for 2 months now am trying to learn and play with wpf. believe me is hard when you learn something to try forget and learn something new. But to be honest I am afraid that change because when ever I hit google ‘is wpf dead’ some say will.. some say NO . I cannot move back and forward all the time.
is there any official statement or something about that technology ;
thank you very much for your post.
Glad this article was helpful to you Stelio.
As for the WPF certification, Microsoft will simply remove it from its offer so you won’t be able to become a certified WPF developer after summer 2015.
But if you get it before it expires this is still good.
Concerning new developments, if you only target Windows PC, which is almost always the case for LOB applications, then WPF is your best choice and with WinRT the story has not changed.
Maybe in the future WinRT will be a good LOB platform, and maybe businesses will all migrate to Windows 8+, but until both happen, at best in 5 years, you should continue to use WPF.
And in the long term you should stop using Microsoft client technologies because they are not mobile capable and instead use Xamarin if you want to leverage your .Net/C# knowledge and be native, or JS/HTML/CSS if you want to leverage your web skills.
On the server side the ASP.NET stack is quite good, so as long as it is supported you can use it.
What a great conversation. I have been prototyping a C# app using WinForms, and I know this is not the right path forward. While there is interest in porting to the web, the requirements are rather complex that I’m comfortable making the decision to focus on running on the desktop for now. But what I wasn’t entirely comfortable with was whether WPF would be a useful investment of my time and energy. Based on your article and subsequent comments, it seems like WPF, despite Microsoft’s lack of pushing the technology, is the best choice.
Glad this article has helped you take the right decision Brian. 🙂
I’m less and less confident in WinRT future, so I’m in standby mode waiting for communication from MS.
The web stack is clearly a safer investment for companies and developers in the long term.
But until it is plainly ready for LOB applications if your only target is Windows PC then WPF is indeed your best choice.
Nice summary of where we are today! For those that have spent serious amounts of time in different Microsoft technology stacks (MFC, Winforms, ASP, Silverlight, etc.) and compare these to WPF, you will have to agree that WPF is a productivity monster when you couple it with things like Caliburn.Micro and Telerik’s WPF control suite and a well tuned development environment with snippets and plugins tune for WPF development.
Complex applications that used to take a seasoned team of developers months to create can be made in under a month by a skilled solitary developer.
Sadly, Microsoft is trying to deprecate their own technology with a significant measure of success. When the enemy is also your friend, paranoia is what we’re left with.
Thanks for your feedback Mario.
Yes WPF is a highly productive platform but it must be earned as it is quite rich.
As for paranoia this is a quality for an IT professional because we must often take care of long term maintainability.
you should give your expert feedback @
https://blogs.msdn.com/b/dotnet/archive/2014/11/12/the-roadmap-for-wpf.aspx
Thanks for your suggestion.
I’ll update the article too.
Hi there,
I ve read enough comments and although an old XAML – bound – things lover with absolutely no fear for the future of. NET style apps, i am putting a smile on my face as i find my self at the time being working with, believe it or not … ASP.NET WebForms with a more mature view of things, giving my customers really really great results, really really fast (with some help of 4.5 and DevExpress 🙂 ). I even do MVVM with the FormView and ModelBinding and almost no state headaches. Of course i speak for the LOB part of the conversation.
Good luck to all.
Yes for sure on the long term the web world is a safer bet than the desktop world but IMHO we still have a decade of active desktop development with technologies like XAML. 🙂
Of course, but i mention it for the .NET goodies residing on the server that bring a good dev experience, rather for the innevidable html+js output that is just … hmm a necessity.
Still hard working humans behind the scenes 😉
Anyway i could not imagive what else could MS do to both support its products and also follow standards, but to gather best active tools and languages and try make them more “universal”. I think that at the end of the day what we don’t emprase so match is the market place requirement.
We ‘ll see soon.
MS is trying to become a standard technologies vendor by incorporating more web and FOSS capabilities inside Visual Studio.
I strongly believe in this effort because though MS is losing the technologies battle it is still really good in tooling (IMHO the best vendor of IDE).
But having good tools, even the best, is only a first step, and MS will have to gain the trust of the FOSS community which is not easy task because historically MS has always tried to kill FOSS initiatives and only when it lost the war it embraced FOSS.
Pingback: Lista ciekawych tematów na początek grudnia | Wiadomości o technologiach IT
I am the author of this Visual Studio Uservoice request:
https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/4249140-one-net-framework-for-one-microsoft
Perhaps I could suggest a few ideas for consideration.
The way in which Microsoft like any large company employs words to convey a brand for marketing purposes can sometimes obscure the underlying unity from a technical perspective.
Silverlight, WPF, WinRT and Xamarin Forms all use XAML with a high degree of compatibility and also a significant amount of divergence, yet no more divergence than can really be expected over the time period involved and for which developers are traditionally used to managing for other platforms.
The method by which the various changes came about was horribly communicated to the developer community due to internal Microsoft politics.
The largest single complaint about WPF has been various performance issues and the obvious technical solution would be to reduce the API to essentials, convert a lot of code to C++ and integrate it with the underlying operating system… And that is exactly what Microsoft did by taking the huge step of including XAML into the Windows API. The XAML API therefore became native to C++, C# (and VB) and Javascript. XAML has been made lean and fast and accessible to every type of Windows programmer. This was a huge leap forward that was completely lost in the negative publicity surrounding something as trivial as changing from a Start Menu to a Start Screen!
With Windows 10, this updated XAML will be able to run on the normal desktop inside a normal resizable Window and provide a fast modern interface across a range of Windows devices.
From an Enterprise LOB point of view, Windows 10 and XAML will be a great LOB deployment vehicle with all the security advantages of a sandboxed App environment.
For the huge installed base of Windows 7, the obvious solution is to make WPF as compatible as possible with WinRT through a layered architecture design, third party libraries and/or hopefully some sort of thoughtful design by the newly revived “WPF team.” (which as far as I can tell is an internal task force using the Windows API XAML team along with others which explains why the WPF blog remains silent since it is really a virtual team)
For IOS and Android, there is Xamarin Forms which is yet another variant of XAML.
For a LOB App to target every client, there is for the very first time a base of XAML across every possible target of Windows 7, Windows 8, Windows 10, Windows Phone 8, Windows Phone 10, XBox One, Android and IOS.
For sure you have a design and architecture task to achieve the maximum in common code but there is no other platform that can deliver a completely Native code App experience across all these devices that an Enterprise LOB might be expected to deploy to. Rather than being negative on the future of WPF, it is more accurate to be extremely positive on the future of XAML.
It is certainly possible to put some effort into complaining about the large number of XAML dialects causing some nasty #IFDEF in the code base, but compared to the current all-too-common practice of an Objective C codebase and a Android Java codebase and a Windows desktop C# Winforms or WPF codebase, the XAML solution is the right choice moving forward for a huge percentage of LOB deployments.
The alternative choice of Javascript/CSS/HTML for LOB will certainly appeal to some but comes with a different set of headaches.
The important point is that XAML is now part of the Windows API which will now be baked into the 1.3 billion desktop computers over the next few years and will be supported by Microsoft for many decades to come. That is as future proof as anything gets in this industry!
Thanks for sharing your thoughts Don, you make some really good points, and you get my 3 for your UserVoice suggestion. 🙂
But I fear unifying the Microsoft development platforms is a huge task that Microsoft won’t do because it’s cheaper to instead reuse what others have made like the web stack and sell tools to leverage it.
Moreover there is a timing issue.
The web technologies are more and more capable and nowadays with frameworks like AngularJS, production-ready libraries, IDEs like WebStorm, testing and profiling tools, you get a rich and productive experience.
So the productivity gap between native and web technologies is getting smaller and smaller every year.
So if Microsoft really engages in an effort to unify all these technologies it will take some years before it delivers and in the meantime the web stack will be as powerful as the result of this effort and will have other advantages like a better compatibility.
As for this figure of 1.3 billions of PCs this is huge indeed but is now only a part of the billions of devices like tablets, phones and watches.
So I feel Microsoft has surrendered and it’s why it’s now promoting the web stack since 2011, just before killing Silverlight.
My advice is: do not wait for Microsoft and instead you’d better get on the web train to ensure a successful future as a developer for your customers and you. 🙂
Hi there,
most of the LOB applications already exist and are mostly client side with DB in the local network.
Companies can then choose between:
– Stay on the client only.
In this case the choice must and can only be WPF, in fact in the release of WPF5 many improvements have been made to support the touch. No coincidence that Microsoft has deprecated practically Windows RT and in all new tablet runs version of Windows where can run standard applications (WPF). By doing all LOB applications, with some improvement graph, can run on windows tablet. But always remain client applications and so this is not a big advantage (only for BYOD). If companies were to think of cloud applications must re-develop from scratch applications, with server side and client side (web applications).
– Go to the cloud.
In this scenario, companies need to write from scratch the LOB application, and then give a new structure to the application. In this scenario obviously the only way forward is HTML5 / CSS3 / JS but I see a big problem: most of the LOB application uses the F1 / F12 buttons which are not practically usable in the browser. So how you can bring your LOB applications on the cloud? You can not tell the customer that if he wants to go to the cloud takes twice as long to make a bill since it must use the mouse instead of the keyboard, right?
Apart from that I see also a difficult migration step of LOB application from Winforms / WPF to HTML5; how I can make coexist in a WinForms application / WPF components HTML5 also working locally with the DB and perform operations on the disk?
Regards,
Stefano
Hi Stefano,
indeed migrating from desktop technologies like WinForms or WPF to the web stack is costly, partly because this is often an all or nothing process, contrary to migrating from WinForms to WPF which can be done component by component, view by view.
It must then be justified by a real competitive advantage like reaching more customers on the mobile platforms.
As for cloud, AFAIK, you can use it to deploy WinForms/WPF applications too using ClickOnce, though you won’t benefit from a wider audience, just an easier way to reach desktop customers.
It’s kinda funny the way people cling to their BS , even after being proven wrong,
RT is would be Dead except it was never alive, anyone who bought into that crap deserves what your getting. calling WPF or Dead isn’t going to improve anything.
look at the http://blogs.msdn.com/b/developer-tools/ and the WPF alternatives, RT,Ligthswitch,Silver Light are Dead , store apps lost there spot on the platforms menu, the Lightswichters are all teary eyed and getting silence. I just wonder if the are gonna get one last shot with the Universal app thing or not, when 85% can’t use, the some of the tiny army rabid Rtards will buy in, not enough to amount to anything, it’s all over but the ringing of hand and mashing of teeth, the modern best in breed webstacks can achieve at least as good and better in some cases,
as far as WPF goes, your so far off base it’s hard to express, it’s the only came in town when it comes to modern real world, mission critical applications and is a fundamental component much of the worlds newest infrastructure, and guess what, no one looking to the commentator bloggasphere for guidance, and guess what else, they don’t blog about the fact they are using WPF, the fantasy bubble created by the blathering of random self appointed pseudo experts is laughed at, it’s a different class of developers, aka professional software engineers not app devs, that doesn’t change the fact that WPF can also do a way better job on consumer apps as well.
I have one question for you might WPF expert, what would you say to the young developer who listened to the RT, and other future predictors said three years ago, who can’t find anyone looking for RT/Modern/Store/Universal experience, and yet lot of WPF jobs paying top dollar?, big on the smug all knowing response, can’t wait!!!
I agree with what you say Dave and it’s precisely my conclusion: keep up with WPF, avoid WinRT which is probably useless and instead bet on the web stack.
As for your question I would say: “Being an early adopter of any technology is always risky, especially when the technology comes from a vendor that has shown a clear lack of understanding of the new trends in the last few years and missed a lot of boats like smartphones.”.
The real deal with WPF is all the people doing it wrong, with all the blogging as they learned by the self-promotional “social network oriented app builder class” to the point where anti-patterns became the perceived best practices, MS poured fuel on the fire with their stupid separation of concerns non-sense,
Bring in the “Don” blend designer types that let them think they were actually providing a useful service, ignoring all the real developers who were saying that Blend and VS where generating mountains of useless XAML, the truth is blend is utterly useless, proper WPF is a terse handle written affair, it should make it easy to see the structure of the UI, everything except name, event and as little else as possible , with everything else include layout/size handled by Style=”{ ,which can even be reapplied at runtime. There is no more need of a designer with WPF than with bootstrap forms, if anything’s dead, it’s the designer role. They need to go back to flash or wherever they came from, I don’t care, they have no place in modern software engineering, and they can take the stupid “Modern” design language along with them, great Idea for 2005!, what’s going be the point of 11nm X86, to be fast and fluid move solid color rectangles around?, oh but just wait til , the New MegaDinoSnaps 8 core ARMs come out, we need MS to make tooling, after all we only know C# and that should be #1 everywhere, MS please buy Xamarin so I can make third class forms appletitos for android and iOS, I’m a one man startup and can’t afford to create separate solutions, I really want to be a Big Boy, please help, Don’t hold your breath Don, It will be entertaining seeing how many new suckers will buy into the sure to come Universal apps, I’m sure the Dons of the world be extremely excited yet again, proclaim all else dead and blog up a pathetic little pile of crap ,again, the great thing is this is it, last chance ,last face plant, there is no stopping WPF now,
There is no stopping WPF on X86 phone, the smart people know max reach html5/Canvas/bootstrap/React, max rich WPF, the sputtering of a few uninformed, like the
Blogger tim.A of the Register who tweeted some BS like WPF touch may never work, are writhing away,
I like seeing the Wolf Pack Foundation that tweets #WPF, it’s ironic, MS threw the WPF devs to the wolfs, now they have a wolf pack on their hands, and the promosocialstoremodern crowd are where milk bone adult onesies. Where are Barnes’s, Brown’s and all the other B’s?, Dead end roads, that’s where, don’t even think of coming back to WPF boys, we don’t need help picking colors or drawing UI, we can have the users pick their own colors and use VSM, thanks anyway, bubbye.
Separation of concerns is pretty useless in simple apps indeed but it can help in building bigger apps, at least to offer a common language for all WPF developers which enhances maintainability.
MS has given up on Blend as it did not succeed in selling it to designers, including it “freely” with MS now.
The future of WPF highly depends on MS investment in it: if MS decides to go all web then WPF will quickly disappear.
Yes MS should buy Xamarin and promote it as it is a great way of building native apps.
But in the long term, when the web stack will catch up, Xamarin will probably itself become kind of deprecated.
Xamarin ,? I quess you didn’t sense the sarcasm, that whole section was a joke!
I can do more with HTRML5/Canvas already, Xamarin is weak , hell even Chuck Pertshold admits it can’t do graphics for shit, along with admitting, her wrote the books on the fly and isn’t a graphics expert, but in perception land , he is worlds leading expert,
“Separation of concerns is pretty useless in simple apps indeed but it can help in building bigger apps, at least to offer a common language for all WPF developers which enhances maintainability.” I can’t make any sence of this statement,
“Separation of concerns” is a trainwreck, I know of a local .Net shop that where soo gullible that they hired a designer who I know for a fact had zero WPF experience. I hand to bite my tounge to stop from laughing in there faces when they ranted about how invaluable if was to have a real WPF designer on the job.
Blend is worse than useless and not at all how it’s done, I may give the appearance of accomplishing something, which I think is worse than doing nothing. Ms has made massive investments in vast array of things failed, yet where proclaimed as the future, the “”RT Big Bet” being the latest, they aren’t calling the shots, the adoption rate of WPF is Huge, where it matters, the endless speculation of what will be the next big thing, I really enjoy listening to all their xarerfans regurgitating back and forth, yet haven’t seen anything even descent, what a bunch of hot air, no xamarin apps in top 10,000 apps on any platform,
has about as bright a future as Windows Phone, Fanboy Hype even MS exec fanboys are just making noise, blog opinion commentators don’t buy MSDN subscriptions. it’s the developers call the shots , not MS, 25,000 xamrites is rounding error in the real world, where is even a competitive xararin app? anyone who needs more than toy level phone would go with somthing like
this.
http://www.alphasoftware.com/
multi palform from the guy who invented the spreadsheet and some other MIT heavy hitters, not warmed over freeware.
Concerning Xamarin, as for any technology, not only its inherent capabilities matter but also how it is perceived and promoted by the community.
And there is a lot of projects using it and a lot more coming, and I was really surprised by this success when talking with a key stakeholder (a service and software company).
Not sure it will get enough traction to last 5 more years, again it will highly depends on MS promoting it (even buying it) or ignoring it and promoting the web stack.
By a common language I mean you can more easily grasp any WPF app if the devs have made the effort to respect common patterns like MVVM: you directly know where to find things and don’t get lost too much in custom plumbing.
It makes a huge difference with big projects with a lots of developers and a lot of turnover.
SoC is good but as a lot of things it must be used wisely and a lot of noobs abuse it, uncoupling too much, making the result more complex instead of simpler. :/
I’m all for defining the View aka Presentation Layer in XAML, that in effect is what WPF is, I’m just saying the best practice is too keep not use tooling generated XAML in the Window View XAML, it’s make a unmanageable mess , I dont care if your talking 1 to 1000s of devs small or enterprise, Blend and the VS designer are a menace to good WPF, period.there is no designer role in good WPF. period. it anti-pattern only nooblets or designers don’t get it, MMVM is a good great pattern , but what I talking about is more fundamental principles. and what gives WPF the Edge with “inherent capabilities ” that are simple superior, and very very few a aware.
as far as Xamarin you can’t just ignore the lack of ” inherent capabilities”
the Web community is x1000 larger already has greater ” inherent capabilities”
Xamarin is may look like a nice bridge to the store app crowd, but it’s really like an extension on the Santa Monica peer, store app3rs are surely some of the most gullible wannabees on the planet and are sure to be happy with the ” inherent capabilities” so Miguel may make a few bucks, it’s a hype fest, do you really think metro crowd can build anything even half way descent, tick tack toe,
the fact you can’t point to anything but potential, when I already have kiss ass WPF on Win10 99$ quadcore, it looks absurdly pointless, doesn’t sound like you are gonna get suckered in,
cross platform frameworks are coming out of the wood work, it’s gonna be cutthroat. is is shocking how much hoopla their is over vaporware, I guess when a blogger can be MS VP anything seems possible just not very likely. you really can’t name a single good xamarin app, mee too, hmmmmmm.
I agree that XAML should be written by the developer and that the designer is only good at showing the result not creating the view.
Just to be accurate the view is not only XAML but XAML+code-behind.
The main point of using Xamarin is to reuse existing C#/.Net code base and to ease the migration to the world of mobile.
This is totally relevant for a lot of teams in many companies that have already deeply invested in .Net and C#, especially for developing WPF applications for their desktop needs.
But in the long term I think it’s better to invest in the web stack, reimplementing some parts in JS so that it can be run on any client.
” the view is not only XAML but XAML+code-behind.” is exactly right, its all the people who try to make it the whole application and then bitch about performance when they stall the dispatcher thread and worse, thats WPFs biggest issue, Ignorance, thankfully it’s only a problem for the ignorant and their victims who are the fools buy there less than useless BS. like have been saying WPF is DEAD for years, go silverlight, silverlight is dead go metro,we can’t call it metro,go RT,aRmTablet is flop,go Modern Store,
store is digital land fill,go universal, no universal on Win7,,WP is well review by some really creditable bloogers,go WP,WP is zombie rat hole, sound the trumpets, datdadadaaaaa, go Xamarin ….#$%$%$##$%#%$”.
whats Dead?, everything they said was the future!, including the stupid UX expert do nothing designer role.and there careers, meanwhile a WPF Dev one of the most in demand, so me anywhere in the world where they want store app experts,it’s an oxymoron anyway and a painful dead end for the foolish, some of which are going around posing as WPF experts because they try it back when it was in fashion, ignore the fact they fail at everything before and after because they are losers,
“I think that the sum of all these facts is pretty clear: WPF is past and present, in the near future it will be in direct competition with WinRT, but later if WinRT gets some traction and enough market shares then WPF may become kind of deprecated like VB6 or WinForms.
Above all don’t be in denial, and have a clear picture of what happens, do not eliminate the pessimistic facts from your mind.”
it would seem at this point,based on your conclusion, on Sep12, that your abilities as a future predictor leave a bit to be desired, I guess old habit are hard to break. I wonder what you would say to the hoop jumpers above, in say 3 three years, after they jump though the Xamarin hoop, then the Universal One Core Open source .net Core hoops, when they can’t get employment? or are they supposed to finance their fantasy freeware empire, that will one day monetize into their long term goal of world domination.
you miss way to many points to pull off WPF expert , you’ve mentioned Xamarin to many times to be considered for junior cub status so I’m afraid we don’t have a spot for you in the wolf pack, my favorite user voice is the own where they want to change the name of WPF to silverlight, cause they told everyone WPF is DEAD, I can’t wait to see twait banes next WPF was dead, this time we nail the lid! and dig a deeper whole. good luck on your Xapp, oooohh , that’s catchy!
and good luck on your socialpromodeving.why is p ball pete when you need him?
The conclusion has been updated to reflect the latest news:
– MS has restarted to “promote” WPF in november,
– WP market shares are still weak and even diminishing.
As a result I’ve changed my perspective on WinRT from slightly optimistic to deeply pessimistic.
As for the people that have invested in these platforms they can reuse 90% of what they have learned: the procedural language is the same (C#), the UI language is the same (XAML), the patterns are the same (MVVM).
And again it’s not the inherent quality of a technology that makes its success and adoption by end users like big companies (SOA is the best example of the gap between added value and “success”); so a lot of these people are working on WinRT projects and for the other (most?) they are better WPF developers.
Others have even made some money by developing apps for the Windows Store.
Pingback: Binding WPF Textblock to two properties using Multibinding
Pingback: Is WPF dead: the present and future of WPF - Eat Sleep Code Repeat
I think projects like NW.js (https://github.com/nwjs/nw.js) make the web stack viable for LOB *today*.
“NW.js is an app runtime based on Chromium and node.js. You can write native apps in HTML and JavaScript with NW.js. It also lets you call Node.js modules directly from the DOM and enables a new way of writing native applications with all Web technologies.”
Thanks for sharing Andrew.
Indeed the web stack is seriously threatening “standard” technologies even in the LOB market.
But from my own (limited) experience the development/debugging/testing experience is not as streamlined as with .Net/C#/WPF.
Of course it’s only a question of time before tooling becomes as good and even better.
Finally will remain some more specific LOB niches (yes a niche in a niche :)) like Excel addins which are heavily used in finance for example.
As a former .NET developer and current iOS hobby dev I am astonished how well Apple improved and supported its own legacy technology Objective-C and the NextStep classes. Now you have a modern language (swift) and a super effective native UI runtime in iOS. Almost all legacy problems of the past, like reference counting and a somewhat obscure Objective-C syntax are solved.
This is totally in contrast with the Microsoft Strategy to reinvent a UI Technology every 2-3 years.
If Microsoft had chosen the Apple way, C++ and MFC or maybe COM would be evolved into an highly effective platform agnostic technology stack.
Thanks for sharing your thoughts André.
I don’t know the iOS development stack so I won’t compare.
I think you’re a bit harsh with Microsoft 🙂
As for the timing: WinForms has appeared in 2002, WPF in 2006 and WinRT in 2012, so you can double your numbers: a new UI technology every 4-6 years.
But the important point is that each one has appeared for “good” reasons:
– WinForms because .Net needed a UI development stack above Win32 to make it more appealing for native developers,
– WPF because it introduced a cleaner, and sometimes more productive, way to develop UIs,
– WinRT because the new Windows needed a refresh of the internal UI layer
Of course there had also internal political issues with members of the Windows team willing to kill .Net, hence promoting other technologies like native C++ and COM for WinRT.
So it’s pretty sure Microsoft could have done better but I’m not sure Apple has done better with its stack: if Microsoft had not developed WPF and WinRT UI then we would have stability but a less powerful and productive stack. 🙂
Apple has done much better. Since you obviously don’t do much (any?) OS X development and don’t really seem to be following things there, you’re out of the loop on it.
A big issue with Windows Forms was bad Graphics Acceleration. It’s one of the things that WPF was supposed to solve. Apple didn’t need to redo their entire UI Technology to add that to Macs. They just made the necessary changes, and developers didn’t have to learn XAML or whatever to reap the benefits. Apple even had mechanics to translate OpenGL calls to subroutines so that their graphics acceleration worked on Intel GMA cards for a performance boost.
Apple takes a much cleaner approach to improving their platform from that perspective, and this is part of the reason why so many startups and entrepreneurs are now targeting OS X and completely ignoring Windows as a client platform.
Windows will always be king for LoB because of its Enterprise Marketshare, but it is already starting to look like a dead end to people developing consumer GUI applications, and a royal PITA because Microsoft is constantly developing, ignoring, dropping, deprecating, and even just failing completely with various technologies.
GUI isn’t the only area where Microsoft had reinvented the wheel multiple times. Look at their Embedded Database Solutions over the years. In and out, multiple times. They’ve had multiple development language in and out, multiple times.
For native development, Microsoft should have developed tooling and frameworks similar to Borland’s VCL (Delphi/C++Builder), but they went all in with .NET.
I switched form Windows to OS X development. Users email me somewhat regularly asking me if I’m going to port to Windows. The answer is no. There is 0% chance because I don’t trust Microsoft. They way they handle their tooling is too selfish these days, and way too political. It’s a virtual minefield and I got tired of spending more time learning than actually doing stuff.
Apple is paradise compared to that B.S.
Thanks for your feedback and perspectives.
It’s true I have never worked with iOS so I won’t be able to compare.
1) Graphics acceleration is only one of the driver for the creation of WPF: WinForms + direct acceleration would not have added a lot of value, for me XAML added much more,
2) Desktop development is not the future, web development is already a big part of present and I expect most of the applications to be web-based in the future (even if running in a desktop mode), and this is not specific to the MS stack,
3) As for the lake of consistency and long term vision at MS I completely agree, during years MS was not an innovative company, lazily exploiting its dominant position on the OS and office softwares markets, which IMHO could explain a part of the the constant changes in strategy and technologies, and sometimes the absence of changes like with I.E.,
4) Native development has indeed been laid aside for .Net but this has changed recently and AFAIK MS is now offering decent tooling for it,
5) If you and other startups/companies can develop applications without caring about Windows, Linux and Android users this is fine, but most of companies need these market shares so they can’t restrict them to iOS even if the development tools are as amazing as you say: they must at best use the web stack to reach all the potential customers.
Pingback: A changing technology | Spectral Core Blog
Pingback: WPF vs WinForms Reconsidered | SashaDu on Software Development
Pingback: WPF - .NET & Visual Studio | Pearltrees
Pingback: Choice of GUI (WPF) | Gekko Timeseries and Modeling Software
At the end of 2015 I made the decision to cease any new developments with WPF. It’s fairly obvious that Microsoft has stopped investing in WPF given there are now only 2 developers left on the “WPF team”.
WinRT on Win 8.0/8.1 was a bust for me. When you spend 2x or 3x more time doing the same thing with the shiny new thing, it’s time to move to the sidelines and wait. I started tinkering with UWP at the end of 2015 and immediately noticed that some tasks were getting done 2x faster with the remainder starting to be on par with where I was at with WPF. Performance is much better/smoother.
The samples provided for UWP are now several orders of magnitude beyond what Microsoft initially provided for WPF when it was the shiny new thing.
There’s a lot to like in UWP. No more MSI drama with AppX, a real super duper browser control, access to DirectX, native code that is brutally difficult to reverse engineer, significant performance boost, much better audio/video support with transcoding made trivially easy, …, native bindings, updated cooler versions of things like tab controls, list/listviews, desktop/tablet/phone/game console/iot with the same binary… , it’s a pretty long list.
There are still a few rather deep pot holes, no DataGrid, no TreeView, nascent third party tooling, etc.
Nonetheless, I was surprised to see a couple recent projects wiz through very quickly thanks to old standbys like Caliburn.Micro working nicely with the new tooling and surprises with how well some of the new controls worked for visualizing good old db tables.
It’s become a no-brainer, time to switch, before others are woken up by the bright lights.
Thanks for your interesting feedback.
I’m not sure UWP has a great interest outside of the world of LOB applications.
IMHO as of now the best bet are truly universal (Android/Linux, iOS/Mac OS and Windows) web applications developed with HTML/CSS and a JS framework like Angular.
As for LOB applications the existing technologies (WinForms and WPF) do a perfect job and are mature with a wealth of tooling.
So I don’t see the point in yet another Windows UI technology and I’m pretty sure this new stuff will suffer the same fate as WinForms, WPF, Silverlight and WinRT.
Time will say…
I share your good experiences with UWP. It kind of finishes a lot of things appearing half-baked in WPF. The performance is much better. At lot of repeating boilerplate code is not needed anymore.
But currently, there is one big deal-breaker with UWP for LOB: I does not run in Windows 7. You even cant develop for UWP on Windows 7, because you can only build, but not debug.
So not only we can’t switch to UWP because all our customers are running Windows 7 and dont even have plans to upgrade, we also can’t take some spare time to investigate the possibilities of UWP for potential future applications. Because our Company also runs Windows 7, and most of us know what it means to get a Windows 10 workstation for a developer in an IT environment where only Windows 7 “is supported”.
I can see why MSFT is trying to push customer towards Windows 10 by adding artificial barriers for current technologies. But not supporting UWP on Windows 7 was a stupid decision, regarding the market shares. Especially for LOB customers.
And worst of all, it needs a message to LOB developers and their customers: “We don’t care about your needs anymore, we are cool know and your stuff is boring”. They are harming the only market where MSFT is still successful. Let’s face it: If there is one thing MSFT can’t do, than it’s being cool.
The lame attempts to look cool by putting hipster-looking guys on to the presentation stages is just embarrassing. My late-teenage kids (15 – 19 yo) are just plane laughing at MSFTs lame attempts to be cool for them. The say MSFT adds are looking like “old people tried to do something looking cool to young peoples and miserable failed.”
Hi Joerg,
thanks for your feedback.
Probably Microsoft has decided not to support Windows 7 for development cost reason.
Seems like “the cheaper the better” is the motto of Microsoft management. :-/
Microsoft is trying to save what it can still save, everyday many developers and software companies switch to the profitable market of the mobile platforms, and drop completely the Microsoft’s technologies. Because Microsoft has lost the mobile war, the only way to keep the developers using its technologies is to make them cross-platform, but to do that it has to drop everything that is Windows specific.
.Net Core 1.0 is the last resort of Microsoft to keep as many developers as possible, you don’t need to be a clairvoyant to see the end of the desktop era. It is enough to take a look to the market share of desktops and mobiles, the former are dropping and the latter are gaining. The buzz of these years is IoT, and desktop aren’t in that category. If Microsoft don’t want to end with a niche market, which is slowing dying, has to find a new way to survive, which is not Windows.
Sad but true Microsoft is running behind all the new trends and technologies, but it arrives always when it is too late. Look at the new Windows 2016, what is the best new feature? Containers, which are available for unix since many years. Microsoft was late in everything, it was late on mobile, it was late on cloud, it was late on NoSQL, it was late in BigData. Raise an hand who is using Bing, the same for the new super assistant Cortana.
Microsoft is building its last ship: .Net Core 1.0, there is the safest place to be, if you want to stay on the Microsoft’s ship.
Indeed Microsoft has missed a lot of boats since 10 years.
But as technologies are tending to stabilize Microsoft has the opportunity to catch up.
As for desktop, in professional context it is well alive. 🙂
And indeed the web is the best bet for some years now.
Hi,
Was interesting read this article, and especially all comments. now its January 2018, what would all of you recommend to go for when it comes to desktop applications and windows? Seems like all Microsoft technologies are pronounced “dead” now 🙂
Hi Bjorn,
if you still target Windows 7 which is likely if you develop for big companies then you could stick with WPF.
But today I would highly recommend to go for the web stack and wrap it in a desktop container like Electron.js.
This way you can more easily reuse your code and components to target other platforms like browsers and mobiles.
And while 90% of web frameworks seems alike there are some nuggets like React.js who uses an innovative and pragmatic approach.
If you have the opportunity try it. 🙂
I just want to say that HTML, CSS, JavaScript were created for text but not applications & it’s awful to create something that mimics traditional applications & it’s true even now in 2020. I hope that they will stay in WWW.
Indeed, but now with web components the lines are almost completely blurred.
I just want to say thank you for this beautiful article it really cleared a lot of points for me and helped me to decide my next move as a beginner.
Its 2020 and WPF is still here and i think its one of the best ways to learn about MVVM along with XAML,Data binding and desktop development in general and even mobile development (Xamarin).
although it has low demand rate i don’t regret learning WPF and no one should be.
Glad this article was helpful to you. 🙂
Indeed WPF is still alive and also a good technology to know if you want to stand out on the jobs market.