These are only opinions, just like the article. I agree with the author that mobile isn't enterprise. Even if enterprise is clamoring for it now, it is a fad for precisely the reasons that the author pointed out. It's a local minimum of productivity that we will eventually tunnel out of; to an area where a real productivity curve exists (mouse, keyboard and monitor most likely).
I disagree that UWP is synonymous with mobile and the author has used the two interchangeably incorrectly. UWP, in theory, runs on all devices but - newsflash - Windows mobile is completely dead. It's exactly like having a go at Linux because it supports DEC.
All UWP is, is a more modern version of WPF that supports more than one execution target (CLI, JS or native). It so happens to run across many devices. I can't see why you wouldn't develop your enterprise software using it (apart from the horrific store) because it's no different from any other stack. If you don't care about it working on mobile, don't deploy to mobile. If you don't care about XBox, don't care about XBox. If you care about one platform only, support that one platform only.
The bonus is that if you aren't enterprise, and do care about the platforms you support, you can carry your skills there. Now, you'd be utterly mad to actually use it (as you would depend on users mad enough to use the store) - but that's the idea behind it.
UWP is unfortunately not a modern version of WPF. It is an adapted form of the Windows 8 'WinRT' platform. It originates from Silverlight of all things.
This is part of the problem, its almost impossible to create WPF-like 'power user' experiences with UWP - as its design philosophy is 'mobile first' and 'touch first'.
Enterprises who would think of building apps with functionality that can be delivered with a UWP app are more likely to just build a web app - its cheaper and requires less maintenance.
The WinRT XAML control stack originates more from directly from "Avalon", WPF's precursor, than Silverlight. Windows Phone 7 was Silverlight-based as an interim stepping stone, and the .NET Core platform is closer in origin to Silverlight than the classic desktop .NET Framework (though not exactly either), which are sources of confusion there, but WinRT/UWP doesn't originate from Silverlight (it just inherits some insight/lessons from it).
I've seen some great power user experiences with UWP, even ones that are happy being "mobile first" and "touch first". "Touch first" is still great for mousing (especially as screen DPIs keep rising and more setups involve monitors in multiple DPI resolutions), even if you think it leads to lower information density (there are tricks to that).
At least in Enterprise environments I've worked "mobile first" is incredibly useful because people are happy being able to work from the device they already carry around at all times. It's to my sadness there isn't more Windows mobile devices as Cordova and/or Xamarin continue to eat up more and more of my development time I could be spending more directly on the applications themselves.
> "Touch first" is still great for mousing (especially as screen DPIs keep rising and more setups involve monitors in multiple DPI resolutions)
WPF is based on vector graphics just like XAML, and high DPI is available for a long time. Per-monitor DPI support is also available for more than a year, they did that in .NET 4.6.2 released in 2016.
Yes, I know how similar WPF is to UWP in DPI support. What "touch first" as a philosophy adds on top of raw DPI support is the concepts of: strong margins, strong minimum sizes, readability when partially obscured. Those things benefit mouse users too, they drop the number accidental clicks, and speed in which a mouse user can click a specific target (faster to find it, faster to mouse over to it, less accuracy required to click it means more speed to go ahead and click it). All of that is UX knowledge that's been passed around for decades before "touch first" (Fitt's Law), but "touch first" helps cement the concepts. If you can touch it, you can click it quickly.
The classic 16px-by-16px/32px-by-32px "toolbar icon" of the Win32 era is now far smaller than most FPS's "headshot" hit boxes on current monitors/DPI settings. Enterprise users shouldn't need to score headshots every time they try to accomplish a task.
Edit to add: …And yes, you could do all of that in WPF too, there are some great "touch first" WPF apps I've encountered over the years. The difference between WPF/UWP here is mostly default stylesheets. But the argument here being replied to is that "touch first" doesn't matter, which I think is incorrect, "touch first" is huge, and does matter, even for (maybe especially for) "Enterprise".
> strong margins, strong minimum sizes, readability when partially obscured
I’ve programmed both for years but never heard about these differences. Do you have a link?
> The difference between WPF/UWP here is mostly default stylesheets
Right, but in my experience when I don’t care about UI design, I can use anything, even win forms. When I care, and have a professionally made UI design on input, default styles & templates are not that relevant for both platforms. I need to create my own ones anyway to implement what the UI designer wants.
> When I care, and have a professionally made UI design on input, default styles & templates are not that relevant for both platforms. I need to create my own ones anyway to implement what the UI designer wants.
A good UI designer may not realize that they desire some of the same ideals as the platform defaults, especially with something like the Fluent Design System. It may not be your job to second guess a UI designer you are working with, but there are times where it makes sense to encourage a UI designer to know/understand the defaults of the platform, and especially the reasons for the defaults of the platform. I've been especially glad since the Fluent branding attempt that Microsoft has been doing a much better job documenting it and the reasoning behind it, as you can see in the links above.
> Right, but in my experience when I don’t care about UI design, I can use anything, even win forms.
In my mind, that is when defaults matter most, when you don't care. If you can get a lot of niceties for free, with no extra work on your part because they are the default, on a platform like UWP, then why not take advantage of that?
The software world and especially the enterprise software world is full of programs built by programmers that could care less about UI design and it shows, and it makes users miserable, even when those users are our future selves sometimes. So many papercuts that could have been avoided by choosing a platform with better defaults to begin with. (Friends don't let friends choose WinForms in 2018.)
Thanks for the links. I didn’t realize UWP has all that by default. When I developed for WinRT/UWP it was for touchscreen-only platforms. But for WPF I do implement what’s written there, however yes have to do that manually both in C# and xaml/styles/templates.
> there are times where it makes sense to encourage a UI designer to know/understand the defaults of the platform
Did that sometimes but it was mostly about less obvious stuff, like controls behavior or animations. I was lucky to work with professionals who didn’t try to bring foreign-looking stuff to Windows.
> Friends don't let friends choose WinForms in 2018
For enterprise software I probably wouldn’t. But for e.g. internal tool for a couple of users and with very simple UI (such as a single dialog application with a couple of edit boxes) WinForms still works OK. It’s simpler to use, integrates with older lower-level technologies better (Win32 API, ActiveX, windows shell, terminal services a.k.a remote desktop), and often consumes less resources (Win32 API is decades old and hence designed for ancient PCs).
> I can't see why you wouldn't develop your enterprise software using it... because it's no different from any other stack
From a .Net perspective, the article authors, it's the debugging challenges that are the major salient difference between WPF and UWP. Considering the demands those frameworks place on developers who are making 'innovative' GUIs there are numerous things that can go terribly wrong at run-time. A lack of relevant debugging tools and a hop between technologies could be a showstopper for some.
COM + .Net competence, like competence with the Win32 API, is somewhat generational. Younger .Net developers are not versed in these things, and those who are command significantly higher salaries and are increasingly less likely to be doing front-end work over time.
If you're dealing with Enterprise customers, or development in the Enterprise, there are real costs associated with moving your baseline developer requirements into specialist territories.
I think you'll find that your employer will move to a newer OS more quickly. Windows 7 is already in extended support, and that ends in 2020. Microsoft is doing their best to reduce the need to support legacy products, so a custom support agreement for Windows 7 is going to be extremely expensive.
I've spoken with several companies that just finished transitioning to Windows 7 in the last year or so.
For them, official support from MS is not a major factor in their decisions.
Whether it should be or not is another matter, but in talking with them, availability of patches really doesn't move the needle as much as you'd expect.
Perhaps, though given how long it took between the begining and end of the win7 roll out I am not convinced. But in any case any IT team starting a project for a few more years will not touch UWP since at least some of the users will be under Win7.
Xamarin has a WPF renderer in some state that is somewhat UWP interoperable.
Maintaining a UWP head and WPF head with .NET Standard libraries shared between them is a reasonable option in some circumstances.
But better still, maybe encourage your employers not to death race upgrades versus exploits all the way to the bitter end in April 2020 like they did with XP's extended support period.
>But better still, maybe encourage your employers not to death race upgrades versus exploits all the way to the bitter end in April 2020 like they did with XP's extended support period.
Ikr, but we can't expect all our customer to upgrade just because our product is in UMP. When we looked at one of our products user base, we could see that over 50% used Windows 7. That ruled out UMP for the subsequent project.
I work in a similar space, although more focussed on the backend. I agree with everything you say as is applies to banking/trading.
BUT ... it's not clear to me that the majority of enterprise software development falls into this category. I think the vast majority is quite likely old VB apps that work perfectly well as web apps.
Most information workers don't have the density or latency constraints that the finance space does.
And where they do, I think in most cases their needs are satisfied by a small-ish set of applications: Excel, AutoCAD/ProE/Solidworks/etc, Photoshop/Illustrator/etc, VisualStudio, and so on.
I do think Microsoft (and Windows) needs a story for the development of "professional" apps like these. And UWP doesn't work for them. I'm not sure C# and WPF does either: how many of even Microsoft's own professional apps are written (or being rewritten) in C#?
Perhaps banking/trading is just too small a market to make it worth Microsoft's while to care about? Perhaps it's a market best served by a third-party stack/tools?
SMH that so many people think that the only ones who like information density and complex desktop apps are finance people.
What about store managers restocking product?
What about developers working on complicated projects?
What about data scientists staring at spreadsheets?
What about power users?
What about anyone with the kind of intelligence that doesn't shy away from large amounts of information?
Do most designers ever think about ANY of these people? Modern app design doesn't even TRY to throw any of these types a bone. No "Advanced >" menus anymore, no pages of options anymore, nothing. It's all just 'sit down, shut up, push the button like a good stupid little user so we can all get paid.'
I think the OP's issue is custom-written enterprise application development though: I agree with your examples of spreadsheets and IDEs (I mentioned those above), but they're generic applications, and their development doesn't justify Microsoft investing in an entire stack.
If the UX and latency requirements can be met with a web app, it doesn't support WPF/.NET maintenance/enhancement.
Web apps can do density so long as the latency requirements aren't too tight. There's where the banking folks spend their IT money.
they're generic applications, and their development
doesn't justify Microsoft investing in an entire stack.
Seems to me there's one or two applications for every profession, and they probably mount up.
I mean, I'm sure if you look at the statistics only 0.1% of users use Photoshop, or Premiere Pro, or AutoCAD, or SolidWorks, or Altium, or Matlab, or whatever - but if you drop support for all of them, what are users going to do?
There are also new development fronts in specialist domains that are computationally intensive or a poor fit for web-apps.
Specifically, when WPF was launched all they could talk about were the cool 3D possibilities for doctors, researchers, and such... The reality has been less "Minority Report" than we had hoped, but those kinds of demands are growing, and very often will require the level of control over hardware that demands a desktop app.
In theory a lot of this is solvable with webapps, in practice there is a reason desktop computing environments exist :)
Visual Studio is written in C# and I think WPF, but I'm not sure anymore at this point. Most professional apps have a wide audience, and therefore can justify more development resources, so they tend to get written in harder ways (C++ and whatever UI works there). C#/WPF work great for apps that require lower costs/more productivity because they aren't going to a million seats.
You're both right. Yes, it's WPF, and there are lots of parts written in C#. But the parent is right -- Visual Studio is C++ using COM and Win32 at its core, going back all the way to the Visual Basic IDE that shipped as part of Visual Studio 6. It would be a very difficult port to Mac, Linux, etc. As of this writing there is even no 64-bit version for Windows (although that's just a matter of spending the time and money to do it.)
The brand name has been re-used for other software. Visual Studio for Mac is Xamarin. Visual Studio Code is on the Electron platform.
Surprisingly, the lack of a 64 bit version is a performance choice.
”For a long time now developers have been asking why Visual Studio hasn’t made to switch to 64-bit. Rather than effort or opportunity cost, the primary reason is performance.”https://www.infoq.com/news/2016/01/VS-64-bit
Initially yes, but they have been making the Roslyn tooling the same across both IDEs.
Visual Studio for Mac has many new features that weren't present in Xamarin Studio, like .NET Core support, ASP.NET types of workflows. And all new Xamarin.Forms improvements are shared between both IDEs.
Number of users an app has is a horrible way to decide whether to write it in C++ or not, and even if it were a good driver Visual Studio is a $1B business for Microsoft so it’s hardly a little niche app lacking a wide audience.
VS has a lot of things going on, many of the teams to specific pieces of functionality that might seem obscure to many of us. The Shell team isn’t that big from what I recall, so yes VS is a huge business but there are a lot of things going on so it’s not like everyone in devdiv is working on core VS. It is really different from a consumer office app.
Another huge pain point of UWP: the whole suspend/resume concept.
UWP apps can't be closed by the user. The system manages the lifecycle and there's no way for a developer to know when the app will be terminated and when to save data.
To save your app's data you have to:
- Register for a suspend event
- Ask for an extended execution so that your app is not terminated within a few seconds
- Save your data and cross your fingers that the system does not terminate your app anyway and your data is lost
I recently ported a document-based macOS app to UWP and this was the BIGGEST pain point (aside from the fact that there's no easy way for an app to have more than one window, ouch).
You are absolutely right, and I work with users who would fire someone in the dev team if their WPF app ever went down during the week (the app is kept running for 5 days of the week). This is necessary for many trading platforms
It's worse when your app requires to maintain a constant connection to a server in order to function - when the app suspends good luck knowing when that connection will be closed, even with an extended execution!
An application can never trust that the connection is reliable. When the app suspends, it is too late to use network. You should shut down as if you were offline.
Even with a background task your app can be terminated by the system without further notice after the suspend event (e.g. when the user powers off the device). There's no orderly fashion in which an app can be terminated and save its data.
> The Enterprise doesn’t care about mobile — it really doesn’t.
The enterprise didn't care about minicomputers, until it did.
The enterprise didn't care about PCs, until it did.
The enterprise didn't care about Web applications, until it did.
In each of the above cases, there were people insisting that The Enterprise would never follow the general market. The Enterprise has special needs, they said. The Enterprise needs things the new tech can't provide, they said. They kept saying that right up to the moment The Enterprise finally moved and made their objections irrelevant.
Enterprise customers see the hot new stuff general consumers have access to. They want it. And they command big enough budgets that someone will eventually get the hot new stuff up-armored and Enterprise-Readied so they can use it to peel off a share of those budgets. By the time this actually gets deployed the hot new tech isn't hot or new anymore, but that doesn't matter. Once the first enterprise domino falls, the rest tend to fall pretty predictably.
You can make a good living for a long time selling legacy tech into the enterprise market. But "a long time" does not mean forever. Enterprise software buyers move slowly, but they do move.
I think there's a distinction to be drawn between mobile _apps_ and mobile device support. It is important to note that often the reason a mobile app exists is for reasons other than to provide features to the user. For example it is easier to monetize users with an app (you can do in-app purchases and plague the user with push notifications to drive engagement). Users are more likely to stay being users with an app. You can support social type interaction such as taking photos easier. None of this matters much for enterprise applications.
Therefore most of the time a simple mobile-friendly web app works fine for enterprises.
If anyone from MS is reading this, please consider throwing some support behind WPF. It's actually a very reasonable framework for native development, and with a few updates here and there, would be competitive (in terms of developer-hours) with the latest JS frameworks.
I doubt that will happen, as MS is seemingly embracing the whole web-services/HTML/JS model. VS Code might be the nail in the coffin - possibly an Electron test-case to see if the entire VS proper can be ported over.
There's a glimmer of hope over here [1]. Microsoft updated the XAML Designer. The new designer has support for UWP but note the comments. In particular "WPF [support] will be shipped sometime after the UWP Designer has been released and stabilized."
The author has some good points. But the solution he proposes - bringing back WPF with a bunch of features they didn't bother adding in the last 12 years - that sounds questionable to me.
WPF wasn't really adopted the first time around. WinForms kept being used for years (till this day) after WPF was the official guidance.
And now, after WPF was abandoned for UWP there is very little chance Microsoft is going to resurrect it.
WPF was very successful, it didn't kill off Winforms but it was used in many many small enterprise apps.
Then Microsoft just...abandons it. Many were annoyed by that.
UWP would be reasonable if they didn't require giving up so many .net features, I'm particularly disappointed that they killed off the DLR for it, and made reflection more costly (because it is supposed to be ahead of time compiled only). It also reminds me of Silverlight in the number of arbitrary things left out from WPF.
So rather than switching from WPF to UWP, I've gone from WPF to...Javascript/DOM/Canvas.
Same here. I used to be a desktop guy but after Winforms, WPF, Silverlight, WinRT and UWP new stuff will be web apps only. I don't trust MS on the desktop anymore.
I disagree - WPF is still used in a very large swath of business applications. As the author points out, if a fork of WPF was modernized with all of the current framework features (generics, async/await, deeper MVVM integration) it would be a great UI framework.
This article is pretty clueless, the author seems to be conflating his broad experience in the banking industry with Enterprise as a whole.
> The Enterprise doesn’t care about mobile — it really doesn’t.
I guess I can't speak for The Enterprise, but only as someone who works in an enterprise. We recently switched to a new service desk system with very strong mobile support, from one with none. Responding to support tickets is a significant aspect of my role, and this has been a huge workflow boost to me. Pretty much anything else we roll out to expand user's access in the mobile space is being gobbled right up. I don't know what rock the author's been living under but a statement like "The few mobile enterprise apps currently out there are more about productivity triage [...]nothing more" is crazy sauce. This space is exploding right now, although falling on their face in that platform race does mean MS and UWP are playing a pretty minimal role in it.
> enterprises do not buy their employees touchscreen laptops, unless there’s a really niche requirement — which is very rare.
Enterprise doesn't buy touchscreens laptops? We've bought hundreds of laptops in the past year and almost all are touchscreen -- not because we give a shit about that, but because they are cheaper than spec'ing a custom order from our vendor to get one without. I agree with the core tenet that touchscreens on laptops are likely never going to be useful, but MS seems to be responding to actual market conditions the author is ignorant of.
> we cannot take advantage of the super-accurate mouse and keyboard input devices that have been so amazing for so long.
I would posit the mouse is super accurate for pointing at fixed targets, but has dreadful accuracy for drawing or any sort of path-based input. There's a reason artists don't use them, and considering a broader range of input paradigms is a decision I would not so quickly fault an OS developer for making.
> Adobe have just release at design tool called XD that’s a UWP app. Compare its usability with its main (proper desktop) rivals like Photoshop and Sketch. The comparison is startling. XD feels like a small mobile app with limited capability, and its because that’s exactly what it really is.
XD is a specialty app with an extremely limited feature set. It is, by design, vastly limited compared to PS because it's trying to compete with more stripped-down successful prototyping platforms from competitors. This is a complete red herring example.
Can anyone explain, why would anyone ditch WinForms in favor of a newer technology on .NET stack? I mean complex apps, not simple forms? Winforms is close to metal (in the sense it is close to Windows), it's high performance in contrast to WPF and its virtualization, it's been here for ages and can't really disappear because WINAPI won't disappear.
In order to make a WinForms app look native on Windows 10, you have to do a LOT of manual layout/padding work. It is do-able but it's a lot of work.
Of all the main code platforms that MS push, I'm still pretty much tied to WinForms - I prefer it, and it feels more intuitive to the way I think. It's also been around over 2 decades now, and you can pretty much do ANYTHING with it.
I skipped the WPF revolution, and am just about to dip my toe into UWP apps (I'm not a professional coder). I think I'm going to find it a steep learning curve :(
What I'd LIKE to see, is UWP running on Linux? That would really cement MS's 'run anywhere' concept.
Why would anyone want to make an app look Win10 "native"? It looks horrible (something is always up with the font rendering) and I'd actually prefer a WinForms app.
'Win10 Native' in this context is making your app look like it's seamlessly part of the OS. The big change is the default font:
Segoe UI Font:
- Standard usage: 11pt Regular
- Sub Headings: 14pt Semi-bold
- Headings: 20pt Regular
WinForms in Visual Studio still defaults to MS Sans Serif 8pt - so you have to change that at the form level before you even start. Plus all the controls have NO padding around them, so you have to add padding manually or use panel controls to space stuff. It's a pain, but not insurmountable.
The thing that kills me, is that I can whip together a fairly complex application in WinForms in hours, and it just works, and is easy to reason about. Trying to do the same with a web app, is like pulling teeth, there's so much ceremony, and so much surface area where things can go wrong.
Microsoft wants to be able to ship Windows machines without the legacy Win32 API at all. Win32 has a lot of baggage and dumb APIs that UWP manages to do better. Windows 10 has already migrated more of Win32 out of the kernel and into a not-close-to-the-metal-at-all emulation layer and its only going to get less performant and more virtualized.
Is this based on some internal information or can you provide citation? It'd be really interesting if what you're saying was on the roadmap officially.
Windows for ARM just recently debuted, with Win32 entirely running in an emulation layer.
Reading through the Insider blog posts shows a long thread of disconnecting Win32 from Windows as a part of the OneCore efforts.
Win32 may remain mostly performant (the word on the street is that the ARM emulation is very performant), but the days when it was the most "blessed" API set for Windows have passed.
The biggest downside for us is the deployment model, we'll stick with winforms for the foreseeable future* but getting the software onto user machines is still about as easy as it was in 1995, this is half the reason many apps become web apps in the first place, instant deployment.
Hosting a corporate store is azure only which is a no go, so we're stuck with the god awful click once.
There are no push deployments, when we release a new version we want everyone to be on that version, not waiting for the app store to get around to it.
The store may have caught up in this regard, but we also need to control which users get which version of the software for deploying preview builds.
The enterprise is MS's bread and butter and I always thought that they understood it well, I increasingly think that they never understood it and they just got lucky that for a time enterprise needs aligned with MS capabilities.
*There is a project to replace many of our winforms apps with react, can't wait to see this crash and burn.
I don't see a lot of engineering design, analysis and simulation software being done in the browser or mobile device. There are a few examples, but the really powerful stuff is desktop Windows (some still in WinForms) or Unix/Linux. The cloud offers some great potential for doing HPC stuff on large clusters, but the user interfaces necessary for DEFINING the problem aren't something I want to do on a touch screen or in a web Client.
I still hate the webclients for major brand tools like SAP and Successfactors where they still don't know about async calls...
I was skeptical about WPF at first, as I didn't like XAML at all. I'm happy I stuck with it. Under XAML is a really elegant engine that you can interface with directly (few of my WPF projects have any XAML in them at all).
I skipped UWP for the same reasons as OP, and because you can't (as far as I have been able to figure out) distribute windows services with it. Win2D looked like an answer to a lot of my design issues, but I got a sense that the team building and maintaining it was smaller than mine.
If Microsoft heavily re-invested in the desktop I would be very happy.
The problem of WPF in my opinion is the absence of strong typing (all binding is based on magic strings) and the fact that if you want to customise a little bit a control you are left rewriting it from scratch. WPF could be a lot better and easier to use than it is.
That binding system is XAML specific. If you bypass XAML, you bypass the magic string binding as well.
I found interfaces a lot easier to build when I ditched the declarative markup and interfaced with the control system directly. XAML as far as I can tell was introduced as an attempt to woo web developers; but it's a thin layer ON TOP of WPF. It seems like a lot of people believe it IS WPF. WPF goes very deep.
I thought UWP Desktop Bridge might allow enough desktop access to support packaging a Windows service. Nope, the Bridge is not designed for that purpose and Windows services are explicitly not allowed.
https://docs.microsoft.com/en-us/windows/uwp/porting/desktop...
Elsewhere the docs talk about registering background tasks through another interface, but it seems like proper integration with services is a legitimate use case for people trying to embrace the blessed desktop path.
You can distribute UWP services on Server, tho! I believe it's just a matter of time when it comes to Desktop, they are just being extremely cautious to implement on the right way.
I'll take the otherside, WPF was only useful on Windows desktops. UWP apps can run on desktop, mobile even consoles. Before UWP developing across all devices was much more difficult. Developing UWP with Xamarin you can get iOS, Android, Windows platforms with very minimal differences in many cases. With .NET Standard/Core 2 even older .NET libs work in many cases except a key part of WPF, System.Drawing.
WPF was built on older non .NET Standard/Core that doesn't work for Microsoft anymore, Windows lock-in is dead and that is what the WPF/Silverlight game was. They tried to platform lock in at the Windows layer with WPF but it was too late, mobile hit soon after.
Microsoft has to be cross platform now and the lock-in has been moved up to Azure, their new OS for developers essentially.
I think UWP is a better platform than WPF even with less maturity. Lots of people liked WPF as it was better than the previous iteration in Winforms, and probably grew a liking to it, but UWP is now and trying to keep old Microsoft platforms alive is a lost cause. Devs must move to what Microsoft is pushing just as you do with Apple, if not, feel the wrath of the future.
UWP apps can run on desktop, mobile even consoles.
Windows Mobile is dead, so UWP is really just for desktops and Xbox (and Hololens, but no one cares). How many apps are going to be used on both desktops and Xbox? Maybe some trivial ones, like a weather app. So, realistically, UWP is for desktop apps, and it's just not as good as WPF for that. It doesn't even come with a multi-column list control!
> Windows Mobile is dead, so UWP is really just for desktops and Xbox
Surface Pros are desktops but closer to tablets/iPad style. So it is like a desktop on mobile platform really. Lots of business apps are going to the Surface for control reasons like that. Who knows, maybe one day Microsoft returns to mobile phones not just tablets, Surface Pros are making inroads and Windows Ink is solid. Bill Gates tablet vision was too early, Microsoft has a valid competitor, but yea it is technically 'desktop'.
Big reasons Microsoft went UWP: Surface/tablets, AOT compiling, Windows Store and building compat with .NET standard/core 2, touch inputs + mouse input, none of which WPF offered. UWP will evolve but it is going to closely match iOS/Android more than Windows desktops of the past.
> Windows lock-in is dead and that is what the WPF/Silverlight game was.
This statement is in total contradiction with what UWP is: a platform so OS-locked it doesn’t even run on Windows < 10. On the other and both WPF & Silverlight runs on multiple Windows versions and Silverlight was supported on Mac OS.
> UWP is: a platform so OS-locked it doesn’t even run on Windows < 10
True on the Win 10 point but they had to make a change, they do similar with new platforms all the time, WPF was pushed on Vista.
Basically UWP matches up nicely with other platforms under Xamarin especially. Though most of Xamarin is iOS/Android focused probably because of the market, it closely mirrors those so that it is easier to make a UWP app from one of those apps. Many business apps are going Android, Surface or even iPad/iPhone Apple focused.
Microsoft had to make a hard change for this, UWP is actually a joy to work with on new projects but porting a WPF app may be difficult and you may have to make many custom controls outside touch friendly interfaces.
> WPF & Silverlight runs on multiple Windows versions and Silverlight was supported on Mac OS
True but not for long, Silverlight also no longer runs on any browser but IE.
UWP will evolve, WPF and Silverlight were very rudimentary on their first iterations. Silverlight was solely js based on Silverlight 1 even. Winforms was more supported at the time when WPF came out as well, WPF was only for Vista when it launched, XP it runs slow.
Before .NET and Winforms it was Visual C++/VB apps, MFC, COM+ etc.
Every once in a while things change enough that the old must be thrown out. WPF was a pre-mobile toolkit and Silverlight was for the age of Flash, those times are in the past.
Mobile and desktop are two different beasts, and all the effort in the world won't make them equivalent. If you want to hit mobile devices, fine, use Xamarin. If youre building for desktop, use something that makes sense there, like WinForms or WPF. You've got wildly different screen sizes, form factors, and input devices between the two classes of devices, and always will. Cramming them together just gets lowest-common denominator garbage, like UWP.
Is it a good thing that the same app can run on desktop, mobile, and console?
I interact with those type of devices in totally different ways. In many cases, you could share some core logic, but the UI should be drastically different. For some types of apps, the core assumptions of the different platforms are so different, it's hard to share anything.
Regardless of that, UWP has poor teach for Microsoft desktop and Microsoft mobile. Somewhere along the way, Microsoft forgot that they won't let most people upgrade from windows phone 8 to windows mobile 10, and that there are a lot of holdouts on desktop too.
Silverlight is the proof that wpf isn't and wasn't meant as a platform lock-in. And Microsoft went big on silverlight, until they realised it was about to be booted from the browser. I think webassembly will give a chance to the return of a silverlight.
Silverlight was a subset of WPF really to compete with Flash. In 2005-6 both were huge pushes and competitive, Microsoft with Silverlight, Flash with AS3/Flex. Part of this was due to Flash video/Silverlight video that took over the world in 2005-6 with youtube and more. This was just before mobile killed Flash and thus Silverlight. Silverlight never got off the ground except for video really and will not come back. Microsoft had another Flash competitor when Flash3/4 was out called Liquid Motion, same fate. When Microsoft abandons a platform you better as well.
All of them were awesome vector based rendering platforms that had great data/web integration. They were also complete packages but thrived when plugins thrived until mobile and Chrome killed plugins.
Flash/Silverlight still have some advantages over html5/webgl/canvas/svg (much of if by Khronos, funded by Apple initially) but those have essentially taken their place and WebAssembly that came from Emscripten/asm.js from Mozilla will eventually be another option.
I do miss the vector nature of Flash/Silverlight but both are gone, especially the latter. There are better options like Haxe, OpenFL/lime, Adobe Animate (Flash successor in web standards) if people still want to use Flash like platforms.
"When Microsoft abandons a platform you better as well."
This is one of the reasons why I am deeply skeptical of UWP. It looks like a Microsoft-only show, and Microsoft frequently strongly support a platform right until they change direction and flip it into maintenance mode to pursue the Next Big Thing. Why invest in it if you don't need to?
One if the ways that Microsoft proved WPF could be used for real apps was that they wrote visual studio with it. you cant build visual studio witb UWP.
i hope that the platform gets there...but right now if i started a new windows app i would use the centennial bridge.
I agree with the article: enterprise will never play well with store/uwp nonsense. I have the same background - I work in high perf very heavy desktop .NET and I can’t see any reason UWP would work here.
But: I also see where Microsoft are coming from. There is no need to innovate in this space. Microsoft want people to run mobile, touch, store... and those of us doing heavy desktop can use third party tooling or just stay with the mature tools we already have. Microsoft will never sunset the legacy win32 stack, and enterprises of the kind the author describes will never choose a windows that doesn’t allow the standard win32 stack.
Reading the comments, I think most of you miss actual realistic complaints of the author.
1) UWP apps are absolutely horrible to debug. They use some kind of COM broker layer to deliver the majority of very cryptic framework level exceptions. Almost everything IS an exception. There's also no way to get proper stack traces in compiled applications and worse, only apps delivered through the store will symbolicate the final crash point, so good luck trying to find the root cause if it's not immediately obvious.
The level of absurdity here is, if you drop a file in a UWP app's drop target that doesn't have foreground focus, the data broker will throw an exception that you can't do that. There's no realistic way to manage that exception, so if you're not diligent it'll crash your app.
2) Then there's the whole XAML interface framework. (Though they seem to slowly be moving away from this to a more reasonable flexible framework, sort of like iOS CoreAnimation, called Composition.) Originally it was meant to be freely styled by "designers", but as the original WPF and Silverlight proved, this flexibility resulted in terrible designs and apps looked cheap and crappy. So the UWP XAML team instead built a completely stylized framework and all the controls have hard-coded baked in assumptions about those styles remaining unchanged. So in that aspect, even if you wanted to push UWP XAML to allow for more information density, you would run into all kinds of show-stoppers.
They are not moving away from XAML to Composition. Composition will be just a "backend" for XAML. Some XAML controls already use Composition and you don't even notice it.
This is more about desktop development than enterprise development. With that in mind, I think there's a better chance of people figuring out how to get it done on UWP or with web technologies (perhaps with some help from MS) than there is of MS improving support of WPF.
Azure is where it's at now for Microsoft, and WPF/desktop apps don't run on Azure.
> Web apps don’t cut it. They don’t cut it as replacements for serious desktop apps.
I don't buy that. If the argument is that "the Enterprise" doesn't care about mobile for this last decade, then it certainly didn't care about usable and powerful desktop apps the decade before.
“enterprise” is a bit vague. But the IDE/Cad/Media creation apps aren’t going to be mobile or web in 10 years either. It’s the “pro” apps that are key - which perhaps isn’t “enterprise” depending on your definition.
One thing I'm not seeing is people talking about the reason Microsoft created UWP: as a competitor to responsive web frameworks that could run on their Continuum and Windows on ARM platforms.
Full stop.
Of course, the second they abandoned Windows Mobile, it made UWP irrelevant (not that it was terribly relevant anyway).
Absolutely no one* wants to build an app that works only on Windows 10 desktops, Xbox and IoT devices. There's no use for that.
I understand the author's frustration, though I don't agree with all of his points. However, what is Microsoft's motivation for investing in WPF at this point? If they don't improve WPF, will enterprise customers stop using Windows? Unless it moves the needle significantly one way or another, they won't do much with WPF. Besides, they have their hands full on other fronts.
The mistake made in this article is that the problem with UWP is not that it is touch, but that it purports to be universal. There is no universal solution that works on both touch platforms and the desktop. Either it sucks on one of these or both of them.
The right solution is to make it so what can be shared is shared and what needs to be specialized can be specialized.
I think we have to ask ourselves, why do we need apps that run on the local machine anyway? 90% of my CPU time goes to Chrome/Firefox. Outlook in one of those runs better than Outlook native on Windows. Play music in the browser works as well as any native music player. Netflix in edge runs as good as the UWP Netflix app. I suspect there's a lot of code reuse among them. There is no mass market for desktop apps anymore.
Even things like slack run better in the browser than outside as an independent app, because they anyway use a browser engine to run for compatibility.
I use vim and VS code for editing. Vim doesn't need a new framework, and VS code bundles an entire web browser engine within it (electron), again, for cross platform compatibility.
All the internal company tools like code review, ticket management, etc. which used to be native apps, now run in the browser, too.
So let me ask again, why do we need a new app framework at all? What we have with WPF is good enough for the rare app that actually needs to run natively. Everything else is a web app already.
Web apps deliver scientifically non-reproducible results and have obvious privacy implications. As a consequence, people cannot use them to design a PCB, simulate a circuit, drive a production line and everything like that on professional scale.
Yes, Web is a damn good technology for distribution, consumption and communication, but I vaguely imagine a situation when a professional relies on Web to do the real manufacturing job on a daily basis with guaranteed, stable and reproducible outcomes.
Please note that enterprise is a huge paying market. You cannot ignore it, as it lies behind everything you can buy in this world.
For example : I used to work for a power system analysis company that built a UWP app for use by engineers while on the floor of a factory or something similar. Is used for drawing electrical diagrams, data capture, and there had been plans for some level of analysis in the app too. But the main reason it is a UWP app is the touch interface. Not really feasible as a web app, especially if there's no internet on the factory floor.
You comment like if internet access was a given: always available, fast, (free), etc. which is in practice not the case for everybody everywhere. Availability problems also occur at the other end: remember when GitHub was down because of an issue with Amazon S3.
And it also extend to updates: if a webapp make an update that's breaking productivity for some reason, you're screwed. On the other hand, you can ignore them on desktop and work like you always do.
Also there is the data ownership, privacy and professional secrecy problematics. Why should I give every bits of my data to an external entity who can then do everything with it when I can do the processing on my own hardware? This is a total none sense.
So there is many reasons for desktop app to be still relevant.
Also the Store is a deal-breaker for B2B apps. It is not acceptable to not be able to make available an emergency hot fix when your customer somehow depends on your desktop application to make her own money.
The Store publishing latency is probably acceptable for free B2C apps, but not for B2B applications.
Enterprises have been able to distribute apps outside the Store since Windows 8.0 back in 2012.
With Windows 10 you can just distribute the .appx and install it with a double click (given you've installed its certificate or if its CA is already trusted, which is common in enterprise environments). No Store required.
Honestly do not see a lot of native development happening on Windows any longer but far more wev interfaces of some kind. I really do not see native coming back in a big way.
I disagree that UWP is synonymous with mobile and the author has used the two interchangeably incorrectly. UWP, in theory, runs on all devices but - newsflash - Windows mobile is completely dead. It's exactly like having a go at Linux because it supports DEC.
All UWP is, is a more modern version of WPF that supports more than one execution target (CLI, JS or native). It so happens to run across many devices. I can't see why you wouldn't develop your enterprise software using it (apart from the horrific store) because it's no different from any other stack. If you don't care about it working on mobile, don't deploy to mobile. If you don't care about XBox, don't care about XBox. If you care about one platform only, support that one platform only.
The bonus is that if you aren't enterprise, and do care about the platforms you support, you can carry your skills there. Now, you'd be utterly mad to actually use it (as you would depend on users mad enough to use the store) - but that's the idea behind it.