16 ms·

Microsoft and the UWP for Enterprise Delusion

150 points by garganzol 9y ago

smacktoward 9y ago
> 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.
- phillipcarter 9y ago
  The author does a fair job explaining what he means: > The few mobile enterprise apps currently out there are more about productivity triage — a quick glance while your getting a latte — nothing more. Do you disagree with that assertion, or just his general statement?
- dboreham 9y ago
  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.
jcastro 9y ago
> 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.
- alkonaut 9y ago
  “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.
starik36 9y ago
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.
- achr2 9y ago
  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.
  - maxxxxx 9y ago
    In addition another great step would be if they cleaned up xaml the same way they cleaned up MVC with Razor.
    - pjmlp 9y ago
      That is what XAML Standard is for.
- seanmcdirmid 9y ago
  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.
  - maxxxxx 9y ago
__d 9y ago
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?
- tomc1985 9y ago
  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.'
  - __d 9y ago
    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.
samcat116 9y ago
This might apply for banking/trading, but it does not apply at all for education markets.
flukus 9y ago
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.
- xab9 9y ago
  React will solve all the world's problems. If not React, then Angular. I can't wait to see the projects falling apart when in two years G/Fb comes out with The Next Big Thing.
jacksmith21006 9y ago
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.
- pjmlp 9y ago
  Doing native development for Windows, of new .NET applications, during the last 4 years. Many business don't want anything browser related, or need applications working in disconnected environments. Enterprise has many special needs.
- alkonaut 9y ago
  It’s always going to be a niche, but I think it has stopped shrinking. The apps that haven’t left the desktop yet haven’t done so for a reason.
youdontknowtho 9y ago
i think this guy nails it. 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.
- naikrovek 9y ago
  You can, you just can't use Microsoft's provided UWP controls to do it.
ghostly_s 9y ago
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.
avinium 9y ago
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.
- pjmlp 9y ago
  Future of WPF is UWP. WPF is for pre-Windows 10 desktops.
- martinsuchan 9y ago
  Adding Compiled Bindings to WPF could be a nice start.
- mattmanser 9y ago
  I remember when I learnt Silverlight it had a huge learning curve because Xaml takes a while to wrap your head around. Given that, I can't really see it ever becoming competitive.
- taspeotis 9y ago
  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." [1] https://blogs.msdn.microsoft.com/visualstudio/2017/09/11/a-significant-update-to-the-xaml-designer/ https://blogs.msdn.microsoft.com/visualstudio/2017/09/11/a-s...
DrTung 9y ago
Agree 100%. I had a bunch of legacy Winform apps and faced the same dilemma. Solved it by switching to Qt. It's excellent even if you just use it for Windows development, i.e. never use any of its crossplatform abilities.
- tonyedgecombe 9y ago
  But then you are stuck with C++ or some crappy binding for your favorite language.
  - tolger 9y ago
    I am considering Qt as well. Modern C++ is a very nice language. I actually prefer it over Java, and I do a lot of Java at work.
- xaldir 9y ago
  I'm with you on this.
nlawalker 9y ago
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.
- ThinkBeat 9y ago
  The client code could run in a browser or in a desktop application. The juicy backend bits could run just fine in Azure.
- pjmlp 9y ago
  Actually thanks to Ooui, http://ooui.mecha.parts/ http://ooui.mecha.parts/ , they kind of do.
technicalbard 9y ago
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...
drawkbox 9y ago
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.
- cm2187 9y ago
  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.
  - drawkbox 9y ago
    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.
m0ther 9y ago
I agree with this. 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.
- cm2187 9y ago
  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.
  - m0ther 9y ago
    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.
    - vitorgrs 9y ago
      The same thing happens on UWP. People see XAML and thing that UWP is just that.
- shoover 9y ago
  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-to-uwp-prepare 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.
cra1ghunt 9y ago
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.
zamalek 9y ago
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.
- therockhead 9y ago
  The platform UWP needs to run on is Windows 7. Without that support it’s not an option for my company.
  - cm2187 9y ago
    A lot of enterprises have only recently moved to Windows 7 (like my employer). A framework that is incompatible with Windows 7 is just a non starter.
    - tallanvor 9y ago
      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.
polskibus 9y ago
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.
- tonyedgecombe 9y ago
  For me supporting high dpi in WinForms was a lot more work than I'd have liked, other than that is a very productive framework.
- pjmlp 9y ago
  XAML is closer to the metal than Winforms. Forms uses GDI+, while XAML uses DirectX.
  - Jaruzel 9y ago
    > Forms uses GDI+, while XAML uses DirectX. Both of which are abstraction libraries, so I don't understand your point ? Yes DirectX is more powerful than GDI+, but I challenge that it's 'closer to the metal'.
    - pjmlp 9y ago
      Well, GDI has quite a few more translation layers to go through between app and GPU. "Comparing Direct2D and GDI Hardware Acceleration" https://msdn.microsoft.com/en-us/library/windows/desktop/ff729480(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ff7... Also, XAML has been fully rewritten in C++ for UWP, consumed by .NET Native as UWP components.
      - Jaruzel 9y ago
        I sit corrected. ta! :)
      - polskibus 9y ago
ricg 9y ago
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).
- rymate1234 9y ago
  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!
  - pjmlp 9y ago
    Well, that can be sorted out with a background task.
    - ricg 9y ago
      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.
      - pjmlp 9y ago
        The suspended even is the orderly fashion to save the data. An ExtendedExecutionSession with a SavingData reason, should be more than enough for any kind of data.
        naikrovek 9y ago
alkonaut 9y ago
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.
dingo_bat 9y ago
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.
- garganzol 9y ago
  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.
  - jenscow 9y ago
    But, would you consider UWP being appropriate with those types of applications? I mean, if an application is well suited for UWP, then it's probably better off as a web app.
    - mcaravey 9y ago
      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. https://www.microsoft.com/en-us/store/p/easypower-onsite/9nblggh5ggfk https://www.microsoft.com/en-us/store/p/easypower-onsite/9nb...
rmrfrmrf 9y ago
Enterprise isn’t Windows-only anymore. If you’re not targeting Mac and Linux, too, you’re doing it wrong.
jenscow 9y ago
UWP comes from the "cloud-first mobile-first" Microsoft. Neither are well suited to enterprise, and one of which has been canned.
lafar6502 9y ago
Ha ha it would be a progress if they dug out win forms and made it official api. And I’m not throwing away my Petzold
thebosz 9y ago
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. *Obvious hyperbole.
tinus_hn 9y ago
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.
jarjoura 9y ago
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.
- vitorgrs 9y ago
  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.

150 points by garganzol 9y ago

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

phillipcarter 9y ago
The author does a fair job explaining what he means: > The few mobile enterprise apps currently out there are more about productivity triage — a quick glance while your getting a latte — nothing more. Do you disagree with that assertion, or just his general statement?
dboreham 9y ago
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.

jcastro 9y ago

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

alkonaut 9y ago
“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.

starik36 9y ago

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.

achr2 9y ago
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.
- maxxxxx 9y ago
  In addition another great step would be if they cleaned up xaml the same way they cleaned up MVC with Razor.
  - pjmlp 9y ago
    That is what XAML Standard is for.
seanmcdirmid 9y ago
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.
- maxxxxx 9y ago

__d 9y ago

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?

tomc1985 9y ago
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.'
- __d 9y ago
  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.

samcat116 9y ago

This might apply for banking/trading, but it does not apply at all for education markets.

flukus 9y ago

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.

xab9 9y ago
React will solve all the world's problems. If not React, then Angular. I can't wait to see the projects falling apart when in two years G/Fb comes out with The Next Big Thing.

jacksmith21006 9y ago

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.

pjmlp 9y ago
Doing native development for Windows, of new .NET applications, during the last 4 years. Many business don't want anything browser related, or need applications working in disconnected environments. Enterprise has many special needs.
alkonaut 9y ago
It’s always going to be a niche, but I think it has stopped shrinking. The apps that haven’t left the desktop yet haven’t done so for a reason.

youdontknowtho 9y ago

i think this guy nails it. 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.

naikrovek 9y ago
You can, you just can't use Microsoft's provided UWP controls to do it.

ghostly_s 9y ago

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.

avinium 9y ago

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.

pjmlp 9y ago
Future of WPF is UWP. WPF is for pre-Windows 10 desktops.
martinsuchan 9y ago
Adding Compiled Bindings to WPF could be a nice start.
mattmanser 9y ago
I remember when I learnt Silverlight it had a huge learning curve because Xaml takes a while to wrap your head around. Given that, I can't really see it ever becoming competitive.
taspeotis 9y ago
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." [1] https://blogs.msdn.microsoft.com/visualstudio/2017/09/11/a-significant-update-to-the-xaml-designer/ https://blogs.msdn.microsoft.com/visualstudio/2017/09/11/a-s...

DrTung 9y ago

Agree 100%. I had a bunch of legacy Winform apps and faced the same dilemma. Solved it by switching to Qt. It's excellent even if you just use it for Windows development, i.e. never use any of its crossplatform abilities.

tonyedgecombe 9y ago
But then you are stuck with C++ or some crappy binding for your favorite language.
- tolger 9y ago
  I am considering Qt as well. Modern C++ is a very nice language. I actually prefer it over Java, and I do a lot of Java at work.
xaldir 9y ago
I'm with you on this.

nlawalker 9y ago

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.

ThinkBeat 9y ago
The client code could run in a browser or in a desktop application. The juicy backend bits could run just fine in Azure.
pjmlp 9y ago
Actually thanks to Ooui, http://ooui.mecha.parts/ http://ooui.mecha.parts/ , they kind of do.

technicalbard 9y ago

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

drawkbox 9y ago

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.

cm2187 9y ago
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.
- drawkbox 9y ago
  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.

m0ther 9y ago

I agree with this. 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.

cm2187 9y ago
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.
- m0ther 9y ago
  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.
  - vitorgrs 9y ago
    The same thing happens on UWP. People see XAML and thing that UWP is just that.
shoover 9y ago
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-to-uwp-prepare 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.

cra1ghunt 9y ago

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.

zamalek 9y ago

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.

therockhead 9y ago
The platform UWP needs to run on is Windows 7. Without that support it’s not an option for my company.
- cm2187 9y ago
  A lot of enterprises have only recently moved to Windows 7 (like my employer). A framework that is incompatible with Windows 7 is just a non starter.
  - tallanvor 9y ago
    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.

polskibus 9y ago

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.

tonyedgecombe 9y ago
For me supporting high dpi in WinForms was a lot more work than I'd have liked, other than that is a very productive framework.
pjmlp 9y ago
XAML is closer to the metal than Winforms. Forms uses GDI+, while XAML uses DirectX.
- Jaruzel 9y ago
  > Forms uses GDI+, while XAML uses DirectX. Both of which are abstraction libraries, so I don't understand your point ? Yes DirectX is more powerful than GDI+, but I challenge that it's 'closer to the metal'.
  - pjmlp 9y ago
    Well, GDI has quite a few more translation layers to go through between app and GPU. "Comparing Direct2D and GDI Hardware Acceleration" https://msdn.microsoft.com/en-us/library/windows/desktop/ff729480(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ff7... Also, XAML has been fully rewritten in C++ for UWP, consumed by .NET Native as UWP components.
    - Jaruzel 9y ago
      I sit corrected. ta! :)
    - polskibus 9y ago

ricg 9y ago

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

rymate1234 9y ago
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!
- pjmlp 9y ago
  Well, that can be sorted out with a background task.
  - ricg 9y ago
    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.
    - pjmlp 9y ago
      The suspended even is the orderly fashion to save the data. An ExtendedExecutionSession with a SavingData reason, should be more than enough for any kind of data.
      - naikrovek 9y ago

alkonaut 9y ago

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.

dingo_bat 9y ago

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.

garganzol 9y ago
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.
- jenscow 9y ago
  But, would you consider UWP being appropriate with those types of applications? I mean, if an application is well suited for UWP, then it's probably better off as a web app.
  - mcaravey 9y ago
    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. https://www.microsoft.com/en-us/store/p/easypower-onsite/9nblggh5ggfk https://www.microsoft.com/en-us/store/p/easypower-onsite/9nb...

rmrfrmrf 9y ago

Enterprise isn’t Windows-only anymore. If you’re not targeting Mac and Linux, too, you’re doing it wrong.

jenscow 9y ago

UWP comes from the "cloud-first mobile-first" Microsoft. Neither are well suited to enterprise, and one of which has been canned.

lafar6502 9y ago

Ha ha it would be a progress if they dug out win forms and made it official api. And I’m not throwing away my Petzold

thebosz 9y ago

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. *Obvious hyperbole.

tinus_hn 9y ago

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.

jarjoura 9y ago

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.

vitorgrs 9y ago
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.