
WinUI – The modern native UI platform of Windows - pjmlp
https://microsoft.github.io/microsoft-ui-xaml/
======
flowerlad
Flat UI has been the downfall of the Windows UI. Firstly, it is ugly.
Secondly, it is not intuitive. Thirdly, it is hard to differentiate from Web
apps.

From a developer point of view that last point is very important. If your
native app is not going to look or feel any different than an app built using
Web technologies why limit your customer base to Windows users?

Sure, native apps are better at reducing resource consumption but if your app
offers significant functionality users won’t mind if it uses some extra
memory. This is the reason Microsoft’s own Teams and VS Code products were
built using Web technology.

Another issue from a technical pov is that XAML, MVVM and 2-way data binding
are outdated. MVVM introduced 2-way data binding to the world. Since then
every JavaScript framework copied 2-way data binding including EmberJS and
Angular. Today we know 2-way data binding is gimmicky and makes programs hard
to debug. This is the reason React uses unidirectional data flow.

~~~
sergiotapia
>Today we know 2-way data binding is gimmicky and makes programs hard to
debug. This is the reason React uses unidirectional data flow.

Uh no we don't. I've spoken to a lot of engineers who curse redux and the
entire ecosystem around it. The reality is, 99% of apps don't need that kind
of craziness. "time travel debugging" is a meme. I'm tired of it being
highlighted as some insane victory. Over what exactly?

~~~
ncallaway
This is super confusing to me, because you're talking about your dislike of
redux, when it wasn't brought up or mentioned?

~~~
sergiotapia
Are you really super confused, or just pretending?

~~~
ncallaway
I was confused. The reply wasn't really responding to the parent comment.

------
asciimov
I'd love to know what group or person at Microsoft decides what looks "good".
I want to know why they decided to go the direction that they have, and why
exactly they cant get everybody on board to go the same direction.

My guess is there was probably one design committee that decided that things
needed to look different, because the "future is now", we can't remind people
of older versions of windows because visually that isn't progress, and we
can't be reminiscent of the "bad old days" when things crashed often.

Then after that committee makes it's decree, everybody who has control over
their own little gui fiefdom each decides "nah.. that looks terrible and we
aren't going to be cohesive, so lets do our own thing over here."

And so, everything looks and acts a little different. Since not everybody got
on board with the change, the original committee digs in their heels and says,
"Well it obviously doesn't work because not everybody is on board with OUR
design."

~~~
ksec
I think Steve Jobs puts it best;

 _The problem with Microsoft is that they “simply have no taste.”_

Windows has always had their Windowish / Microsoftish smell to its design.
Much like Linux, You could spot a linux desktop from 100 miles away. And
everyone thought these were simple you could just copy it. Turns out there are
trillions of small details that make it all coherent and beautiful.

~~~
wayneftw
I think I put it best: "Apple likes to make people think they have taste and
that they're good at design, but they're actually really, really bad at design
and their tastes are quite obviously very shallow."

Windows and all the Linux desktop environments that copied Windows have so
much more functionality than the brain-dead macOS that can't even get basic
features like window management right.

Imagine thinking an OS that won't let you easily maximize or snap application
windows is any good?

~~~
asdff
You can do those last few things pretty easily, by the way, but the desktop
philosophy of macOS is just very different. It functions a lot like a real
desk. Things are sized however they are meant to be sized, and you kind of
pile them up. I don't line up things on my desk edge to edge maximizing space,
its not necessary as some overlap and slop is fine. Apple has a lot of tools
with sorta redundant functionality that make it easy to sift through the pile
and see everything at once. Three fingers swiped up on the trackpad spreads
everything out on your desktop, just like spreading out papers on your desk.

It might seem like an issue if you are coming from a tiling window management
environment, but over time it becomes quite familiar and intuitive to use
because of all the parallels with the physical world and how we interact with
physical objects. I have tried the tiling window manager route, and it's more
clumsy than anything imo.

~~~
rrrrrrrrrrrryan
Parallels to the real-world certainly make technology easier to learn, but not
necessarily easier to use, and I'd argue it goes against the main benefit of
computing - simplifying physical processes through abstraction.

You could design a VR environment that lets you walk around your virtual
house, open your virtual front door, walk down your virtual driveway to your
virtual mailbox, pull out virtual envelopes and open your virtual mail, but
you'd just be replicating all the old real world cruft that doesn't matter to
achieve your goal. What you really want is just to read some text in an email.

I had an older professor in college who still read and replied to all of his
email via terminal, and he was multiples faster than those of use that used
Gmail, but I remember thinking I'd never devote the time to learn to do things
this way when the way I'm used to works just fine.

Apple has done a tremendous amount to make technology more approachable, and
in doing so has brought millions into the digital age, but I do think the
pendulum has swung a bit too far - a monitor isn't a desk, it's a monitor. Too
much value is placed on "intuitiveness" these days, and while those real-world
parallels might feel nice to interact with, there's a time to disavow
ourselves of them to take full-advantage of what the technology can be.

------
naetius
A word of advice: I'm well in my 30s but I often feel like an old ranting
fart.

Every time I read of some new amazing framework like WinUI or SwiftWUI or
whateverUI, I always stop and wonder: will applications written with this
thing today ever run unaltered in 10+ years from now?

Microsoft has been doing an amazing job in these past 30+ years in keeping
things working: stuff written on Windows 95 can still run without any
particular issue on Windows 10. Sure, there's a bit of "cheating" here and
there to keep the compatibility working but the bottom line is: there's
retrocompatibility.

As an example: if a developer wants to use Win32 to write something on
Windows, it's still possible and it _IS_ still supported, with APIs that
basically didn't change for like... ever?

Apple seems to be on the far side of the spectrum: they have amazing
technologies but - as a developer - I always feel I have an immense work to do
just to keep up and allow my code to keep working as it used to.

So, the question for the community here is: how can we balance the "sugary" to
make things as accessible and sustainable as possible with the "stability"?

~~~
fxtentacle
Sadly, most OS X developers notice way too late that the constant pressure to
support what feels like 100 different OS versions makes their app financially
not viable.

At least that's been my experience: Plenty of OS X apps abandoned after each
major update.

~~~
mikhailt
Can you name at least two apps that has been abandoned? That hasn't been my
experience at all with macOS.

I don't have a single app that was abandoned. BBEdit, 1Password, Little
Snitch, MailMate, Tweetbot, Typinator, Rocket, and many more are all still
updated when need be. Key note is "need", stable apps do not need constant
yearly updates.

In addition, you can say the same thing about Windows. Metro, UWP and previous
attempts didn't go anywhere either, their MS Store is pretty much a flop.
(Granted, MAS as well).

Linux...it's not bad but there are issues with various UI frameworks, stores,
etc. GTK/QT, Flatpak, snap, etc.

~~~
fxtentacle
Most painfully [https://www.dragthing.com/](https://www.dragthing.com/)

Also, the original Overdrive Mac app. I believe they still don't have a
replacement Mac app.

The official ReadItLater app, the service is now called Pocket btw.

That Caffeine app to prevent the laptop from sleeping.

iTunes

Adobe Fuse

Google Picasa

~~~
odysseus
You can replace Caffeine with Amphetamine.

Some minor aspects of Dragthing can be replaced with Siracusa’s app
Switchglass.

As for Overdrive, does Libby work on the Mac?

~~~
fxtentacle
I don't know. My library has since switched to the Tolino app.

And since most of my pro audio apps also stopped working on OS X and the USB
dongle works the same with Windows and Mac, I myself also abandoned OS X for
productive work.

------
t0astbread
Clicking through to the repo behind I see this in the README:

    
    
      Data/Telemetry
    
      This project collects usage data and sends
      it to Microsoft to help improve our products
      and services. See the privacy statement for
      more details.
    
      For more information on telemetry implementation
      see the developer guide.
    

This has been probably my biggest peeve with C#/.NET so far. I actually like
the language(s) and the ecosystem but why does everything from Microsoft need
to contain telemetry? Like, Visual Studio okay, it's a fairly large
application and architecting it might need some intel on how people use it
(even though I believe you can do without but I'm not an expert). But the
dotnet SDK? That's just a punch in the gut, especially to developers who
oughta be more enlightened on tracking/privacy concerns than average users.

And I know you can opt out but I've done that and still seen dotnet make
network requests on runs. Maybe it's essential for the functionality but I'm
having a hard time trusting a company that puts telemetry in their SDK.

Which opens the question: Who else is doing this? I know JetBrains has some
telemetry in their IDEs (although like I said IDEs are more justified I think
and I haven't tested their opt-out). choosenim also recently asked me if I
wanted to report anonymous usage data. What about npm? The Rust stuff? How
much hidden telemetry is there inside developer tooling and what can we do
against it?

It would be neat if there was some sort of database for this. Kinda like what
Exodus Privacy[1] is doing for Android apps.

[1] [https://reports.exodus-privacy.eu.org/en/](https://reports.exodus-
privacy.eu.org/en/)

~~~
thunderbong
Honestly, I'm really getting tired of this peeve that everyone seems to have.
Every site is practically tracking everything. Emails are not private. Every
damn mobile app is trying to access all it can. COVID-19 isn't doing any
favors either.

And when someone creates an open source product with this clause in the README
right up front along with the option to opt-out, people get peeved about it?

I can understand if the norm is to NOT collect data. But since the world
doesn't seem to work that way, despite what some techies would want (since all
this tracking has been created by techies anyway), I think it's time to grow
up and face the real world for what it is - avoid where we can, adapt in our
own ways where we cannot. And try and not get peeved.

~~~
roblabla
The norm isn't to collect data when it comes to development tools. In fact,
Microsoft is very unique here. As I said in another comment, they're the only
SDK in widespread use that has telemetry that deeply ingrained.

~~~
pjmlp
Sure it is, Apple, Google, IBM, Oracle, SAP, Eclipse, JetBrains and plenty of
others do it.

------
tvanantwerp
Is it me, or does this landing page for a UI platform contain very few
examples of what that UI looks like and how you might use it?

~~~
Someone
You wouldn’t use it, you would fill in a form to get access to the “Alpha
Insiders Program”
([https://www.research.net/r/WinUI3AlphaInsiders](https://www.research.net/r/WinUI3AlphaInsiders)),
and (possibly) hope they let you in.

As another answer said: (for now) this is targeted at the enterprise.

~~~
byproxy
Is it strange that they're using SurveyMonkey and not Microsoft Forms?

------
jbb67
I don't know about anyone else but when I get a new program and it turns out
to be using a "modern" looking API I just assume it's going to be awful. Not
just the UI but everything about it. I've rarely been wrong.

~~~
aikinai
Interestingly, I think this is the opposite in the Mac ecosystem. If an app
uses the latest APIs and design trends, I expect it to be well crafted and
cared for and am also rarely wrong.

~~~
remir
I agree. I feel like the developers in the Mac ecosystem actually love
developing apps for it and it shows.

------
petargyurov
There's something strange about the new flat UI that Windows uses that doesn't
convey that my actions are doing anything.

For instance, making changes in Settings feels... flat... I can't tell if
something is loading or if my system is hanging or if nothing happened! I
really don't like it.

~~~
SturgeonsLaw
Personally I've always disliked settings panels that apply the moment you
click a control. I like being able to hit OK, or better yet, click Apply and
see the button then get greyed out as a little visual confirmation that the
settings have applied.

~~~
toyg
I can tell you that that behaviour is learnt. People unfamiliar with classic
desktop paradigms find annoying and confusing to have to confirm a choice
they’ve already made.

The most intuitive setup, imho, is to apply the change immediately, but also
materialize some sort of UNDO button to revert back.

~~~
asdff
Sometimes you are doing multiple changes at once, at which point it's better
to have an apply. Take a game. Change the resolution, delay. Change the
textures, delay, Change the shadows, delay. Change vsync, restart. I could
wait the 30 seconds between every click twiddling my thumbs, or I could just
click it all at once and restart the game.

~~~
kevincox
This makes sense when applying changes is expensive. If applying the changes
is cheep (or invisible while the settings dialog is open) then you don't need
the confirm step and you can do it immediately or when the dialog is closed.

(just have a good undo option)

------
hermitcrab
MFC, UWP, WPF, WinForms etc. I wonder how long before this is superceded in
turn?

My 3 applications are written in Qt/C++. Hopefully it is going to shield me
from this, as it has from the previous changes.

~~~
toyg
Yeah, MS has been very inconsistent of late. They went from Chen-style
decades-long support for foundational tech, to a whirlwind of different
things, promoted then chucked aside like they were a Google product.

~~~
MaxBarraclough
> then chucked aside like they were a Google product.

They're still supported though, right? (WinForms, WPF, UWP.)

~~~
toyg
Yeah but at one point the future was WPF, then it was Silverlight, then it was
Javascript...

~~~
MaxBarraclough
Sure, they keep inventing new GUI toolkits for little reason, but unlike
Google, the old ones can still be relied on.

~~~
nxc18
Not really, a bunch of apps from the WinRT era are very broken under Windows
10. It’s disappointing given how much from the early 90s still works, but code
from 2013 is now totally broken.

~~~
int_19h
Silverlight is where things have started to go downwards wrt long-term
stability. But Win32, MFC, and WinForms are still very much alive and well. I
mean, WinForms even got .NET Core treatment and high/dynamic DPI support.

------
fmakunbound
Is there some WinUI 3 application code I could compare with a
AppKit/Qt/whatever? I look all over, and surely must have missed something
obvious before getting lost in XAML Islands, WinRT, WinUI2 and other random
shit.

~~~
mikhailt
There aren't any as far as I know (if you're asking for actual real life
code), WinUI 3 is still very alpha stage. The first actual release is going to
be later this year with .NET 5.0 release.

You can look at their community toolkit preview here if you just want to see
some code: [https://github.com/microsoft/Xaml-Controls-
Gallery/tree/winu...](https://github.com/microsoft/Xaml-Controls-
Gallery/tree/winui3alpha)

Even then, we won't know for a while as most devs aren't likely to switch on
day one since it will have to be justified from current working stable
codebase.

------
longtermd
I don't even see any screenshots of WinUI there. Is there an obvious link
anywhere with tons of screenshots of how it actually looks like?

~~~
jsf01
Apparently there’s an app you can install (if you are running Windows) through
the Microsoft store that demos each component. Why wouldn’t they just throw up
some screen shots? Beats me.

~~~
vegardlarsen
XAML Controls Gallery on Windows Store: [https://www.microsoft.com/en-
us/p/xaml-controls-gallery/9msv...](https://www.microsoft.com/en-us/p/xaml-
controls-gallery/9msvh128x2zt). Source on
Github:[https://github.com/Microsoft/Xaml-Controls-
Gallery/](https://github.com/Microsoft/Xaml-Controls-Gallery/) (see
winui3alpha branch).

~~~
singhrac
Honestly, this looks terrible. Even though Windows hardware has gotten much
better over the years, and Windows 10 is a much nicer OS, you can tell that
the developers in their UI frameworks don't sweat the small details.

All of the screenshots are lowish resolution. In the second screenshot, the
spacing on the icons is funny (more bottom margin than top). Blue on dark gray
is hard to read, even for someone with young eyes like me (I cannot imagine my
parents enjoying looking at that). In the first screenshot, the code isn't
syntax highlighted (I also think the font is not monospace, which is just
appalling).

------
sjmulder
I'd like Microsoft to succeed with a new vision for the Windows desktop but
IMO the current style isn't it.

As for the framework itself, it seems needlessly complicated to get started.
The XAML based frameworks use a whole different paradigm from web development
or classical RAD tools.

And it's hard to take Microsoft UI frameworks seriously when they hardly use
them outside of the core Windows apps. VS Code, Teams, even the VS installer
are all Electron apps.

~~~
Ididntdothis
"And it's hard to take Microsoft UI frameworks seriously when they hardly use
them outside of the core Windows apps. VS Code, Teams, even the VS installer
are all Electron apps. "

that's the problem. How can you have faith in their frameworks if they don't
use them themselves?

~~~
badsectoracula
It isn't just having faith, by not using these frameworks themselves they are
not "dogfooding" them to find issues.

------
S_A_P
I really tried to get into WPF a while back, I learned PRISM and MVVM and
tried to go all in. What I found is that _most_ of the time when I build a
tool or a windows app its usually a tool for automation or data manipulation.
What using MVVM did was make the UI take 3x longer to build, usually (and this
is my admitting Im not a designer) would not be as easy to use or read as
standard winforms, and honestly was complexity for complexities sake. I still
use plain old winforms and c# and can make really usable, skinnable UIs with
my DevExpress controls. Maybe if I were building an app that had requirements
for chat, multimedia or some other use case that I dont need the Xaml ui
paradigm works. I dont like Flat UI, and I personally think that the UI in
Teams and One Note are a step backwards in usability. I had a PC that for a
specific reason needed to have hardware acceleration disabled for the video.
What that meant was that OneNote was broken. The UI would not display
correctly- the note pages were blank unless you grabbed the UI with your mouse
and moved them slightly. Winforms just works on every windows box...

~~~
int_19h
You don't need to use MVVM for WPF - it's a design pattern, not a framework
requirement. If you prefer the typical WinForms approach of just handling
events directly and manually managing the data flow and actions in those
handlers, it can totally do that.

------
rsynnott
Okay, so if I was making a video to demonstrate "Unmatched Native
Performance", I'd probably try to avoid making it rather jerky, but that's
just me.

~~~
garaetjjte
Well, it's GIF (slightly unexpected in 2020)

------
royjacobs
It's such a shame this isn't a cross-platform UI toolkit. I'm not implying
that I think this is the best toolkit or anything, but we can definitely use a
bit of competition in that space (although kudos to Qt, they're doing an
excellent job).

~~~
jayd16
Isn't it? Or is the bullet point implying they have a windows only DLL you can
use in cross platform languages?

~~~
royjacobs
I don't think this will run on MacOS or Linux? I'd be happy to be corrected on
this :)

------
gjsman-1000
WinUI 3 is VERY DIFFERENT than WinUI 2. It's a full UI layer that you can run
on UWP and Win32. [https://microsoft.github.io/microsoft-ui-
xaml/about.html](https://microsoft.github.io/microsoft-ui-xaml/about.html)

~~~
topspin
Is that a good thing or a bad thing? It could go either way with approximately
equal probability.

~~~
nxc18
It’s very bad because if you’re a C# developer you now have to worry about
which COM apartment your Window is in and you get silverlight era error
messages when something breaks.

------
Thorentis
Linux, amazingly, has some of my favourite UIs right now. It used to be
different. I used to hate the Linux UIs, and preferred Windows 7 or OS X. Now
that Win 10 is dominant, and I can't justify a new MBP (though I still love my
2015 MBP), I've jumped to Linux Mint. The UI is clean, easy to use,
uncluttered, has obvious affordances. It isn't quite as polished as Win 7 was,
but it's better than this new crap.

~~~
badsectoracula
The main issue with UI on Linux is that toolkits have a higher churn than in
Windows - this is because there isn't really "Gtk", "Qt" or whatever, but
"Gtk2", "Gtk3", "Gtk4", "Qt4", "Qt5", etc (and i'm sure that if i mentioned
"Qt3" i'm sure someone would point out that nobody uses that anymore :-P).

Writing something in Win32 will ensure it will run in 10 years from now and
chances are it'll also run 20 years from now. As a user you have a very high
chance of finding applications that work regardless of when they were made. As
a developer you can focus on your tasks without wasting time to "upgrade" to
the latest fad (Microsoft does release new toolkits, but the old stuff keep
working and Win32 is the stablest of them all). And your knowledge will still
be perfectly valid, no need to waste time learning how to do the exact same
stuff in a different way.

Writing something in Gtk3 (the current stable one) will ensure... well, once
Gtk4 is stable, Gtk3 will be deprecated and the one to avoid. Qt can't even
remain stable in the long term if they wanted (though they do not seem to want
to - after all Qt is middleware targeted to application developers, not a
platform component regardless if KDE pretends that it is) because of C++. As a
user you are limited in the applications you can find and have to keep around
all sorts of different toolkits - which wouldn't be that great of an issue
(hard disk space is cheap) if those toolkits were still supported and
compiled. Except the only distribution i'm aware that provides -say- Gtk1 is
Slackware and Qt4 is already on its way out by most distributions. Gtk2 will
soon follow (and perhaps some distributions will already have it dropped). As
a developer you have to chase after the brokenness that Gtk and Qt developers
introduce (though TBF Qt seems a bit better here, probably because they are
getting paid by selling Qt licenses and they cant annoy the developers using
Qt too much) and waste time "keeping up" just so that your _existing_
application will keep working.

Above X there aren't any stable UI APIs (unless you count Athena but that
hasn't received any updates since the 80s - even the updates 3rd parties made
during the 90s to improve its look a bit never became part of the "official"
distribution). And people want to get rid of X's stability too with Wayland.

~~~
jfkebwjsbx
> Writing something in Win32 will ensure it will run in 10 years from now and
> chances are it'll also run 20 years from now.

This, so much.

And they will likely work on Linux and macOS through Wine, too!

~~~
badsectoracula
Yeah, it is kinda amusing that one of the stablest ABIs for GUI applications
on Linux is the Windows one :-P.

Sadly the Wine GUI controls, while they work, always felt off to me and have
multiple minor issues. But at least they work. I think a big reason is that
despite libwine being usable as a general purpose toolkit for (ELF) Linux
application, it never saw much use as that so these issues were never paid
much attention.

~~~
jfkebwjsbx
Indeed, the Wine controls could use some help.

It would be great if someone could provide a new renderer based on Vulkan, for
instance.

~~~
badsectoracula
Vulkan would make things more complicated and wont really fix anything (if
anything it'll make things worse because that added complication will make it
harder to fix things and most likely will break compatibility with anything
not supporting Vulkan - e.g. older and/or weaker devices and other OSes like
macOS) since it isn't really rendering that is the issue but behavior (there
are also some drawing issues but those are at the GDI level and you do not
want to break GDI).

~~~
jfkebwjsbx
Ah! I was referring to the graphical issues. Behavior is more important, of
course.

By the way, Vulkan is "supported" on macOS thorough MoltenVK which is provided
by Khronos under a permissive license (although they don't develop it).

------
ilmiont
The webpage thinks it’s wonderful but in use it’s ugly, slow, distracting and
horribly optimised for desktop use - everything is too big and bold and it
creates cramped UIs where controls are needlessly hidden in menus.

------
fareesh
This is nice until you click into some settings menu and a UI from 1995 shows
up

~~~
petargyurov
This is something that really annoys me about the current state of Windows.
They're clearly going for a gradual changeover to the new UI.

Yet I would much rather use the "old" style Control Panel than the new
Settings page.

~~~
Ididntdothis
"They're clearly going for a gradual changeover to the new UI"

this has been going on for about 8 years with no end in sight. I wouldn't call
that gradual.

~~~
asveikau
If it started 8 years ago and hasn't ended, I would call that gradual, in the
sense that it is a slow process.

~~~
Ididntdothis
"Half assed and unfocused without clear direction" is probably a better term
:-)

~~~
asveikau
I guess gradual implies that there are grades, degrees, phases, perhaps a
solid plan.

------
0xDEEPFAC
Spongebob was right - everything in the future will be a chromium-based web
app:

[https://www.youtube.com/watch?v=_p6tvs-
qjpA](https://www.youtube.com/watch?v=_p6tvs-qjpA)

~~~
imhoguy
I hope everything will corrode into Rust soon.

------
jzer0cool
I felt liked the Metro design which felt hip, new, and modern when first
coming across while developing an app for a windows phone back around 2013.
But they lost the phone os battle to iOS and Android.

~~~
tonyedgecombe
I still think it was a huge misstep to push Windows down the tablet route. If
they wanted that sort of device they should have extended the phone operating
system to it. It really does feel like the worst of both worlds.

~~~
XorNot
Windows CE had a really nice developer experience IMO. Visual Basic worked on
it! Knocking together basic data entry mobile apps was within the range of
anyone who can do advanced Excel.

This might be of questionable value to "real" developers but the business
value of this type of power is immense and gets things done that would be
unaffordable to do today.

------
snvzz
Remember Metro?

The lesson is to not jump onto the new fancy thing, as Microsoft might just
drop it in a year or two, and it will all have been wasted effort.

Just use good old and tested. Or portable (e.g. wx).

~~~
oaiey
Just that Metro / UWP / WinUI are the same linage and therefore has some age.
Whether it is relevant ... different story.

~~~
DaiPlusPlus
It's only relevant because it explains why this WinUI3 is still using XAML,
even though XAML is extremely painful to work with (it's verbose; it mixes
content, presentation/style and behaviour in the same XAML document (they
learned nothing from HTML+CSS... which makes sense because WPF was designed
around 2003 when IE6 was at the peak of its dominance), the built-in layout
controls are anemic and have now fallen way-behind CSS's layout functionality,
and so on and so forth.

What Microsoft should do is snapshot a recent revision of CSS and make that
the basis for the style and layout of XML or JSON-based structured documents,
and then extend it where appropriate. Like it or not, eventually all layout
systems are all going to become alike in the end (be it a desktop GUI system,
web-page HTML+CSS, WPF/Jupiter/XAML, Qt, Apple's constraint-based layout
system, etc) - it feels like a waste of resources to build yet another layout
system (or in this case: trying to squeeze more life out of XAML and whatever
WPF's latest descendant is called). Remember that using CSS does not mean
having to use a web-browser engine, or using JavaScript, or even HTML - CSS
was designed from the start to be agnostic to the types of documents and
environments it's used in.

~~~
eddhead
You can definitely move templates and styles to other files and reference them
from there. You can do that to pretty much any XAML element. XAML is actually
a compilable-to-ILR markup unlike HTML/CSS/JSON that need to be interpreted.

I don't see how HTML/CSS does anything any better, XAML is verbose, but the
tooling takes care of most of it.

~~~
DaiPlusPlus
CSS isn't "interpreted" (CSS is declarative), and JavaScript can be compiled
to [.NET
CIL]([https://en.wikipedia.org/wiki/JScript_.NET](https://en.wikipedia.org/wiki/JScript_.NET)).

>I don't see how HTML/CSS does anything any better, XAML is verbose, but the
tooling takes care of most of it.

CSS's modules for layout are far more advanced than WPF/XAML/WinUI. Never-mind
the more brain-dead aspects of WPF/XAML/UWP like `<border>`, WinUI only has
<Canvas> (absolutely positioned elements), <StackPanel> (similar to CSS's
flex-box, or normal block layout), and <Grid> (which is much closer to HTML
<table> than CSS `display: grid;` in terms of capabilities) - all other layout
systems have to be done by hand - which requires a deep understanding of
WPF/XAML's layout system internals - and who wants to invest the time in that
when there's still uncertainty about the supported lifespan of WinUI?

I've noticed that Microsoft only commits to supporting a UI framework when at
least one of their major products relies on it (which explains why WinJS
became irrelevant, _fast_, while MFC and WPF are clearly here to stay (I note
that Microsoft has only one major product relying on WPF: Visual Studio -
literally everything else uses some non-public UI platform like DirectUI
(Office) or MFC.

~~~
contextfree
Windows isn't a major product?

~~~
DaiPlusPlus
Only a small number of programs and utilities that ship as part of Windows
uses WPF. Windows has more WinForms-based GUIs in it than WPF-based GUIs.

It’s a far cry from the Longhorn demos of 2003 that showed the entire Windows
UI been made with WPF, and Explorer itself hosting third-party applications’
WPF components.

~~~
contextfree
Yeah, I meant WinUI/UWP XAML. Starting with 8.1 it's been the standard for any
new or overhauled Windows shell UI, along with the built-in apps. As you
mentioned, this was the original intention for WPF, and the failure of this
plan (which the Windows team largely attributed to the dependency on .NET) was
the main reason WinUI/UWP and WinRT came about in the first place (as
basically a do-over of the Longhorn plans, but ditching the .NET dependency to
build on COM instead). So it succeeded at getting Windows to adopt it (at
least for a while - apparently in 10X they are starting to use web tech for
shell pieces like the new Start menu, although I think the actual window
manager itself is still XAML based), while WPF failed.

------
knight17
This is a subjective take. I don't know whether any of you share this concern
but I feel like almost all new UIs are unattractive. (Maybe except Apple, and
I'm an Android/Windows user). The new windows UIs are flat, colouring is off
somehow (I don't have the lexicon to express what is missing), wastes lot of
space, and appears like applications made for kids.

Take the calculator application included with Windows 10. It takes time to
load. Earlier it was instantaneous. It takes up way more screen real estate
too. Maybe the new design helped them to make this app easier to use on touch
devices, but from my perspective, in all other respects it is going backwards.

~~~
buboard
microsoft didnt start these trends, and it's sad that they are following. win7
was a gold standard of usability and speed. Humans have fast 3d contour
perception for a reason, it helps us find buttons and fruits.

i dare you to find your sound device's control panel in win10

~~~
AlanYx
It's fascinating to watch how even babies pick up on what's a pressable button
(and what's not) in the real world via contour perception. Before they even
have an understanding of cause and effect, they love to find buttons on
physical items and press them.

I wonder why UI designers stopped trying to leverage this principle.

~~~
RockIslandLine
Yeah, discoverability in modern computer UIs is terrible.

------
jandeboevrie
Will be cool to update our MFC app to look better. Wonder if it will still
work on wine then, it does now with VS2019 and the old win 98 look. But the
app is almost 20 years old... Still maintained and worked on today. And until
ms stops support MFC, no change needed. Change just costs money for no
significant profit or advantage to us or our customers.

~~~
nindalf
The new API is only supported on the latest versions of Windows 10. If your
app has users on older Windows versions, the suggestion of using this API will
almost certainly be shelved for at least a few years. That’s how it works on
Android - google shows off a new API and we make plans to use it 5 years later
when users actually have it on their devices.

~~~
snuxoll
WinUI 3 is decoupled from the platform and is one of its major improvements,
apps built with it will run on Windows 10 builds as far back as 1803 (that’s
two years old and is EOL even for enterprise customers).

~~~
nindalf
That's pretty great, and kudos to Microsoft.

However the person I was replying to has a 20 year old app. I'm going to guess
they still have users on Windows 8, 7, maybe even Vista and XP. Using the
WinUI API, even a bit of it, will leave those users in the lurch.

------
MaxBarraclough
> Unmatched Native Performance

Can anyone offer any insight on this? If memory serves, WPF is backed by
DirectX. How can they hope to beat that performance? Performance improvements
over its MVVM? Modern UI toolkits tend to add high-level abstractions and
degrade performance (e.g. by relying on web technologies), rather than enhance
it.

~~~
sleepinseattle
The framework layer of WPF is implemented in C#. WinUI is all C++, including
the framework and the compositor that makes the DirectX calls.

In the framework layer, typical UI updates are faster because the WinUI data
binding system uses code-generation rather than the reflection-like runtime
binding system that WPF has.

WinUI also includes the rather incredible Windows.UI.Composition API’s, with
things like ExpressionAnimation that enable lots of cool animations (like
parallax, sticky header, or cursor-relative) at a stable 60 FPS.

Disclosure: I work at Microsoft on the Windows team.

~~~
MaxBarraclough
Great answer, thanks.

> code-generation rather than the reflection-like runtime binding system that
> WPF has

That's a good move. If a convenient abstraction can be implemented in a way
that 'compiles out', it ideally _should_ be implemented that way. Does this
enable more compile-time checks?

~~~
sleepinseattle
Yes, in WinUI you get build breaks if you have a typo in your property name :)

It also adds the ability to bind to functions, which can eliminate a lot of
ViewModel boilerplate for computed properties.

------
headacheache
Desktop development is a complete mess at the moment on Windows. Core 3.1
definitely has many good improvements and is good for class libraries but
adding a GUI currently has few desirable options 1)Winforms designer doesn't
work with complex or 3rd party controls 2) WinUI doesn't work on Win32 3) WPF
works but lengthens development and will soon be out of sorts with this WinUI
4) Really everyone wants cross-platform GUI but not much forthcoming except
Uno or Avalonia but these are risky for large projects 5) Blazor could be
interesting but only works as Desktop standalone using Electron.NET which
seems a horrible dependence. 6) Old Winforms on defunct .NET framework works
but looks horrible 7) Old 3rd party Winforms on defunct .NET framework is
expensive

~~~
thoraway1010
I don't get it either. Developing on windows used to be trivial. Winforms
designer was drag and drop, click into code, write an extra module, done.

I was told, oh, you are an idiot, you need to be using XAML / WPF etc etc. I
tried - the stuff looks works, much more complicated to develop and does LESS!

Even Visual Basic (remember that?) made GUI development trivial I thought
compared to these new improved approaches.

~~~
headacheache
I have a project due in about 2 weeks and genuinely have no viable options to
build anything on core 3.1.

Just found these links, 2nd one especially looks interesting.

[https://blog.stevensanderson.com/2019/11/01/exploring-
lighte...](https://blog.stevensanderson.com/2019/11/01/exploring-lighter-
alternatives-to-electron-for-hosting-a-blazor-desktop-app/)

[https://blog.stevensanderson.com/2019/11/18/2019-11-18-webwi...](https://blog.stevensanderson.com/2019/11/18/2019-11-18-webwindow-
a-cross-platform-webview-for-dotnet-core/)

------
kennydude
The only thing I didn't like was Microsoft adding an annoying banner asking me
to install some Points extension :(

Not cool putting adverts on your Github pages like that

------
pnako
Looks cool. I'll wait six more months to try whatever will replace it.

------
MR4D
Flat UIs in many cases are _objectively_ bad.

The reason is because humans have two eyes, which give us the ability to
distinguish depth easily (meaning low cognitive load - our brains are
optimized to process this).

In a UI, whenever there are more that two dimensions, depth should be shown
(simulated, technically) because with our two eyes we cannot discern depth
easily on a flat surface.

Obviously you can go overboard. For instance, in HN, flat makes sense. But in
a windowing system, shadows(1) are essential to show depth. Otherwise it
increases the cognitive load required to distinguish between the foreground
and background.

(1) - you could use blurring (or other techniques) as well, I'm just using
shadow as a simple example.

------
zerr
I wonder if it is the same person who has worked on the implementation of e.g.
Win32 "BUTTON", MFC's CButton, Windows.UI.Xaml.Controls.Button,
System.Windows.Forms.Button, System.Windows.Controls.Button... :)

------
flukus
So many red flags in such a quick succession. The setup page
([https://docs.microsoft.com/en-us/windows/uwp/get-
started/get...](https://docs.microsoft.com/en-us/windows/uwp/get-started/get-
set-up)) says you have to download Visual Studio, enable your device for
development and register as an app developer. The latter two indicate just how
much control MS has of your machines, you have to pretty please ask MS if it's
ok to make your own programs, the former shows that they still can't make a
decent API and need an IDE to do all the work, conveniently locking you into
their tool suite.

A little bit later this is confirmed when the show you hello world
([https://docs.microsoft.com/en-us/windows/uwp/get-
started/cre...](https://docs.microsoft.com/en-us/windows/uwp/get-
started/create-a-hello-world-app-xaml-universal)) which instantly creates a
mess of json, xml and c# for you so you don't realize how ridiculously
complicated it all is.

For reference, here's hello world with GTK ([https://developer.gnome.org/gtk-
tutorial/stable/c39.html](https://developer.gnome.org/gtk-
tutorial/stable/c39.html)), a single c file and single line instruction to
compile it. Here's one for Qt
([https://doc.qt.io/archives/3.3/tutorial1-01.html](https://doc.qt.io/archives/3.3/tutorial1-01.html)).
Show me a WinUI equivalent of those 2 pages and I'll be more impressed than I
am by a slick marketing page.

------
lousken
It used to be possible to click on a list of items and hit a alphabetical key
and it'd go to the result starting with that key. Also typing more would go to
that particular matching item. This isn't possible in WinUI as far as I could
test in native windows apps. You can't ctrl+f in settings - it won't highlight
the search

And there're tons of more missing features like that. Did anyone try that UI
with just a keyboard?

------
freeone3000
Another one? Why not fix the six that are already out there?

~~~
Mistredo
This basically fixes all of them by building a common umbrella that all
existing UI toolkits (UWP, WPF, WinForms, Win32) can use.

This picture summarizes it well - [https://github.com/microsoft/microsoft-ui-
xaml/raw/master/do...](https://github.com/microsoft/microsoft-ui-
xaml/raw/master/docs/roadmap_winui3.png)

~~~
ptx
It's the other way around, isn't it? They're not going to reimplement the
Win32 API on top of WinUI, but WinUI uses Win32 in part for its implementation
on some platforms (that platform being classic desktop Windows).

~~~
SneakerXZ
What I meant was you can use WinUI 3 in your Win32 app, so it is a UI toolkit
that can be used in any other existing UI toolkit.

------
BiteCode_dev
This supports "WebView2(Chromium-based engine)" natively, which may add one
reason to why Microsoft chose chrome and not firefox as a browser engine:

\- they share one tech for their browser and UI

\- they rip the benefit of their work (and the community work) on electron

\- it opens the door to sharing one instance (or at least main libs) between
different apps using this engine, solving the 'electron spawn one engine per
app' problem

------
vsskanth
I wish their showcase app resized better. Layout doesn't seem to flow well, as
seen below.

[https://imgur.com/zr4mSLr](https://imgur.com/zr4mSLr)

Also, I find the UWP monochrome UI style extremely confusing and difficult to
use. I don't know why it is to different from the Office 2019 UI, which I find
usable.

------
thrower123
No one wants to use touch on Windows devices, because Windows devices are for
doing actual work, and touch is a shitty, shitty input method.

I'm going to stick my fingers in my ears and keep trudging along with Win32,
because it will never die. Trying to kill it would be the monumentally dumb,
and I don't think Microsoft is that brain-dead.

------
chunsj
Just make a plain C API like Win32, or...

~~~
Teckla
_Just make a plain C API like Win32, or..._

I can't tell if you're joking or not, but this seems very sensible to me,
because it could offer great performance, and it's easy to create bindings
from almost any language to C.

------
pekim
It's a reasonably well written and informative page. But there's an annoying
oversight.

> WinUI 3 is the next version of the WinUI framework, shipping later this
> year.

There's no publication date on the page. That makes it very difficult to know
the year that's being referred to. Is it this year, or some past year?

------
revskill
Microsoft products's documentation is always bad. What i expect the first is
sample of code and screenshot to know what's actually like if i want to try
it.

It's like Microsoft documentation team doesn't have developer mindset in mind.

------
jbritton
Does anyone know if WinUI will be supported on .Net Core or since it is C++,
just a linux library.

The article listed several languages but omitted F#. So I also wonder about
the F# story for WinUI.

------
eecc
Love how one of the stock photos features a MacBookPro :)

------
ifexception
I'm not sure how I feel about this... I think I would still rather go with MFC
and the good ol' battle tested Win32 APIs

------
behnamoh
Isn't it ironic that the WinUI logo is pixelated?! I mean they could use a
higher quality image for that.

~~~
kalleboo
The lack of HiDPI graphics is extremely ironic

------
emddudley
Is any of this accessible from Python?

~~~
contextfree
Not at present, at least not reasonably. There are Python WinRT bindings under
development
([https://github.com/Microsoft/xlang/tree/master/src/package/p...](https://github.com/Microsoft/xlang/tree/master/src/package/pywinrt/projection))
but they don't (yet?) support the "composable types" type system feature
(basically a form of implementation inheritance) that the WinUI and
Composition types require. So you'd basically have to write your own support
for this.

------
ARussell
Will Rust bindings be available, despite their decision to write this in C++?

~~~
jcranmer
They've announced Rust/WinRT recently (see
[https://news.ycombinator.com/item?id=23033451](https://news.ycombinator.com/item?id=23033451)),
so I rather expect there will be, eventually.

------
stuaxo
Anybody going to compile this and get it running on Linux and OSX?

------
jsf01
Is there a way to see a preview of each UI component?

~~~
vegardlarsen
XAML Controls Gallery on Windows Store: [https://www.microsoft.com/en-
us/p/xaml-controls-gallery/9msv...](https://www.microsoft.com/en-us/p/xaml-
controls-gallery/9msvh128x2zt). Source on
Github:[https://github.com/Microsoft/Xaml-Controls-
Gallery/](https://github.com/Microsoft/Xaml-Controls-Gallery/) (see
winui3alpha branch).

------
rsynnott
... this week.

------
skyde
Only work starting windows 10 ?

------
koolhead17
Do we really need WinUI in 2020?

~~~
techntoke
No. It has already lost. No one cares anymore about developing exclusively for
Windows.

~~~
Mistredo
You should step out from your bubble. Majority of the world still runs Windows
on their desktop.

~~~
kalleboo
And on their copy of Windows, they're running Chrome and 10 copies of
Electron.

In 1995, Marc Andreesen said "Netscape will soon reduce Windows to a poorly
debugged set of device drivers", but I guess that turned out to be Google
instead.

~~~
pjmlp
I guess you are speaking about Desktop Linux.

~~~
ginko
Did Linus Torvalds kick your dog or something?

~~~
pjmlp
Nah, we even share common opinions.

"Fragmentation is Why Linux Hasn’t Succeeded on Desktop: Linus Torvalds"

[https://itsfoss.com/desktop-linux-torvalds/](https://itsfoss.com/desktop-
linux-torvalds/)

~~~
techntoke
LOL, succeeded means something very different in this context than what you
are implying. Linux did succeed on the desktop and in fact it has made many
great strides that makes performance and desktop management better than
Windows in almost every way. Just because it doesn't have majority
marketshare, in part due to Microsoft making backroom deals to ship computers
from the slave labor factories that Microsoft supports in order to sell $200
pieces of junk adware laptops at Walmart, doesn't mean that it hasn't been
successful.

~~~
pjmlp
That looks like the same kind of argumentation where every new car is the car
of the year, one just needs to tune the right parameters.

------
mister_hn
No CMake, no party.

------
squarefoot
WSL hooks coming in 9..8..7..

Developers flocking to WSL in 6..5..4..

Linux dead in 3..2..1..

~~~
neilsimp1
> WSL hooks coming in 9..8..7.. Sure.

> Developers flocking to WSL in 6..5..4.. Maybe some, sure.

> Linux dead in 3..2..1.. What? Linux on the server won't see any change.
> Linux on the desktop, maybe, but I doubt most people using Linux on the
> desktop are going to even consider switching because Windows has a new UI
> framework.

The only big advantage that I see is _one_ UI framework for Windows and
multiple different ones for Linux.

------
burlesona
The fact that this page doesn’t render correctly on mobile makes me very
skeptical about the quality of this UI library.

~~~
noahtallen
Renders fine for me. Besides, the folks who write the website would be totally
different from the folks on the platform side of things.

~~~
tonyedgecombe
It does feel like there is a general lack of taste in Microsoft. There are a
few pockets of good work but overall it doesn't seem to be a priority for
them.

------
techntoke
Use Qt or Electron and move on with it. With PWAs being supported in the app
store and now with Chromium Edge, might as well just build something that will
work on all platforms and mobile too. While I admit that there are too few
options for lightweight fast Linux UIs, especially with Vulkan acceleration,
Qt performs incredibly well and Chromium and Node are only going to get
faster.

~~~
baal80spam
> Electron

Oh God please no. I don't need or want every application wrapped in a browser
engine.

~~~
larschdk
Sorry, but it already is. No-one write layout engines or canvas rasterizers
any more. They just use chromium. Spotify, Teams, Slack... I expect even Word
+ Excel to eventually transition.

~~~
SneakerXZ
Sadly, this video is on the point [https://www.youtube.com/watch?v=pW-
SOdj4Kkk](https://www.youtube.com/watch?v=pW-SOdj4Kkk)

------
zelly
The C++ API uses those gross Windows "^" pointers. Literally stopped reading
there.

~~~
snuxoll
You’re thinking of the old C++/CX projection, and, yes, it was awful.
C++/WinRT fits right in with modern c++ and got rid of ref new and hats.

~~~
pjmlp
Although C++/WinRT tooling is still lacking versus C++/CX, no syntax
highlighting or intelisense for IDL files.

Also I don`t get the hate against C++/CLI and C++/CX.

Apparently everyone else is allowed to have language extensions on their C and
C++ compilers, only Microsoft not.

~~~
snuxoll
C++/CLI is a necessary evil for operating on the CLR where are object
lifetimes may be managed by the CLR and others follow standard C++ memory
management. Ultimately it’s raison d'etre is to bridge native code to the CLR
where P/Invoke or COM isn’t sufficient (lot of reasons that could be the
case), so we deal with it.

C++/CX on the other hand only exists because Windows Runtime Components, while
based on COM, is still a superset with new features that couldn’t be supported
with C++98 and MSVC lacked the necessary C++11/17 features to implement it
without needing compiler extensions.

Syntax highlighting and Intellisense being absent for MIDL 3 does indeed cause
annoyance, however.

~~~
pjmlp
I guess those explanations were for the wider audience, I am perfectly fine
with Microsoft's C++ dialects.

Actually my only complaint is the downgrade in tooling experience in name of
some ISO purity that I don't care about, and other compiler vendors also do
anyway.

For the time being I don't plan to adopt C++/WinRT until the tooling
experience catches up with C++/CX.

