Deep Dive into .NET Universal Windows App Development
channel9.msdn.com
channel9.msdn.com
Java guy here. I've had some limited professional exposure to ASP.NET web apps over the past five years, but have really taken an interest in diving into the Microsoft stack over the past year or two since all of the cross-platform activity started happening. I'm mostly interested in ASP.NET, as I do little to no development in the desktop or native mobile app space, but I've been interested in at least learning more about those areas.
My understanding has been the following:
[1] WinForms is a very ancient framework for writing traditional desktop applications. It inspired ASP.NET's WebForms, an ancient framework for writing web apps. Both are still used by greybeards, but are effectively considered deprecated legacy tech.
[2] WPF is the current standard for writing traditional desktop applications. It uses XAML markup files to describe a GUI, with each XAML file being backed by a C# class storing the event-handling logic.
[3] "Metro" and "Windows 10 Universal" are emerging frameworks. Trying to achieve some level of convergence between desktop and mobile app development. Pushed hard by Microsoft, but no one cares because there are few users of the Windows Store or Windows Phones.
I am accustomed to seeing "WinForms is dead" Internet discussions, with people chiming in to point out that it still lives on in many shops. However, I've never seen a "WPF is dead" thread before.
Are you guys saying this because you're moving on to "Metro / Windows 10 Universal" even for desktop application development? I don't know anyone going in that direction yet, but then again Hacker News is a bit of a startup niche that poorly represents the technology industry as a whole.
DISCLAIMER I haven't actually watched this video yet... it's almost an hour long, and I'll have to do so later. A "TL;DR" would be cool, but I'm assuming that the gist is XAML still having a role within these newer frameworks that I haven't explored yet.
The have also extended the HTML and JS app model where any website can basically declare the capabilities they want to use and be published as an app in the store. They give you some boilerplate to detect that you are running in an app host so that you know when you can call system features like the camera or whatever.
It's literally never been easier to write a windows app...
Especially among MS developers, there are many people who don't read read HN or any other tech industry site. They rely or depend on MS to provide them with career advancing technical advice, but for the last eight years they have been consistently let down. Microsoft's preferred flavor changes every two years; Win Forms, SilverLight, WPF, Html5, now Universal Windows Apps. Add Metro-flavors of some of these.
This isn't working, at least for Business Users. Customers are switching from their Native Windows apps (often Win Forms, rarely WPF) to HTML, iOS and Android. Businesses will not build another Windows platform Native app; although some consumer apps might be written.
Developers are seeing their hard-learned technology go down the drain. That was time they could have learnt something new or spent with family. Developers who are in IT/Software for just the job/money find in relatively difficult to just go and learn the web. Many of them could have done it 10 years back (when they were younger), they can't do that so easily now. The last time MS' advice helped was when they had an iron hold on the industry (aka the Monopoly).
Here's some advice for MS: Build on HTML, perhaps partner with Mozilla. See if you can get it to work as fluidly as Native. They still have perhaps the most formidable research team out there among Software Companies. Closed, Windows Native apps are over.
> don't read read HN or any other tech industry site. They
> rely or depend on MS to provide them with career advancing
> technical advice, but for the last eight years they have been
> consistently let down. Microsoft's preferred flavor changes
> every two years...
Ahh... thanks, this makes sense. Things are somewhat similar on the Java side with Oracle, but not quite. In my opinion, the biggest contributing factor to the strength of Java's ecosystem is that the community has a healthy level of distrust toward Oracle.
Oracle promotes new things all the time. Sometimes they catch on and get widely adopted. Sometimes the community by and large completely ignores them, and uses another third-party framework instead (e.g. Spring). Oracle is begrudgingly respected, but I wouldn't say that their word rises to the level of "default" in the Java community.
Microsoft guys seem to have much tighter bond with the mothership, and put a great deal more trust in Redmond's agenda. They are much less likely to explore alternatives that come from outside of Microsoft (e.g. I see a lot small microservices for which Nancy makes a lot of sense, but which are still built on ASP.NET "just because"). This causes the wider ecosystem of alternatives to be much weaker than that of Java and other common stacks.
I'm very excited about the future, as C# is a much better language than Java, and Microsoft is at least saying all the right things lately about wanting to see more innovation from the community and less blind reliance on Microsoft. It will be interesting to see whether Microsoft can attract enough newcomers like me to offset the alienated longstanding crowd.
Unfortunately, the word "dead" causes people to talk right past each other because it has 2 meanings. More on that later.
First, there has been lots of discussion around "WPF is dead" since that soundbite was made popular by former Microsoft PM Scott Barnes back in September 2010[1]. Predictably, Microsoft denied it with typical business-speak (e.g. "we're still committed to WPF, yada yada") but Scott did call its demise correctly. You see, you have to understand Microsoft's (and most companies') modus operandi to notice how something actually "dies". They don't "kill it" by lighting up a neon sign and issuing A Big Press Release exclaiming, "We just killed WPF and you will thanks us later!" The way companies kill products is to not give it first class attention such as adding new cutting edge enhancements and diverting resources away from it. It's very rare for a company to plainly state that they will abandon a technology. (Adobe publicly stating they will prioritize HTML5 over Flash would be a rare example.)
As for the word "dead" in technology discussions, it has 2 meanings:
#1 "dead" -- as in no longer the preferred, preeminent, first class technology; publishers no longer release new books about it; it is not updated for the latest operating systems or hardware platforms (e.g. iPhones, etc).
#2 "dead" -- as in formal official definitive statement from vendor that it is abandoned, not supported, and nobody anywhere uses it anymore.
Almost always, when people proclaim "X is dead", they're talking about definition #1, and the people who argue against it are talking about definition #2.
If someone says "Latin is dead", they're talking about definition #1. It means that today, Hollywood movies will have actors speaking in English, not Latin. The latest Stephen King novel will be English not Latin. We're not using Latin to type out comments on HN. Latin has been "dead" for several hundred years.
The detractors countering with "Latin is not dead" are using definition #2 and will say they just saw a blog post exclaiming "carpe diem!" and a mathematics proof concluding with Latin phrase "QED". High school and colleges still offer classes to teach Latin.
That's the ongoing sorry state of discussions around the word "dead". The 2 camps just talk past each other and perpetuates the endless cycle of disagreements.
In any case, just like Latin is "dead and also not dead", "WPF is dead and not dead" depending on what the context is.
I personally still use WPF for all my development given its richer API. I'm not a big fan of XAML, but WPF has a good basic API for putting stuff on the screen and handling input in C# (disclosure: MS employee, but research).
Only those not able to grasp that what matters is the XAML stack, not the little layer that is put on top of it.
I really wish JavaFX Script would have taken off. It provided a nice balance between code and markup.
I just tend to abbreviate to XAML when speaking about it.
There changes on the APIs between WPF, WinRT and Silverlight if you will, and not all features are exposed across all stacks.
Yet, any developer knowing XAML, the usual programming idioms and the respective .NET APIs can easily transition among all of them.
This has been mentioned at multiple PDC and BUILD conferences in the last years, but I guess many at HN and Reddit don't follow them.
Plenty of Microsoft haters on HN, this post has already been flagged or flamed off the front page. Oh well.
Parts of it eventually became what is known as WPF. The whole set of concepts that it embraces are as follows:
- XML based "language" for describing UI layouts (XAML)
- A set of .NET APIs for buttons, dialogs, windows, and so on
- A set of .NET APIs for manipulating the XAML DOM
- A set of .NET APIs for handling application resources
- A set of abstraction concepts, namely binding, data templates, triggers, MVVM, storyboards
When Silverlight came out, the team responsible for it adapted all these concepts to the platform. Similarly to the WinRT platform.
The main differences are the XML namespaces used by XAML, which expose different set of UI widgets in each platform.
Also some .NET APIs are a bit different as the classes aren't 100% equal across all platforms, e.g. TypeConverters are not available in WinRT.
However those basic concepts originally from Avalon are still there.
Do you actually think that HTML, CSS and Javascript are good technologies to build applications on top of compared to something like Silverlight, which is purpose-built for the task?
"Do you actually think that HTML, CSS and Javascript are good technologies to build applications on top" Are you serious? I am not saying "the web" is perfect, but this just nonsense.
Unfortunately, the XAML everywhere people lost at Microsoft, so we're stuck with half-baked, kludgy and limited solutions like atom/electron/node-webkit for building cross platform desktop apps. XAML everywhere (Silverlight) is so much more precise and it's compiled. I would have preferred that they continued developing Silverlight at least as a means of building cross platform desktop apps, but I understand why they don't want to expend the energy.
Azure and web tech is incredibly important. XAML can be used for desktop apps and store apps...thats been the story for about three years now.
They have said for years that WPF is the way to go if you are writing a desktop app that has rich UI needs.
I really don't understand this kind of thing...was C++ dead even though MFC is only getting minor updates?
Azure is literally the most important thing that the server and tools division is working on. Just because they are developing cloud tools doesn't mean that they wont support desktop apps.
The "mixed message" they have been sending to the enterprise is around licensing. Dev technology changes and this isn't anything new.
However, that doesn't mean that you should and if you're going to lock yourself in to a single priopritory vendor, you're doing yourself and the people you work for a disservice if you haven't weighed it against the alternatives.
I highly doubt the GP really meant that, which is what I was really referring to. What is it about "enteprise" which makes them think they're different? Honest question.
You're betting that Microsoft (or any other company) will continue to support all it's api's indefinitely. And when it doesn't, you not caring about a "wider landscape", will bite you.
Silverlight is great example of this, one year it's "the best" (enterprise) technology the next year it's dead. I wonder if it's even officially supported on Windows 10.
Sadly MS seem to have abandoned it.
They have tried to fight the impression, but people don't seem to listen.
Reminds me of Nokia's words at Qt DevDays when they said they're 100% invested in C++ and Qt. I think one year later they royally screwed their entire developer community and switched everything to .NET with absolutely no way to port your code except by rewriting it.
Luckily Qt survived, in no small part because it was open source. I guess the moral of these stories is to be careful when using languages and frameworks controlled by corporations and to focus instead on open technologies...
The lesson there is to keep learning and stop trying to find silver bullets. What did this guy do join a WPF monastery and only practice WPF-fu without somehow becoming a better .net dev in the process?
If you haven't picked up enough web skills in the last decade to be dangerous you must have been hiding somewhere. Time is only wasted if you let it be. I had to do some crazy shit in access years ago, but I'm not angry that the skills I learned building forms in Access 2000 aren't useful anymore.
I usually end up using WinForms for my limited GUI needs (very limited, desktop only), and that's mostly a wrapper around Win32 APIs that haven't really changed in 15 years or more. Does that mean WinForms is dead?
Although from what i heard at Ignite, they are making some improvements for touch support for WPF, XAML debugging, rendering performance, etc. It had maybe five minutes during an hour-long session on the future of .NET that I went to.
edit: link http://channel9.msdn.com/events/Ignite/2015/BRK2702
I'm just saying...i think they have heard everybody and have tried to bring all of their dev's along on the new app model.
Win32 apps, WPF and .net, objective-c for chrissake...android APIs...what more do you want?
For example, here is a recent post on WPF work for VS 2015 [1]. It is very much alive and being used.
[1] http://blogs.msdn.com/b/dotnet/archive/2014/11/12/the-roadma...
In fact if they were starting from scratch now I doubt they would even use XML, it's not great a great way to edit large documents.
WPF is quite mature for what it does. The components underlying the web are changing rapidly. Comparing these two does not mean WPF is dead.
WPF, Silverlight and WinRT all have XAML at their core.
Sure there are few APIs differences among those versions, but so what?
UIKit is not the same as Cocoa Touch, and I don't see these reactions on Apple Forums.
Nor on Google forums, when they keep changing the UI classes between each Android release.
The whole concepts in the XAML and .NET stack, how bindings work, data templates, DirectX integration and so on are the same, even if there are a few changes required.
There are just a few differences in the APIs, but that is about it.
Somehow, Microsoft doesn't seem to be able to pass the message that all those names are mainly the flavour of the month from the marketing department for the XAML stack.
There are just a few differences in the APIs, but that is about it.
Meaning that of course some changes are required.
It is like when one changes SQL queries among RDBMS servers, of course some things change, but one doesn't have to throw out all the SQL knowledge out the window just because of that.
If you are butt hurt that WPF didn't set the world on fire the way html did...you just weren't paying attention. Evry developer should know html and js...whether you like it or not. I would say the same thing about C...but html and js are the thing that everyone should know something about
An interesting angle to this story is the recent introduction of Xamarin Forms, which is also a form of XAML, even more universal in that it targets iOS, Android and Windows.
The implementations of the objects referenced by XAML may differ and have incompatibilities, but that's not a XAML problem. Xamarin.Forms uses completely different ones, for example, while still keeping the same markup.
Maybe I look at it differently, but I don't expect things like consistency from API's. They are what they are. You find out what you need to do to solve a problem.
It's not like there is something out there that is magically better. Just varying degrees of inconsistent.
But you do not expect an API/object model to arbitrarily change for existing features. Which is what happened.
A Win32 C app from 20 yrs back still compiles with no problems in Windows 10, but where do you go with a big enterprise app that was built 7 yrs back in then-state-of-the-art Silverlight? Any migration will be a big investment and comes with uncertainties and limitations.