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).
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 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.
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.
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.
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.
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.
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.
"
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.
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 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.
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...
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.
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.
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?
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:
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.
Because Electron does not run on mobile and it doesn't interface with the native UI.
Just use ionic and electron, it is trivial.
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.
You think you can draw conclusions from such a weak heuristic?
One could argue that browsers are the software that had the most investment in optimizations. E.g chromium has the state of the art of 2D rendering performance (best skia integration).
It's really sad to see that the myth that browser are slower than native uis is not challenged anywhere, It seems like people here locally disable their critical thinking, because of a blind spot.
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.
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.
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.
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.
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?
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.
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.
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 ?
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.
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.
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.
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 :-/.
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.
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.
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.
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:
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.
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.
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
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.
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".
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.
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.
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" ;)
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.
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) ?
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.
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).
> 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.
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.
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.)
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
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.
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.
React native sucess is based on rumor.
Is there any, relatively recent and significant benchmarck showing performance difference between react native and react electron?
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.
216 comments
[ 2.8 ms ] story [ 260 ms ] threadThis is like yet another messaging app from Google.
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?
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.
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.
It's not like what's expected out of desktop GUIs have been completely static over this time frame.
https://www.paulgriffiths.net/program/c/srcs/winhellosrc.htm...
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...
Inside the implementation of the API they might say:
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.https://old.reddit.com/r/csharp/comments/f9i9hc/which_one_is...
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.
"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.
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.
And a large majority of factory and laboratory automation control systems.
Do you still make apps for Windows?
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.
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...
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.
Does this mean this can be used to create Desktop applications that work on Linux & OS X?
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.
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.
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)
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?
https://github.com/winjs/winjs
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!
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.
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/
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.
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. You think you can draw conclusions from such a weak heuristic? One could argue that browsers are the software that had the most investment in optimizations. E.g chromium has the state of the art of 2D rendering performance (best skia integration). It's really sad to see that the myth that browser are slower than native uis is not challenged anywhere, It seems like people here locally disable their critical thinking, because of a blind spot.
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.
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.
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.
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.
WPF, UWP, SilverLight, Metro. Am I forgetting any?
I wonder if WinUI is truly more performant than Winforms. Winforms hooks directly into WINAPI. How can you be faster than that ?
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.
They've also have been the ones leading the effort to add MacOS support to react-native.
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.
- 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
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.
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.
really hard to find all the CSS that affects a particular part of an app Devtools show which selector from which file affect which element.
It mixes styling (colours etc) with layout (flexbox). Yes, why not? :)
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 :-/.
When I look for solutions to that, I end up with useless "guides" like this: https://www.wpf-tutorial.com/styles/using-styles/
- 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.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.
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.
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.
P.S. Actual download link: https://aka.ms/winui/alpha/projecttemplates
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.
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.
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).
(one difference is that the WCT is mostly C# and WinUI/the built-in controls are C++)
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.
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.
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.
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.)
> 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
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."
The thing that was missing before was a nice UI framework to go along with it; hopefully this WinUI thing addresses that.
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.