[weejewel]

Sometimes I feel teams choose Electron/webapps because nobody knows how to design a great Windows-native application.

If Windows truly had a great UI+UX equal to macOS, the investment of native apps would be much more worth. Now creating a web app for windows is almost the de facto choice because there’s nothing better!

[tapoxi]

I think Electron won out because Microsoft kept pulling the rug out from under Windows developers as they went from Win32, to Windows.Forms, to WPF, to UWP, to WinUI 3. Why take the risk on the most modern Windows framework when you could just go Electron, have a broader pool of developers, and get Mac & Linux support as well?

[aejae]

This. We (at Remotion) are currently evaluating what platform to build for, given our start with macOS native / Cocoa. But for Windows, what is Windows Native?

Seeming like more of a collection of half-baked ideas than robust frameworks that we'd want to bet a bunch of dev time on.

As you both mention, we might end up with a cocoa macOS app and an Electron app for Windows & Linux.

[jeppester]

Please don't make Linux users suffer because of Windows.

[aejae]

I'm not a frequent Linux user so that comment crept in there—we haven't evaluated as deeply. Any suggestions for how to best build Remotion (lightweight video chat + dock for your team) onto Linux?

[rickstanley]

Are Qt, GTK4 or Compose (Jetbrains) viable options?

[aejae]

I'm not a fan of Qt from my time at Dropbox (we used it for our desktop client preferences for some time), but will need to check out GTK4 and Compose. Thanks!

[SureshG]

Check compose mpp, uses Kotlin and Skia under the hood. Really good performance overall.

https://www.jetbrains.com/lp/compose-mpp/

[wiseowise]

Not native.

[throw10920]

I'd like to point out that, while that's a good reason why Electron might have won in terms of developer mindshare, that's not necessarily the reason why it won on in terms of marketshare.

I personally believe that the cause of the latter is a combination of (1) cost-saving through fewer platforms to support (2) cost-saving through a larger developer pool and (3) better branding support, but I've never worked in the business myself.

[yardie]

I remember having to import obscure Win32 libraries because the latest platforms were never complete. Like the fontpicker would drop you from WPF to Win32 because MS couldn't be bothered to update it.

[TYPE_FASTER]

Don't forget Silverlight!

[StillBored]

Or just bite the bullet and use win32/COM, because its basically the API under all these newer APIs anyway, and in the cases its not there is a compatibility shim.

Of course this doesn't stop MS from simply removing functionality, like they have been doing for the past 10 years. Explorer has a fraction of the API surface it had in the past, as do large parts of the OS. Like for example the color APIs which used to describe every little part of the UI so it could be tweaked are now basically gone.

[HWR_14]

Well, you don't use the bleeding edge Windows API. You shouldn't use the bleeding edge of any API in general.

[ravenstine]

Maybe that's the contributing factor, but I really think it's more of an economic decision.

There are far more JavaScript developers out there, so it's easier to hire people to work on an Electron app and have crossover between other teams working on web-based projects. Write-once-runs-anywhere is also a part of it. JavaScript is also extremely forgiving and has possibly the easiest debugging experience of any language I'm aware of.

This isn't to say that JavaScript developers don't often do things that completely subvert the advantages of writing web-based apps, but those advantages are nevertheless on the table regardless. Writing a truly native application will always be more challenging than writing a web app (or even something like a Python-based app) and will always require some amount of specialization no matter what anyone says (as has been observed with React Native and I'm guessing that will inevitably happen with Flutter).

UI is also one of the hardest things to do right when writing cross-platform applications. Business logic is usually quite portable, but UI introduces geometry and fundamental incompatibilities between widget toolkits. The web, with some exceptions, ignores native widgets, thus the problem of writing UI code mostly goes away because there's only one toolkit to work with.

[socialdemocrat]

“Extremely forgiving” is what I think is worst with JavaScript and makes debugging harder. Stuff does not blow up when it should. Good debugging requires “fail fast” IMHO, not JavaScript style “keep going until it is not humanely possible to continue with broken state”

[ravenstine]

Anything that is easy can as easily have pitfalls.

> Stuff does not blow up when it should. Good debugging requires “fail fast” IMHO, not JavaScript style “keep going until it is not humanely possible to continue with broken state”

It depends on what you value. JavaScript and the rest of web technology is good at getting something on-screen and working, more or less. Many businesses, for better or worse, don't care about software architecture and developer happiness. They want something working, and ASAP, and more features to be rolled out for all platforms. Web technology, for all its faults, is going to win every time. Even better when code is written in such a way that debugging your JavaScript doesn't end up being so much of a hunt through a stack trace with layers upon layers of framework code.

Granted, I do agree in general that "fail fast" is better, and I absolutely think that it's practical to write JavaScript code in such a way, but that's not an attractive selling point for JavaScript or Electron. That's like a PSA telling people to eat their broccoli; Electron is like telling people to eat plenty of donuts, and most people are going to eat donuts because companies of all sizes are all too happy to treat the resulting diabetes (metaphorically speaking).

[jenscow]

You're right.

On Windows, the current "native" UI toolkit is WinUI.

I quoted "native", because it's not really native. It's just what's in active development by Microsoft at this point in time.

Creating a desktop-web-app is just more convenient, because of skill re-use and you know it will continue to work, not only on Windows but Linux and OSX. Web is more mature and will continue to evolve.

On Windows, no one cares anymore if your app has a "native" UI - the OS itself has conflicting UI styles, and most main-stream apps are different.

Not the way I like things, but it's the way things are.

[fassssst]

What does “native” mean to you? WinUI is implemented in C++, contains the control set of the current design language, and is used by the Windows shell itself and even Notepad.

Yea it looks different than what you can get from CreateWindowEx with the various control styles, but those also look different than MFC, Windows Forms, etc.

[captainmuon]

I would call it almost, but not quite native. There are some things MS internal apps can do, but that WinUI 3 can't. (Until recently, creating additional Windows, but also things like blurred transparency.)

I think a real native solution would be shipped with the system, and get an updated theme and feel with an OS update. But the last version that did this was Win32/Uxtheme and to some extent WPF. Metro/UWP formally did this, but it encourages you to hardcode a lot of styles, so you have to update your app when a new Windows version comes out. But I think MS has moved away from shipping the UI library with the system.

The real native UI is what MS uses internally, and for a lot of products that is DirectUI. It is used in Explorer, the start menu used it for some time in Win10, I think the control center also used it. But also MSN messenger used it, and Office, too. Spiritually it is similar to WinUI 3 I think: implemented in native code, drawing "windowless", and using some kind of XAML.

[fassssst]

DirectUI was a precursor to XAML and is being rapidly replaced by WinUI internally. It has janky markup and renders using non-GPU accelerated GDI.

WinUI 3 intentionally decoupled from the OS so app developers can support several versions of Windows while still using the latest GUI stuff, in the spirit of web apps.

[jenscow]

Win32 is what I would call native, and MFC/WinForms are wrappers around that.

So in technical sense, WinUI is as native as Qt/wxWidgets.

Just my preference on terminology, rather than anything against WinUI (I've been developing a WinUI app).

[fassssst]

None of that Win32 UI stuff is being updated anymore so it’s more “classic” than “native.”

[marwis]

One could say both are native Windows UI toolkits. Kind of similar to when Apple shipped Carbon and Cocoa.

[drcongo]

This might be a stupid question, but is MS Teams Electron on Windows? It would strike me as weird that the maker of the operating system doesn't use their own UI toolkits?

[laurent123456]

Skype is made with Electron too and so is VSCode. They do like most developers do - if they need a cross platform app, they use Electron. Although I think they are pushing for React Native (maybe?), which can use native controls.

[aejae]

Yep! https://docs.microsoft.com/en-us/microsoftteams/teams-memory....

[flanbiscuit]

Teams 2.0 in Windows is moving away from Electron but still using web based technology. It's not going to use Chromium to render, it'll use Edge Webview2 that comes with the OS.

https://techcommunity.microsoft.com/t5/microsoft-teams/teams...

https://docs.microsoft.com/en-us/microsoft-edge/webview2/

[ramones13]

WebView2 is Chromium-based

[Gaelan]

Isn't Edge just Chromium these days? The page you linked says:

> Evergreen distribution. Rely on an up-to-date version of Chromium with regular platform updates and security patches.

[andai]

Isn't Edge just a Chromium reskin?

[drcongo]

Good lord. I can't imagine Apple putting out an Electron app.

[wlesieutre]

MS Teams has to work cross platform or no one would use it, they'd be "Slack except worse because part of your team can't have it."

It's not like Apple is maintaining iMessage anywhere except their own platforms. And even with that, until very recently the Mac version was second class compared to iOS, only catching up when Marzipan/Catalyst let them share one codebase between the two versions.

So that's not exactly Apple using Electron, but it's still a good example of "Even a giant company like Apple has trouble effectively maintaining separate cross platform versions of the same product."

[vxNsr]

Microsoft makes many terrific MacOS native apps (the most obvious of course being O365), idk if they have MS teams for Linux but I doubt that’d be a reason for using electron.

[copperx]

If Microsoft was developing Office today as a greenfield app, it would surely be Electron based.

[criddell]

If anybody can afford to write native apps, it's Microsoft. How many Teams users are there? Tens of millions? The cost of developing native apps spread across all those users is pretty much zero.

I think the real reason Microsoft went Electron is because they plan on extending it to eventually take control of Electron on Windows. So they need some big Electron-based applications to justify that.

[drcongo]

It already is "Slack except worse". The Catalyst comparison is an interesting one though, Catalyst on macOS is still pretty horrible in terms of usability, but a lot better than Electron on system resources.

[raydev]

The Apple Music app was effectively an Electron app for a few years before the Catalyst version arrived, just a shell around webviews. And even now, there's still a bunch of webviews in the app today.

Mac Messages was comically just a plain webview for years. Again, that changed with Catalyst.

[oscarmv]

Uh no. The old client's chat transcript was using WebView for display with a bunch of custom-fed CSS/HTML/DOM that was built in code. The rest of the app was good ol' AppKit.

The whole chat transcript being a web view thing was one of the main reasons the app eventually got killed in favor of a Catalyst version. There was zero expertise in the team to make all the random new transcript features that the designers kept throwing on the iOS client and there was also no way to reuse the knowledge and code of the iOS team either. Various attempts to rewrite the mac client's chat transcript to native throughout the years failed due to lack of resources and/or corporate bullshit.

[raydev]

> Uh no. The old client's chat transcript was using WebView for display with a bunch of custom-fed CSS/HTML/DOM that was built in code. The rest of the app was good ol' AppKit.

Yes, I overstepped, the sidebar was probably an NSTableView and the text input looked native enough. I still find it comical that the star of the show, the transcript, was a webview.

> due to lack of resources and/or corporate bullshit

I suspected as much, and again, it's comical. Trillion dollar company. Apple, of all companies, can afford to pay Meta-level comp or higher, roll out big recruiting efforts across the US and Canada and let engineers work in more cities, and yet they've only barely started in the last couple years.

[heresaPizza]

MacOS 12.3 just changed that and the difference is incredible. All the Apple music screens load much faster, especially the search one that previously was not just slow but also broken

[_jal]

No, instead Apple has Catalyst to give things that slightly janky, cheap-port feel.

[kuschku]

Yet they even use WebKit to render parts of their own OS settings.

[nmfisher]

Can you imagine the monstrosity that is iTunes on Windows? Far worse than any Electron app.

[drcongo]

It was a monstrosity on macOS too.

[toxik]

Apple puts web views in its platforms all the time.

[reaperducer]

Microsoft Azure Storage Explorer is Electron, too.

The best part is that when Azure Explorer crashes (days that end in "y"), it wipes out all of my VSCode windows, too!

Yay, Electron!

[copperx]

It's not weird, it's telling. Microsoft clearly sees Electron as the future of desktop development.

[criddell]

I'm pretty sure Microsoft embraced Chromium for Edge because they are going to make some big bets on Electron-style development.

[mixedCase]

Windows 11 shell UI seems to be mostly web. I remember how during beta testing people kept finding widgets were you could accidentally trigger Chrome's caret browsing prompt when pressing F7.

[criddell]

Even Microsoft's native applications can feel off. For example, I use Outlook for my email and really dislike its editor. When I type, I want the text to snap into existence immediately as I type. In Outlook it feels like it glides into being and doesn't even keep up to fast typing. Word is like this too, but fortunately I don't have to use it very often.

Because of this, I write longer emails in a text editor and paste it into Outlook when I'm done.

[n8cpdx]

This was an added feature, so it stands to reason that it should still be able to be turned off.

Try this if you haven’t already: https://superuser.com/questions/989951/is-it-possible-to-dis...

[throwmeariver1]

Every month or after a fresh install you can't start the clock or calculator app because it needs an update. It's not even an automatic update you need to open the app to get notified that there is an update. Insane.

[copperx]

Disabling that is a checkbox away in the settings. Coincidentally, I really like the glide effect and wish it existed on macOS.

[marwis]

Which parts exactly? If anything explorer.exe has never been more native (it used to have a lot of HTML elements in Win98 to XP). I think new control panel and start menu are WinUI based.

[marwis]

And OneDrive is in Qt!

[me_me_mu_mu]

I think Electron/crossplatform tools are great at very early stages in order to test whether the product can work. You can quickly put together a working cross platform application to start testing features.

I am a noob at startups (working on some of my own ideas) but I almost always start with the most simple set ups (zapier + google forms tbh) to try some process with 5-10 people. If that seems promising I'll build a app over a weekend/5 days using flutter, and then get that into people's hands. I've not used electron, but at least my thinking is that if I can validate an idea and come up with a good business model, I can grow to a point that I can hire actually competent engineers to build the best experience for the users.

The primary goal (at least as it seems to me) is to solve some problem that people are comfortable making some tradeoffs(mostly unnoticed by normal people, let's be honest otherwise they wouldn't even want to try a bare bones google forms + email) while providing far more value to them.

Ultimately these are all tools, use the right one where it matters until it needs to be upgraded or changed.

[holbrad]

If I wanted to make a native windows application I really wouldn't know what to use ? WPF is what I've worked with. But WPF is awful.

When I was doing some games programming using Imgui for little widgits was actually quite nice. But wouldn't want to use C++ generally for an application.

What do people actually recommend ? Electron seems to be the go to.

[n8cpdx]

I work in WPF, UWP, and Xamarin.Forms daily.

I’m a little offended by the comment about WPF; WPF is stuck in 2006 but at least is about as polished as you can expect from a 16 year old product. Microsoft should aspire to make their other UI offerings half as good as WPF.

UWP is like WPF, but with critical features stripped out, broken core functionality (e.g. renderers for paths/SVGs are super broken), and an 80% chance of facing a COM exception if you try to do anything remotely interesting.

I’m learning web tech so I can make a career change - I built my career on .NET client technologies and I deeply regret it.

Take it from a (former) Windows fanboy, choose Electron.

[duxup]

>because nobody knows how to design a great Windows-native application

In that case it is a question of resources right? Nobody in our org knows how to do that thing well, so we could have them go learn or ... use Electron and get the app out the door...

The choice for an organization with limited resources seems obvious.

[weejewel]

I meant to say — Because Microsoft doesn't lead by example and doesn't offer the correct documentation & tooling.

[MiddleEndian]

They also don't lead by example in their software.

In basically every single text field/area in Windows, `CTRL Delete` deletes the current word and leaves the space before it, so if you type "Hello Hello", hit ctrl delete, and then type "Goodbye" your result will be "Hello Goodbye".

In Windows Mail, for reasons unknown, it deletes all the way to the last character of the previous word. So if you type "Hello Hello", hit ctrl delete, and type "Goodbye", you get "HelloGoodbye". It's baffling. Why make a unique UI element just for this that's inconsistent with the rest of the operating system?

[NicoJuicy]

They are getting there ( after a very long road) - https://devblogs.microsoft.com/dotnet/dotnet-maui-preview-14...

[forgotpwd16]

If Windows was only the case we wouldn't be having a blog post explaining why they didn't chose Electron for a program running exclusively in some other platform. As that implies that Electron is very widespread even in that platform.

[SureshG]

> because there’s nothing better!

You should check out compose multi platform - https://www.jetbrains.com/lp/compose-mpp/

[tinus_hn]

Is there even such a thing as a Windows-native application?

[ChasingEchoes]

yes. There is only one that i can think of.

Notepad++