
WinUI, The modern native UI platform of Windows - pjmlp
https://microsoft.github.io/microsoft-ui-xaml/
======
klodolph
Win32, Visual Basic, MFC, ActiveX, WinForms, WPF, Silverlight, UWP, WinUI. (I
know these aren’t either/or alternatives, bear with me.)

I think Microsoft knows it needs (1) a way for developers to build apps that
look like they belong in 2020 (2) where the frameworks won’t find themselves
in the garbage within a few years. This “toolkit approach” seems to recognize
that the runtime is a _separate_ problem, so e.g. you can use Win32 + C++ +
WinUI, or you can use C# + UWP + WinUI and get something reasonably
consistent.

Maybe this is the time Microsoft gets it right. Who knows?

~~~
2bitencryption
You missed one!

[https://github.com/winjs/winjs](https://github.com/winjs/winjs)

~~~
pulse7
And another one: Windows Aero

~~~
contextfree
That's not a UI toolkit, it is/was a theme for existing UI toolkits.

~~~
theandrewbailey
Am I the only one who thought that Aero (Windows Vista/7) looked good?

------
blattimwind
Content advisory: 30 MB 720p gif unironically named "performance2.gif"

~~~
butz
Somebody read your comment and "optimized" it: meet "performance2-min.gif",
now only 12.52MB.

~~~
butz
When converted to MP4 the same video weighs only 2.46MB, and probably even
less if exported directly from source, not converted from gif, like I did.

------
fifticon
I have to work with WPF on a daily basis. What a nightmare, and how I miss
working with Qt. I wish the people responsible for WPF were forced to use it
for the rest of their lives. The grid layout is broken. The stackpanel is
broken. There are no sane defaults for anything. You can rotate any control -
WHY? Default stackpanel has no control spacing. WPF code throws no exceptions.
Bound comboboxes in datagrids have the performance of glaciers. Keyboard
shortcuts trigger the decades-old 'edit field contents only transfer on
killfocus' bug. Parent-windows and always-on-top is a mess. Live dom is
different from your static hierarchy. I've waited for fixes to the WPF mess
since.. 2007? I sense WinUI isn't it.

~~~
lostmsu
I am not heavy on UI development, but most of my experiences with WPF were
pretty good.

In what ways grid and stackpanel are broken? They seem to perform exactly as
designed (though I only have CSS to compare to, but it is magnitudes worse).

The fact, that core controls have no default spacing seems like a sane
engineering decision, considering you can set it app-wide with a few lines of
XAML.

Shortcuts sound like a problem for a specific scenario. The default binding
update on lost focus might have been a bad decision, but even given my little
experience I remember it quite well.

~~~
The_rationalist
Why CSS is magnitudes worse?

~~~
IshKebab
I have no idea about WPF but CSS was really designed as a document styling
system. It isn't very good as an app styling system: There's no scoping so
it's really hard to know which bits of an app any CSS affects, and really hard
to find all the CSS that affects a particular part of an app. It mixes styling
(colours etc) with layout (flexbox). Etc.

------
api
I don't want a new native UI for Windows. I want a cross platform UI.

I am _NOT_ developing the same GUI N times for N different platforms. No way.
Even very large companies like Slack are refusing to do that. They have the
resources to have three or four parallel dev teams but why?

I don't care how nifty, pretty, fast, or modern this new UI is. It's not cross
platform therefore it does not exist.

This is not a technical problem. Check this project out:

[https://github.com/andlabs/libui](https://github.com/andlabs/libui)

Yes it's minimal and rough around the edges, but it's the work of one
developer in their spare time. If one developer hacking away in the evenings
can do that, then there is no excuse.

If OS vendors keep insisting on being special and trying to herd developers
into making OS-specific apps, developers will keep going to bloated but
portable alternatives like Electron and Qt. Why is every new app an Electron
app? Don't blame developers or Electron. Blame OS vendors.

It's 2020. We have common portable APIs for threads, networking, even 3D
graphics, but not 2D GUIs. It's easier to write a portable cross platform 3D
rendering engine than it is to write a portable cross platform app with a
menu, a box, and a button. It's just offensive at this point.

~~~
Too
Actually using Unity, which is made to be a 3d engine, to write a 2D GUI isn't
such a bad idea when you take cross platform into account.

------
Topgamer7
Anyone else hate shrinking scrollbars? I just want it to be there, I don't
want to have to hover on it to have it actionable. I don't care the much it's
small, just so long as its there.

~~~
canada_dry
> hate shrinking scrollbars

IMHO there are many things to dislike about 'modern' GUIs!

Back when Windows was a relatively new concept common sense things like making
buttons stand out and using colour and borders to group and organize features.
These things have pretty much gone out the window. Everything is a flat
homogeneous dark scene.

/rant

~~~
zzo38computer
I agree; it is full of mess. I think Xaw is fine, although many things should
not need GUI at all, I think.

------
ComputerGuru
Better link: [https://github.com/microsoft/microsoft-ui-
xaml/blob/master/d...](https://github.com/microsoft/microsoft-ui-
xaml/blob/master/docs/roadmap.md)

This has actual technical details, the roadmap, the rationale, etc.

To those wondering: this does not offer cross-platform GUI. Microsoft’s
(inadequate) answer to that is blazor in browsers or browser controls. When
they say cross-platform support for WinUI they mean it can be targeted by
libraries providing cross-platform UI abstractions, the example they give is
react native.

~~~
s_y_n_t_a_x
Their answer to cross-platform is react-native. react-native-windows is built
on top of this.

They've also have been the ones leading the effort to add MacOS support to
react-native.

~~~
pjmlp
Actually React Native for those that are into C++, and Xamarin for those into
.NET.

~~~
s_y_n_t_a_x
Well if you want to contribute to the RN core then yes you'll use C++.

To write a RN extension for X platform you will write it in the language for
that platform.

To use a RN extension you can use any ECMAScript language.

~~~
pjmlp
You missed my point, Microsoft sells it as:

\- Windows shop deeply invested in C++ and wants to go cross platform? =>
React Native (playing the role of Microsoft's QML)

\- Windows shop deeply invested in .NET and wants to go cross platform? =>
Xamarin

------
etaioinshrdlu
No! Not another UI toolkit from Microsoft!

This is like yet another messaging app from Google.

~~~
wetpaws
Google messenging app powered by Microsoft UI toolkit when

~~~
battery_cowboy
That would live for an instant less than the planck time.

------
mappu
If you read "Qt" for every mention of "WinUI", all the platitudes still hold
true, and you additionally gain mobile, macOS + Linux support.

~~~
lostmsu
But then you have to program in C++ or JavaScript. I recently learned the
former (std17) does not have a string.split function in the standard library
(though I envy the random numbers library for scientific purposes).

~~~
mappu
_> But then you have to program in C++ or JavaScript._

Bindings are available for Python, Go, Rust, C#, Java, Crystal, D, Haskell,
Julia, Node.js, OCaml, and more besides:

[https://wiki.qt.io/Language_Bindings#These_are_third_party_l...](https://wiki.qt.io/Language_Bindings#These_are_third_party_language_bindings_for_Qt)
(non-exhaustive)

~~~
Klonoar
No, there are no good Rust Qt bindings right now - it's a bit of a byzantine
process to tie it all together.

------
jiggawatts
The WinUI project templates[1] have had about "600 installs".

Tells you everything you need to know about how excited Windows developers are
about yet-another half-baked UI framework that will likely never get critical,
required features before it is abandoned.

[1]
[https://marketplace.visualstudio.com/items?itemName=Microsof...](https://marketplace.visualstudio.com/items?itemName=Microsoft-
WinUI.WinUIProjectTemplates)

~~~
Jaxkr
Also, nobody is building native apps for windows anymore. Everyone is building
web apps because they run everywhere, and can easily be packaged as a “native”
application.

~~~
contextfree
Why are people still building native apps for other platforms? Doesn't your
second sentence apply to those too?

------
petilon
When Microsoft switched to Flat UI it lost all ability to control the native
UI platform of Windows. Thanks to Flat UI, native apps are indistinguishable
from Web apps. If ordinary users can't tell a native app from a Web app why
invest in native app, which only a subset of potential users can use? If you
use Electron then you can use web technologies, and everyone can use your app
including Windows users, Mac users, Linux users, mobile users and web users.

Yes, Electron requires more resources than native apps, but that's only a
problem if you're making a trivial app such as a calculator. If you're
building a substantial app then the fact that Electron apps require more
memory is usually not a problem. And that's the reason Microsoft themselves
uses Electron for Teams, VSCode etc.

~~~
tomc1985
This is the sort of logic that keeps a desktop-development plague like
Electron going strong

> Yes, Electron requires more resources than native apps

It requires _orders of magnitude_ more resources. Many of us are sick of
watching huge chunks of expensive computers' ample resources go to waste so
that some startup dweeb can avoid hiring actual desktop development people. It
is the #1 harbinger of the kind of resource inflation and lack of engineering
excellence that keeps people having to buy new hardware unnecessarily, but hey
who cares BeCaUsE mAh BaLaNcE sHeEtS

~~~
lordlic
> Many of us are sick of ...

Not many enough to matter.

> who cares BeCaUsE mAh BaLaNcE sHeEtS

It is an actual concrete fact that in many (most?) cases the total cost of
developing and owning an Electron-powered app is going to be lower than a real
native desktop application given that you can reuse the same
code/people/skills you already employ on your website and mobile app. Building
the same UI n times is crazy.

Are you just complaining about that fact or actually suggesting that we ignore
it and stand up against "resource inflation" as a matter of principle? I can't
imagine a startup CEO going before their board with a slide deck and saying
"We're making progress on a unified app experience across web and mobile that
should reduce our development costs. We were going to do the same thing for
desktop too, but then we realized that Engineering Excellence™ meant we had to
hire a whole new team of developers. No, the app isn't performance
constrained, why do you ask? Sure, everyone else is using Electron but
everyone else is _wrong_."

~~~
fifticon
You sound like one of the reasons the Epic Background Launcher takes up 293 MB
of ram when idling in the background.. I was recently trying to figure out why
my nephew's 16gig machine was running so slowly. It turned out, it was because
he had just installed loads of crap like that. I can now see, what he really
needed, was 32gig of RAM and 128 cores instead, to run your electron apps.

------
boromi
Can someone help me make sense of the million and one different UI platforms
on windows and why I should even consider looking into this? Being a Windows
dev is very confusing when it comes to UI

~~~
madhadron
Yes, macOS's approach of "Cocoa or GTFO" must be seen as as strength.

~~~
kristianp
It's really interesting to me that stark difference between MS's GUI framework
fire-and-motion, vs macOS's stability. Why couldn't MS do that? They have c#
vs macOS's objective-C, perhaps it's because MS wanted to have a decent C++ UI
framework, but the Windows-8/modern app direction they took added to the
fragmentation.

~~~
WorldMaker
WinUI 3.0 finally offers some of the "Carbon" to Windows 8's "Cocoa" (in XAML
Islands and better overall interop with Win32 and older OS releases).
Microsoft's attempt to go "Cocoa only" missed the "Carbon" stage that that
their own application teams internally warned them they would probably need
(as those same teams had warned Apple about in the originally "Rhapsody" plan
to skip an intermediate stage like "Carbon" entirely). Maybe after WinUI 3.0
has been out the door for a while and more apps transition to targeting WinUI
3.0 they can think about killing Win32 only and going "Cocoa only".

------
vbezhenar
They should just return to WinAPI. It works and looks good. Their phone
platform is failed, so those terrible UI are not needed anymore. Return to
Windows 2000 style, it'll look modern nowadays. Find out old code which
allowed for proper skinning and let users decide how they want their UI to
look.

------
monocasa
You'd think that Microsoft would internalize that even they strategically are
treating the OS as a commodity now, and wouldn't waste time on a platform
specific UI kit (even if it's their own platform).

Also, fool me once...

~~~
Rusky
> Also, fool me once...

To be fair, their past offerings still work fine, they're just in maintenance
mode. Which is exactly what a lot of people want- they stop changing and
everything you built with them just keeps working.

~~~
Ididntdothis
You also need a framework that stays up to date. As of now they have a whole
list of frameworks in maintenance but nothing that stays cutting edge. At
least we need a clear upgrade path which doesn't exist.

~~~
leetcrew
what do you mean by "stays cutting edge"? do you expect existing code to get
UI update for free? I would love to have that natively, but I'm not sure how
realistic it is.

I work on an application that targets both windows and mac. we have windows UI
code that was written ten years ago that still works and looks more or less
okay. on the other hand, every year we have to deal with breaking changes and
new bugs from framework updates on the mac side.

~~~
monocasa
I expect support for new stuff like touch events, hidpi, etc. even if it takes
some code changes on my side to use.

It's not like what's expected out of desktop GUIs have been completely static
over this time frame.

------
polskibus
Sad to see .NET core not supported (yet). I thought all new development was
supposed to target .NET core and now this ? Come on Microsoft, you can do
better (especially that NET 5 is coming in November)!

I wonder if WinUI is truly more performant than Winforms. Winforms hooks
directly into WINAPI. How can you be faster than that ?

~~~
huzaif
WinUI 3 supports .NET 5 :
[https://youtu.be/tasbSc3771A?t=186](https://youtu.be/tasbSc3771A?t=186)

~~~
polskibus
It says here [https://docs.microsoft.com/pl-
pl/uwp/toolkits/winui3/](https://docs.microsoft.com/pl-
pl/uwp/toolkits/winui3/) that .NET core is not supported, but maybe they'll
fix it by Nov.

------
gman83
"Works with your favorite cross-platform technologies."

Does this mean this can be used to create Desktop applications that work on
Linux & OS X?

~~~
contextfree
It's referring to React Native and Xamarin, whose Windows implementations are
built on top of UWP XAML/WinUI. Xamarin only supports Android and iOS besides
Windows. For React Native, there's additionally a Mac OSX implementation that
Microsoft has been developing. At one point Canonical was working on a desktop
Linux implementation but it seems to have been abandoned from what I can tell.

------
timw4mail
Meh, Win32 forever.

~~~
gridlockd
What exactly do you mean by Win32? GDI?

~~~
bmh
This is what a Win32 app's source code looks like:

[https://www.paulgriffiths.net/program/c/srcs/winhellosrc.htm...](https://www.paulgriffiths.net/program/c/srcs/winhellosrc.html)

~~~
leetcrew
maybe I'm just ignorant, but I always have a chuckle at stuff like this:

    
    
      wndclass.cbSize         = sizeof(wndclass);
    

why does a struct need to be told its own size?

~~~
Ididntdothis
Because different versions of the struct have different sizes. That’s a C
artifact.

~~~
leetcrew
I figured it's one of those structs where the macro can resolve to a few
different types depending on what's #define'd, but the implementation should
still be able to use sizeof wherever it's needed.

I do believe there's a good reason; I just can't figure out what it is.

edit for any curious readers: I found an answer here
[https://stackoverflow.com/questions/30416191/why-do-some-
win...](https://stackoverflow.com/questions/30416191/why-do-some-winapi-
functions-need-sizes-of-structs-passed-as-their-parameters/30416321)

~~~
Ididntdothis
You can and should use sizeof in your code. The Windows code needs to know the
size so it knows what version of the header the code was compiled against.
There are probably other ways to do this but sizeof is not bad. That’s how
they can get backwards compatibility over decades.

------
xpressvideoz
AFAICT, this doesn't seem to fix the performance issue of the modern Windows
UI, even though it claims so. I've always been saddened by the modern Photos
app taking several seconds to boot, compared to the good ol' Picture and Fax
viewer taking a blink. Considering this brand new UI toolkit is just a rehash
of the framework Microsoft were using internally, and probably also used by
the Photos app, how can we expect to gain a performance boost from WinUI, when
they cannot fix the performance issue of their own apps?

~~~
contextfree
The claims of improved performance are meant relative to web/Electron or WPF
apps I think. There's a lot more that affects app performance than the UI
framework it uses though ...

------
saagarjha
It's quite humorous to see a picture focusing on a Microsoft engineer clearly
holding up a 13", non-touchbar, MacBook Pro next to the heading "The Future of
Windows Development" ;)

~~~
RMPR
It runs Windows :D

------
arunc
> This project collects usage data and sends it to Microsoft to help improve
> our products and services. See the privacy statement for more details

Telemetry to help your own products or Microsoft?

~~~
alkonaut
Its usage/install stats for the product itself, so Microsoft. They make an
excellent free telemetry product if you want to use one in your own app.

------
moogly
As someone who used to make a bunch of WPF apps, and hated the framework from
day one almost 15 years ago (it was a half-baked, over-/underdesigned mess
that felt dated on release day, and was never updated to take advantage of
newer C# language features), did things ever improve with Metro or UWP?

At least they got rid of that buggy crash-prone Blend designer (that wasn't
truly WYSIWYG) and the idea of using DI for design-time data instead of just
doing hot-reloading during runtime (which I believe they finally embraced,
after AmmyUI showed the way).

~~~
moron4hire
UWP is WPF done right. You were right about the problem with WPF. The other
problem was that it was very different from WinForms. But WinForms was also
fundamentally broken, in a way that didn't appear until you had to make
anything larger than a basic calculator app. UWP fixed all of that. If you
take the time to learn it, it makes a lot of sense.

~~~
sqldba
That’s the first time I’ve heard anyone complement UWP. I thought it doesn’t
support anything useful like datagridview?

~~~
contextfree
Stuff like datagrid tends to live in the Windows Community Toolkit
([https://github.com/windows-
toolkit/WindowsCommunityToolkit](https://github.com/windows-
toolkit/WindowsCommunityToolkit)) these days. Though there's apparently an
effort to reimplement it natively in WinUI
([https://github.com/microsoft/microsoft-ui-
xaml/issues/1500](https://github.com/microsoft/microsoft-ui-xaml/issues/1500))

(one difference is that the WCT is mostly C# and WinUI/the built-in controls
are C++)

------
Fiveplus
I might be new here but don't understand the hostility of these comments. Can
someone chime in and explain?

~~~
bmh
First, there was Win32. That is still supported, and works reliably. It's a
plain C interface, and it works on all versions of Windows. You have to do
your own anchoring logic (ie all controls are positioned like HTML
'absolute'), and lots of stuff yourself, but it works, it's fast, and the docs
are good.

Then, in 2000, Microsoft gave us .NET and WinForms, and we all thought that
we'd be cross-compiling our C++ apps so that they ran inside of the hybrid
native/.NET compiler called C++/CLR, so that we could take advantage of this
improved UI toolkit. From C#, WinForms worked great. From C++, not so. But we
thought that maybe we could write our GUI in C#, and interface to C++ for the
heavy lifting/legacy code. I tried it a bit, and it was doable, but it ended
up being very clunky to have this giant divide between the .NET world and the
native C++ world.

Fast forward a couple of years, and Microsoft started talking up XAML, and
it's native Windows Desktop incarnation called WPF. It had a browser sibling,
which was Silverlight. This was a completely different to WinForms, and it was
the future of Windows UIs. I tried it a bit. It made your app startup slowly,
because it was now a .NET app. There were some interop issues between plain
old C++ code, and C++/CLR, but it was OK.

Not long after that, Microsoft started talking about Windows 8, UWP, and
Windows on ARM, and that's kind of where I lost track. With Windows 8, there
were going to be a variety of ways that you could build desktop GUIs. Some of
them seemed to be inherited from XAML. But now, instead of C++/CLR, you would
use some kind of COM 2.0 thing. So you didn't need to build a hybrid .NET app,
but the API wasn't great. In addition, Microsoft supported some kind of HTML-
based app - which was some kind of thing inspired by Electron... but running
on the IE engine instead of Chromium.

And now... this.

I don't know what most people ship these days, when they build Windows UIs.
It's a mix of Electron (eg Slack, VS Code), as well as QT, and good ol' Win32,
that we've had since the 90s.

So this is why people are tired. Microsoft keeps shipping yet another UI
framework - and the people have stopped believing that they can invest in this
thing, which is inevitably going to be replaced by yet another thing in 3
years time.

If you stick to plain ol' Win32, you can be pretty sure your app will be
trivial to compile and run for decades, so that's what I do for little Win32
UIs.

~~~
asveikau
The thing about especially some of the more recent efforts is: the approach
might have made sense when Microsoft was a monopoly and there was lots of
interest writing software for Windows.

But suddenly targeting Windows is much less interesting, but they still have
the monopolist's arrogance: "You will rewrite your app to work on our new UI
framework, right? Right...?" What actually happens is that every deprecation
and every new thing weakens their ecosystem. Their biggest draw is in legacy
software, and they variously want to throw out their legacy support, or create
tomorrow's legacy today with new frameworks that end up abandoned.

~~~
pjmlp
I still find interesting being able to target 85% of desktop systems,
including laptops and 2-1 detachables out there.

And a large majority of factory and laboratory automation control systems.

------
lordlic
Setting aside all of the discussion about Microsoft's perennial new UI
frameworks... does anyone else really dislike the Fluent design language? It
feels weird and mobile-optimized and spaced-out and infested with odd special
cases, and it seems like every classic-style Windows component they replace
with the new style of UI gets simultaneously dumbed-down and harder to use.
When Google released Material Design I didn't like that either, but it's grown
on me. Fluent Design still hasn't clicked with me.

~~~
fifticon
Amen bro. What I lament the most, is that navigation guidelines that seemed
set in stone between 1987 and 2005, are starting to slip. Things like how to
navigate with keyboard, or that typing in a list will incrementally-search to
what you typed, seem to fall away. E.g. the "Apps and Features" screen in
windows, will not let you type directly in the scrolling list. However, I can
see that after some recent windows update, the screen now has a Search field,
god forbid.

------
RMPR
> With 1 billion devices running Windows 10

Just like Java

------
ourmandave
The github initial commit was 16 months ago.

From github...

 _The Windows UI Library (WinUI) provides official native Microsoft UI
controls and features for Windows UWP apps.

WinUI is the easiest way to build great Fluent Design experiences for Windows.

WinUI can be used in any Windows 10 UWP XAML app, or in a Xamarin.Forms app
running on Windows 10 using native view embedding._

------
alkonaut
This feels...complex. Why the strange app models (uwp, xamarin)? Where is the
normal support for just firing this up in any desktop app written in any
language? I don’t want to learn about xaml islands or fear that a browser
runtime somehow loads into my app. Is this product not for me?

~~~
contextfree
The point is supposed to be that it can be optionally used with any of those
app models or cross-platform frameworks, not that it relies on them ... but I
guess it didn't convey that to you clearly enlough?

~~~
alkonaut
Not clear enough no. A minimal hello world with the smallest possible examples
for different languages would be good.

------
kyberias
It's utterly confusing. What is the recommended upgrade path for classic WPF
.NET Framework apps?

~~~
Ididntdothis
The only upgrade path is to rewrite large parts of your app.

~~~
miffy900
Well no, one upgrade path is to port to .NET Core 3.1 which supports WPF apps.

------
gigel82
They seem to be putting a lot of effort on React Native for Windows and Mac
([https://github.com/microsoft/react-native-
windows](https://github.com/microsoft/react-native-windows)). If you don't
want to go full Electron, I think React Native ticks a lot of boxes (cross-
plat, accessible for entry level/JS developers, native performance for the
most part).

The thing that was missing before was a nice UI framework to go along with it;
hopefully this WinUI thing addresses that.

~~~
nathanaldensr
Unfortunately, React Native is inherently tied to UWP and the Microsoft Store,
which are both utter failures IMO. When people use Windows they expect an open
computing environment. They expect custom installers, apps that can scan other
process' memory (e.g, Cheat Engine), etc. They don't want Apple's walled
garden in Windows. This is _especially_ true in corporations where IT, _not
Microsoft_ , act as the ultimate authority over a machine.

~~~
contextfree
RN isn't tied to the UWP app model nor the Store. It's built on the UI
framework that was created for UWP, but (as the link for this thread
mentions), that can be used outside the UWP app model (currently via XAML
islands, in future via WinUI 3) and apps in the UWP app model can be
distributed outside the Store anyway.

In my personal opnion, it might be a good thing that apps that can read each
others' memory, etc. can exist, but they shouldn't be the default, users
should have to explicitly opt in to allowing that, and not in a way that will
become just another dialog box for most people to mindlessly click OK on.

------
kozak
Maybe it's because I'm not a native English speaker, but I fail to grasp how
"blistering performance" is supposed to sound like something good.

~~~
twojacobtwo
The Merriam-Webster[0] dictionary offers the following definitions that might
help:

1: extremely intense or severe; "blistering heat"

2: very rapid; "a blistering pace"

[0][https://www.merriam-
webster.com/dictionary/blistering](https://www.merriam-
webster.com/dictionary/blistering)

------
baybal2
It took only few years for them to dump UWP, they are going full google now.

P.S. Actual download link:
[https://aka.ms/winui/alpha/projecttemplates](https://aka.ms/winui/alpha/projecttemplates)

~~~
contextfree
WinUI is basically just another name for the UI framework from UWP, just
decoupled from the OS and with the namespaces changed from Windows.* to
Microsoft. _

~~~
baybal2
The it has become an abandonware to an even bigger extend? Is this their
signalling?

~~~
contextfree
? it's not an abandonware if they're working on major upgrades?

------
steeve
Every UI toolkit on Windows is/was based on Win32 (except XAML). There are so
many places where it leaks it's not even funny anymore.

UI consistency isn't Windows strongest point. I'm glad they're trying to fix
it.

------
uk_programmer
I am going to echo other people's sentiments with this. I am very hesitant to
even bother looking at this because it yet another UI platform for Windows.

WPF, UWP, SilverLight, Metro. Am I forgetting any?

~~~
ben509
If you sift through enough settings panels and preferences dialogs, you should
see everything going back to DOS widgets in there.

~~~
MikusR
Wbat is a DOS widget? The earliest stuff is from Windows 3.1.

~~~
indeyets
Turbo vision
[https://en.wikipedia.org/wiki/Turbo_Vision](https://en.wikipedia.org/wiki/Turbo_Vision)

~~~
MikusR
And where you can see it in Windows 10? Honest question.

------
yardie
At this point I'm going to stick with React. And I wrote a few applications in
XAML. And got hell for it from other developers who prefered Win32 and MFC.

------
The_rationalist
They claim to be interoperable with electron Cf _Works with your favorite
cross-platform technologies_ What does this actually mean?

------
markus_zhang
Can they just sack people instead of projects?

------
dvfjsdhgfv
Can someone confirm as it's not clear from the article: WinUI apps will run
_only_ on Windows 10, correct?

------
maxmalysh
I see no reason to use this proprietary Win10-only Microsoft framework instead
of HTML + JS + Electron.

~~~
bigown
It's open source.

------
hizxy
“Modern UI” is not a selling point.

------
ezoe
Another half-baked framework that will torture the unfortunate developers.
There is no reason to use these mess except if you're writing a software for
MS-specific niche platforms such as HoloLens, XBox and alike.

For UIs that can be achievable by web browser, we use web browser. For video
games, we use dedicated libraries. For native utility programs, we use cross
platform libraries or maybe native libraries.

They added yet another half-baked library that only works on MS products and
the only developer who has a misfortune to use WinUI will be the one who has
to support very narrow platform(one specific model of MS hardware) with the
demand of very narrow customer(just one company asking a utility tool and
specify the exact UI library it use).

Everyone should read the xkcd 927 before inventing their own yet another
library. [https://xkcd.com/927/](https://xkcd.com/927/)

------
bassman9000
Remember telemetry: [https://github.com/microsoft/microsoft-ui-
xaml/blob/master/p...](https://github.com/microsoft/microsoft-ui-
xaml/blob/master/privacy.md)

------
MR4D
Shame they didn’t make this 64-bit only.

------
layoutIfNeeded
I bet it will be abandonware by 2023.

------
WhyNotHugo
Can someone explain exactly who this targets?

Outside of Microsoft (including Office), who actually develops native windows
apps which would use this any more?

\- Things like games or steam don't use native+OS-specific UI. \- Internal
company software (including finance, etc) seems to always be web-based. \-
Tools like slack, etc all seem to be Electron.

Any "off-the-shelf app" will probably want something that's cross platform --
I don't think anyone targets "windows only" any more, right?

~~~
alkonaut
I’m guessing 90 or 95% of enterprise desktop apps (trading, cad, Point-of-
sale, medical, ...) is windows like they always were. Sure, a lot is moving
from the desktop because it should be webapps, but few companies outside a
very small niche (those that make apps for broad markets of consumers like
Spotify or Slack) worry about cross platform.

The exception is and always was media creation, where Mac always had a
foothold.

But for every normal boring enterprise out there, so long as every customer is
a business where everyone runs windows, that’s your target.

------
jokoon
To be honest, I would prefer OSes to just offer some rendering primitive
instead. Remove the "layers of crap" (I'm quoting John Carmack), and let
developers do whatever.

At this point HTML+JS is one option that gives a good amount of flexibility
and support, and it looks like OSes should just be a browser. In my view, any
OS should be able to use any windowing manager at the same time, provided they
can use the same rendering core.

I like building simple interfaces using SDL or SFML, and as long as you only
redraw when needed, it's just good enough. The godot editor works that way,
that's how it's able to work on all platform: you have a small throbber that
turns indicating when it's redrawing.

~~~
lmz
That kind of interface will be "interesting" to use while blind.

