WinUI, The modern native UI platform of Windows | Hacker News Reader

WinUI, The modern native UI platform of Windows

microsoft.github.io

190 pointspjmlp210 comments

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?

"Maybe this is the time Microsoft gets it right"

Windows GUI was done right long time ago by Delphi and now Lazarus. Now it is also multiplatform. When it comes to UI with Delphi approach I could concentrate on what I am doing instead of how. And it's been available for 25 years.

One thing that I always disliked on Visual C++, specially when compared against C++ Builder, was that doing MFC had nothing visual about it.

C++/CX seemed to finally be what I was expecting, since C++/CLI never had designer tooling support.

But since they got the ISO C++ striking force to redo C++/CX with C++17, now we are supposed to wait for ISO C++23, for the Visual Studio team deliver with C++/Winrt what C++/CX can already offer today.

Sometimes I think someone should offer some C++ Builder licenses to Visual C++ team.

You missed one!

https://github.com/winjs/winjs

Yep, I dared the man to tell during an MS event in Vancouver in 2010 to tell when they will dump it.

The auditorium exploded in laughing.

3-4 years down the line, that "biggest thing since sliced bread in development for Windows, and WinMo" got quietly swept under the carpet.

And even after that, they tried to spin 3 or more "trendy Javascript platforms" to no avail.

So now they have 6, possibly 7 defunct Javascript platforms for Windows whose very fact of existence completely discredits them in eyes of developers.

P.S. He forgot to mention Windows script hosts!

And another one: Windows Aero

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

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

This one may have had the swiftest official deprecation timeline of them all.

DWM was created to facilitate Aero, and is still used today.

WinRT and the UWP XAML framework built on it were already designed to support multiple languages and language runtimes (well, C++ and C# anyway, but theoretically other languages; they're working on Rust support). It's also been possible to use it in a Win32 app since Windows 19H1 with XAML Islands. WinUI 3 will make this easier though, and decouple the framework from the OS so it can work on older Windows (10/10X) releases, so those are the new aspects here.

This toolkit approach sounds inspired by the web. You write in whatever language / framework but the GUI runs in the browser runtime.

But what about their ReactXP? That's supposed to let you build for React for Windows & Mac and thus WinUI, and also React Native for mobile and such.

They did a great job with ReactXP tying together react-dom (Web), react-native (Android, iOS, macOS), and their react-native-windows (Windows, Xbox, Mixed Reality).

Unfortunately, development on it has slowed and it's not the easiest experience for new developers.

Fortunately, it's super flexible and open-source so I've forked it to continue my vision of the perfect native cross-platform stack:

https://ult.dev/

Do you know why development on ReactXP has slowed? Are they abandoning it?

No and I didn't mean to give the impression that it's inactive or anything.

It's a pretty mature project so there's not many changes needed.

The main thing was I wanted it to do more and I didn't agree with certain styles and APIs.

Why choose ult instead of electron? If the argument is performance, benchmarks are needed.

Because Electron does not run on mobile and it doesn't interface with the native UI.

No benchmark is needed. Running your app in an entire browser (one of the most complex pieces of software w/ millions of lines of code) is of course going to be less performant and eat more resources.

I'm not dissing Electron, it's great if you have a web app that you want to make standalone on the desktop. That alone does not make cross-platform though.

Ult can target the DOM so you can build a web app then wrap it with Electron. This is currently the best way to target Linux. Ideally there will be a GTK bridge like the bridges for the other major desktop and mobile OSes.

Back on my .com days, we would just start the application using localhost and make a OS request to use the system browser, but what do I know.

Congrats

you can use Win32 + C++ + WinUI, or you can use C# + UWP + WinUI and get something reasonably consistent.

Wow. This reminds me of the stupid prediction I made in another thread today about Microsoft eventually abstracting Windows away so that it's a shell that can run on top of Linux. Or perhaps any other kernel.

Thinking of the Duo smart phone.

Microsoft developers always discovered that the UI controls you see in apps like Word, Excel, Visio, etc were never available on any of these libraries or frameworks. Don't forget WTL in the list.

You’re forgetting about Windows Template Library....

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

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

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.

I think someone couldn’t get mp4 auto play to work in all browsers, and just gave up and resorted to a gif to check off their requirements list.

To be fair though it’s hard to convey irony in text, let alone a file name.

“Gif is the modern universal video format.gif” would have been very ironic.

Yeah https://microsoft.github.io/microsoft-ui-xaml/img/performanc...

How do you know it is unironic?

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.

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.

After my rant day, here examples from my work day: I need to lay out two data-tables in a dialog, with 50% to each. I also need label headers above each section. The tables must grow and share available space, the labels stay put. In WPF, this 'daily driver' task, requires this:

- it can't be solved with DockPanel (which is OK.) - it can't be solved with hbox(StackPanel), because of StackPanel's broken design (ie not handling resizing children.) - so I'm forced to use Grid.. Which, for this trivial task, requires this:

        <Grid Margin="0,10,0,10">
            <Grid.ColumnDefinitions>
                <ColumnDefinition Width="*"/>
                <ColumnDefinition Width="*"/>
            </Grid.ColumnDefinitions>
            <Grid.RowDefinitions>
                <RowDefinition Height="30"/>
                <RowDefinition Height="*"/>
            </Grid.RowDefinitions>


 And then, on each of my 4 children, I have to put these:

..Grid.Column="1" Grid.Row="1"

What a bloated inelegant mess. I don't want to specify absolute indices on my grid children, I want it handled by nesting or symbolic row identifiers (anything where I don't have to count/update row/column indices by hand.)

I'm not happy, that the layout rules for grids have their own "", "number", "number", "number%" system independent of the hor/vert alignment system. I don't want to specify an absolute height on my label row.

To clarify on the "app-wide layout". You can specify things like "OK, let's have a 10px margin around the outer containers". But that doesn't really help you specifying the internal spacings _between_ items. You end up having to do lots of one-off adjustments, with the first or last button/panel. I don't want to spend my time messing with all that, it's trivial and boring, it should be something solved in a single place, once. After that, I just want to add "semantic" controls to my interfaces/screens, and have the application-wide layout rules make sure it's laid out nicely in the same way.

When I look for solutions to that, I end up with useless "guides" like this: https://www.wpf-tutorial.com/styles/using-styles/

Why CSS is magnitudes worse?

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.

"..as designed". Yes, their design is broken :-). Grid: All your items must specify absolute row/column indices. When you add row/column, you have to adjust all those row/column indices +1. And manage Row/ColumnDefinitions. The 16G computer should manage all that.

StackPanel: It assumes children have known static sizes. You can't specify "2 children with 50% space each". Thus a downgrade from hbox/vbox layouts we've had since 1989 :-(. Because of this, most of my layouts are a weird mix of DockPanel, StackPanel and Grid (not because I want DockPanel, but because it's less broken than the other two.)

How would you set up default spacing/margins app-wide? I can't see how you would do that, without at the same time adhering to some custom "magic" rules, in your xaml instances, to cooperate with your app-wide settings? IE normally you end up with weird mix of "margin at 10px", but then have 0 margin on some sides, for first/last item.

Shortcuts are not a "specific scenario". The shortcut in question is closing a dialog, where your OK button has IsDefault="True". In that case, the value in user's current edit field is not transferred, unless you as a programmer address it. Apple had this issue handled in 1994 :-/. Microsoft in 2007 believes programmers love dealing with stuff like that.(e.g. UpdateSourceTrigger=OnPropertyChanged will solve some cases.. Hooray, I really love having to type UpdateSourceTrigger=OnPropertyChanged.. Well no I don't).

I'm not asking for fixed default spacings, I'm asking for a well-designed mechanism to handle margins and spacing, app-wide, without having to specify alternating "0 pixels above, 10 pixels below" on random buttons to make things fit.

An funny example is StackPanel missing an items-Spacing property. The funny thing is, it actually has this setting.. But it was only added in 2017 (after 10+ years?), and available in some SDK preview that I have never managed to find in either my VS2017 or VS2019.

I forgot to mention ways in which DataGrid is broken. On paper, it seems great. But in practice, the implementation of things like DataGridComboBoxColumn means it only works for toy examples. If your tables have 20 rows and 3 columns, DataGrid with DataGridComboBoxColumn seems fantastic. But we don't have 20 rows and 3 columns, do we? No wait, we have 30-40 columns, and 900 rows.. And then you find out that DataGridComboBoxColumn performs like a dead dog/kicking a whale down the beach, because some genius at microsoft thought it a good idea to look up the display value for each cell dynamically in the combobox itemsSource, FOR EACH CELL IT HAS TO RENDER.

And then you get a head-ache, because you remember programming the same things back in 1995 and 2003 and 2007 and 2009 with Qt/MFC/Delphi/Swing(yes, swing..), and having them perform well, and wonder why this is suddenly not possible in 2020. There are solutions to many of the problems in 3rd-party, e.g. Caliburn, but I don't want to have to use 3rd-party fixes for things that should be in the core package, in 2020 (and 2007, or whenever they did WPF.)

Another thing: WPF not throwing exceptions (or silently catching them, whatever you call it.) I'm very much not a fan of this. As far as I can see, it just means programmers are ignoring and/or inaware of and not fixing, a million bugs in their GUI code. If you don't believe me, try running Autodesk's monopoly building design tool Revit. Parts of it is written in WPF. You can tell that, because if you run Revit from within Visual Studio, the Immediate diagnostics Window is scrolling full with all the errors that Autodesk's programmers choose to ignore. Which is real helpful, when you are trying to find the messages YOUR program outputs in the same window :-/.

WPF, broken?!?

I had the pleasure to work it during 5 years.

Qt is also no walk into the park with multiple iterations of the UI scripting language, unclear roadmap of QML vs C++ based widgets, bugs left years unfixed for mobile platforms since they decided to pivot into IoT (aka Devices), the whole non standard C++ macros, and several other issues.

Strange. I had mostly pleasant experience with WPF. In fact, back in the early days it was so exciting to work with.

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

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.

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.

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.

> 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

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

The words and icons should be what's directing your eye, not half the screen's fields being magenta.

I'm finding skinny scroll bars increasingly hard to target, even with my mouse.

Honest question: Do you actually use scroll bars much? I can't remember the last time I actually clicked on one with a mouse.

If I'm on a desktop, then I use the mousewheel for incremental scrolling and home/end/page/up/down for faster scrolling.

If you have a long page and your looking for something "about this far down the page", there should be a TOC or a map.

On touch interfaces, it's just the side of the screen or standard scroll.

At this point, for me, a scroll bar is more an read only position indicator than an actual navigation tool.

Interested to see if I'm in a minority here.

Trackpad response on my HP Stream 11 is horrific. The only reliable way to scroll is to somehow get the touchpad to admit you are trying to scroll, so that the thin scroll bar appears, then move the mouse over to the scroll bar handle and click to drag it. Triple click to start a drag action also works, once you have the handle.

I love my little HP plastic laptop. It's a plastic toy I got for $85, including a Windows 10 Pro license, and I just toss it into my bag when I want to go somewhere. Perfectly adequate for text editing. Yesterday I had Visual Studio Code, web browser with 10 tabs, Ubuntu 19.10 via WSL, and Docker desktop all shambling along. I felt like Jason Bourne driving an attack Lada.

My other Win10 device is a ThinkPad x230. Its touchpad is also limited, but has three real hardware buttons.

Mostly I use similar aged MacBook Pro or iMac with Magic Touchpad. Totally different level of quality, no comparison really.

I always wondered why pro Windows laptop users in my family only used extra USB mouse devices. Ugh. I have yet to experience a mass market Windows laptop trackpad that most people would be able to use full time.

Trackpads are no longer a Windows vs Mac thing. On the Windows side, if the manufacturer implements Windows Precision Touchpad, the scrolling, gestures, and multitouch experience is (for the vast majority of users and manufacturers) excellent and near-Mac quality. If the manufacturer does not implement Precision Touchpad, then it's on them; their trackpad experience will suffer and will be closer to the terrible experience you have with your HP Stream 11.

I use my mousewheel the vast majority of the time, but it is not uncommon for me to use a scrollbar. In fact, I had to earlier today and remember being frustrated that I couldn't see it at first and that it was so small it was hard to click on.

It comes in quite useful when I need to move over a lot of space to find what I'm after. I'd be using the wheel on my mouse for quite some time otherwise.

We also use them as an indicator to realise there is something to scroll, in the first place?

Honest question: Do you actually use scroll bars much?

Yes, all the time.

Discord has that very thin user list scrollbar that is the same colour as the main background with only the little box being a shade-darker to even indicate there is a scrollbar at all.

Seriously annoying.

i agree. it's a UI element that forces me to behave to how it wants to behave and not how i want it to behave. i want to just scroll through a page without having to delicately hover and click my mouse. the extra few pixels are not worth the time i've spent jacking with those things. (in microsoft edge, the scrollbox will sometimes not even widen and thus can't be grabbed. you gotta refresh the page to get it back.)

Better link: https://github.com/microsoft/microsoft-ui-xaml/blob/master/d...

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.

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.

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

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.

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

No! Not another UI toolkit from Microsoft!

This is like yet another messaging app from Google.

It's essentially the same UI toolkit from UWP, just with the namespaces changed and decoupled from the OS and app model.

Google messenging app powered by Microsoft UI toolkit when

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

What are we up to now? 5, 6?

WinUI, WInjs, UWP, WPF, ReactXP. Any other?

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

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

>But then you have to program in C++ or JavaScript

qt now also supports python as a first class citizen (https://www.qt.io/qt-for-python). The documentation is still a little bit lackluster but it largely mirrors the c++ api.

I've written a few smallish projects with it and it's been a breeze.

If you use Qt you have all the string utility functions you need (https://doc.qt.io/qt-5/qstring.html#public-functions)

> 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... (non-exhaustive)

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

Several of those bindings that I have tried leave a lot to be desired, especially since Qt widgets often encourage C++ class inheritance.

> I recently learned the former (std17) does not have a string.split function in the standard library

It's not C++ and it works in-place, but my manpages say "strtok" has been standardized since C89. strtok_r in POSIX since 2001.

Isn't macOS support being pushed via react-native on macOS? IIRC MS is the biggest contributor there.

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

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.

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

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.

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

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

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.

> If you're building a substantial app then the fact that Electron apps require more memory is usually not a problem.

Gonna need a citation on that. Every tab of Gmail I have open takes up more RAM than my fully-featured Outlook desktop app that's pushing an order of magnitude more items through Exchange.

Slack, Discord, and Teams are loads more heavyweight than all the fanciest (non-Electron) IRC clients. Or look at Telegram: wicked fast native client that's barely using more than 100 MBs on my box with 20 some odd group chats all pushing instant multimedia notifications every couple mins.

Not to mention all the Electron counterparts are just slower. I actually don't know what black magic Microsoft did to make VS Code so snappy (it's way more responsive than all those chat apps I listed above), but it's also still noticeably laggier than Sublime and true Vim.

There are all these clients out there now that use far more memory then native alternatives and objectively perform far worse but they are all insanely popular and dwarf the alternatives in terms of user base.

So I mean, "it's usually not a problem" is true, resource consumption of the clients don't appear to affect acquisition of users or popularity of the platform.

That ignores the fact that those apps may have done even better had they invested in native alternatives.

I don't think it's a stretch to assume that there's some non-zero set of folks out there that tried to switch from Exchange/Outlook to Slack at scale and said "this doesn't really meet our needs". Some of that is UX, sure, but that UX was also driven by the limitations of performance.

How big is that non-zero set? Who's to say, business is hard and full of imperfect assumptions. But I can tell you as a user of most of these apps, having them not do what I tell them to do because of laggy UIs is infuriating. (E.g. I constantly make the mistake of "reacting" to someone else's message in Teams while I'm trying to find a permalink or edit my own message. Then they get a push notification, I erase the reaction, and I hope they assume it was a mistake. Happens every couple days.)

Not a problem for one metric, sure. Certainly a problem in others. Let's not imagine that because one thing is a success, all its other failures must be ignored.

Until you have 5 electron apps open taking 12 GB of RAM and half the power your 6 core CPU. The benefit of using an OS native library is that (ideally) memory can be shared between processes via various behind-the-scenes mechanisms (shared DLL memory, graphics caches, etc).

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

In this particular case, WinUI's appeal is that it is one UI toolkit that works across development environments and underlying languages.

This means that you can use WinUI from C++ code, or from C# code, or from .... code, rather than having to choose (and learn) a UI toolkit for each development environment.

Whether it will actually play out that way, who knows.

Microsoft has been firing UI, data access, etc. toolkits at people for the past 30 years. Every 10 or 15 years there's an actually important one that people will end up using. You can't always know which one straight away, but basically that's Win32+MFC and then WinForms for GUI. And Qt, although that's not from MS.

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

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.

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

anecdotal, but, as steve once said “most companies die of indigestion”... putting their weight behind one toolkit ensures everyone is working to make it the best it can be...

It probably helps that it was a fully mature toolkit inherited from another place, and came in with the return of Steve Jobs, so it would be pretty politically untenable to start trying to ditch it.

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.

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

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

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.

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.

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.

I would like the framework to stay up to date with new features. With every .NET framework so far after a few years you stop getting any updates and all new development happens on the new platform. This gets really tiring after a while.

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 ?

WinUI 3 supports .NET 5 : https://youtu.be/tasbSc3771A?t=186

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

At this point it should be a multi-platform toolkit running on .NET Core. I don't think many devs will be excited about WinUI.

Microsoft wants to make a profit, not to excite many devs. How would they profit from cross-platform GUI toolkit?

Well, I'd imagine the logic would be the same as it's been with things like vscode -- winning over developer mindshare and goodwill has a lot of immaterial benefits.

They aren’t going to profit from WinUI either. Not many devs will jump on it.

"Works with your favorite cross-platform technologies."

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

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.

No it means you may be able to get it working on more than one windows PC. Don't bet on it though.

Meh, Win32 forever.

Ah the API that is frozen in Windows XP cryogenic state.

This can be a positive depending on your perspective.

The biggest one being that's it's available on xp, vista and 7. Had they back ported WinUI to at least 7 it wouldn't have been dead on arrival.

What exactly do you mean by Win32? GDI?

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

https://www.paulgriffiths.net/program/c/srcs/winhellosrc.htm...

It's not much effort to wrap Win32 into a pretty nice C++ library. I guess in a sense this would be MFC but with modern C++ you can do much better.

It's not much effort to wrap Win32 in any language, which is more than you can say for something like QT.

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?

Many Microsoft APIs do that so that they can add members at the end of the struct in future versions.

Inside the implementation of the API they might say:

    if (wndClass->cbSize == SIZE_IN_PREVIOUS_SDK_VERSION)
    {
        // Code to handle legacy structure goes here
    }

If they add to the struct and don't make accesses to the new members conditional on cbSize's value, then it's a bad pointer dereference. The caller allocated it with the "old" size, likely on their stack, and some unrelated value might be located where the new members would be, or it could be a bad pointer.

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

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

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.

Classic desktop GUI. As to what API that would mean, I don't have a clue.

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?

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

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" ;)

It runs Windows :D

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

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.

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

I've never used WPF, but I've done alot of UWP, and from the code samples I've run into for WPF while searching for UWP solutions, UWP feels like it is pretty much the same thing as WPF, with a few namespaces or classes missing. I can look at WPF code, and easily copy+paste or translate it to UWP with minimal effort.

Alright, thanks. I'm pragmatic enough to see some value in that (easier to transition, no retraining), but man, I would not be happy.

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.

Can you promise that it's good? When I try to read up on it, it just seems to be some 'android clone' intended for playing-card-stack-navigation? (IE UI's where you keep flipping back and forth between full-page layouts) ?

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

Stuff like datagrid tends to live in the Windows Community Toolkit (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)

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

DataGridView had huge problems if you wanted to do anything even slightly off the beaten path. UWP forgoes opinionated controls.

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

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.

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.

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.

But since Windows 8 they've stuck with essentially the same XAML framework (albeit under different names - Metro/UWP/WinUI). So they've been reasonably consistent for the last 8 years at least.

I've been wanting to make a Windows app for my specific budgeting needs so that I can uninstall LibreOffice since that's all I use it for.

So my plan was to use React + Electron since it's easy and quick, but it feels like overkill.

So I considered downloading VS Community and using C# and .NET for it, but that also kinds of feels like overkill.

So I considered using Win32 APIs, but I remember the sample hello world program's source being surprisingly complex.

So I considered learning MFC and using that since I heard it's a decent layer on top of Win32, but then I'd have to relearn C++.

So I opened the WinUI page and the WinJS repo linked to somewhere else in here, and both seem like dead ends.

This is why I still have LibreOffice installed. Which of course also feels like overkill.

You have to do your own anchoring logic

Or moving logic, as it were... I'm sure I wasn't the only one who has made the "button you can't click"[1] prank application after finding out that UI controls are windows, and can be resized and moved too.

[1] A single window containing a button labeled "CLICK ME", which jumps to a random place every time your mouse approaches it. I have also made a version without the window, or rather the containing window, which has the slightly amusing appearance of a lone button that jumps around the desktop. Labeling it "click me to close" of course makes it even more fun...

Win32 is even better: it will run on Linux and macOS, too, thanks to Wine and friends.

As a .NET dev I've settled on WPF. Win32 is too low-level, and might have problems with high DPI support.

You totally forgot that Silverlight for a while was supposed to be the best framework for the desktop :-)

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

Most probably use WPF but that's not much fun.

That was a really informative comment, thanks for taking out time to explain it.

Do you still make apps for Windows?

I have done it during the past 5 years before switching jobs.

Life science research laboratories and many medical devices are pretty much some form of Windows running a mix of MFC, Forms or WPF, dependending on when the application was made.

The large majority of device manufactures, delivers their SDKs as a mix of DLLs and COM libraries, with samples written in C++, VB and C#.

While HN might talk all day about R vs Python vs Julia, many of the researchers actually use Excel or Tableau, and when their built-in programming cannot keep up, it gets reborn as a .NET desktop app.

Microsoft has a habit of releasing a new UI toolkit for Windows a few times a decade and then only supporting it for a year or two.

There is a Microsoft UI toolkit that can't run in latest Windows version?

There are probably 8 that can run on the latest version. And all of these became abandonware a few years after their introduction.

Thanks. That clears it up

This comment from few years ago is informative https://news.ycombinator.com/item?id=18105142

This reddit comment has a good overview of the history:

https://old.reddit.com/r/csharp/comments/f9i9hc/which_one_is...

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.

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.

> With 1 billion devices running Windows 10

Just like Java

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.

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?

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?

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

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

1. Try moving to WPF on .NET Core 3+ now.

2. Wait for .NET 5.

3. Try adopting WinUI 3+ controls as XAML Islands, one at a time until your XAML is more WinUI than WPF.

4. Eventually drop remaining WPF dependencies and declare it a UWP app.

5. Profit?

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

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

They seem to be putting a lot of effort on React Native for Windows and Mac (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.

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.

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.

React native sucess is based on rumor. Is there any, relatively recent and significant benchmarck showing performance difference between react native and react electron?

Yes, the new version of React Native for Windows is built on top of WinUI

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.

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

Not native either. You want to look up burned rubber or carpet and rug burn. Sometimes when a thing moves very fast, it makes heat and this heat causes blisters.

blistering means fast.

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

WinUI is still UWP, just made portable across multiple Windows 10 versions.

Basically it is the UWP version of Android's Jetpack.

Win32 is done, frozen in Windows XP view of the world, the future keeps being UWP.

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.

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

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

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.

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?

UWP and "Metro" are the same thing, this is also basically the same thing just decoupled from the OS and with the Windows.* namespaces swapped out for Microsoft.* namespaces. So they've stuck to one reasonably coherent approach for the last eight years or so at least.

Yes, you're forgetting Win32, which of course was an extension of the original Windows 16-bit API which I'm not sure had its own name.

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

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

Turbo vision https://en.wikipedia.org/wiki/Turbo_Vision

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

I am a long time desktop dev but my next project will either go web or qt. I am done with MS desktop toolkits.

I've been doing .NET for about 10 years and tbh outside of .NET core itself for building web applications and services (not just windows services) I am not massively interested.

MFC and WTL. The latter still exists in a way, but its license may not be to your liking.

I was being rhetorical.

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.

They claim to be interoperable with electron Cf Works with your favorite cross-platform technologies What does this actually mean?

Can they just sack people instead of projects?

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

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

It's open source.

“Modern UI” is not a selling point.

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/

Remember telemetry: https://github.com/microsoft/microsoft-ui-xaml/blob/master/p...

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

I bet it will be abandonware by 2023.

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?

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.

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.

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

Reply on news.ycombinator.com