10 ms·

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

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!

forgotpwd16 4y ago
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.
duxup 4y ago
>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 4y ago
  I meant to say — Because Microsoft doesn't lead by example and doesn't offer the correct documentation & tooling.
  - MiddleEndian 4y ago
    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?
ushakov 4y ago
- speedgoose 4y ago
  I’m quite sure Microsoft has enough applicants to filter such candidates and only go with experienced or competent web developers.
  - ushakov 4y ago
    yeah, imagine what desktop apps would look like without web developers fast startup time, no battery drain, low system requirements, native look and feel… guess we don’t deserve it
    - speedgoose 4y ago
      You forgot “doesn’t exist for your operating system” in your list.
      - ushakov 4y ago
        i’d love to have an OS that doesn’t support Electron
        jakear 4y ago
        FreeBSD. Let me know how it goes for you. Genuinely interested.
        johnny22 4y ago
        seems there's a port now (based on electron 13), although not merged upstream
        speedgoose 4y ago
        FreeDOS perhaps.
tapoxi 4y ago
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?
- throw10920 4y ago
  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.
- TYPE_FASTER 4y ago
  Don't forget Silverlight!
- yardie 4y ago
  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.
- aejae 4y ago
  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 4y ago
    Please don't make Linux users suffer because of Windows.
drcongo 4y ago
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?
- aejae 4y ago
  Yep! https://docs.microsoft.com/en-us/microsoftteams/teams-memory-usage-perf#:~:text=Teams%20is%20designed%20to%20use,browsers%2C%20including%20Edge%20and%20Chrome https://docs.microsoft.com/en-us/microsoftteams/teams-memory....
  - drcongo 4y ago
    Good lord. I can't imagine Apple putting out an Electron app.
    - raydev 4y ago
      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.
      - heresaPizza 4y ago
        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
      - oscarmv 4y ago
        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.
jenscow 4y ago
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 4y ago
  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.
  - jenscow 4y ago
    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 4y ago
      None of that Win32 UI stuff is being updated anymore so it’s more “classic” than “native.”
      - marwis 4y ago
        One could say both are native Windows UI toolkits. Kind of similar to when Apple shipped Carbon and Cocoa.
  - captainmuon 4y ago
    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.
ravenstine 4y ago
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 4y ago
  “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 4y ago
    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).
holbrad 4y ago
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 4y ago
  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.
me_me_mu_mu 4y ago
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.
SureshG 4y ago
> because there’s nothing better! You should check out compose multi platform - https://www.jetbrains.com/lp/compose-mpp/ https://www.jetbrains.com/lp/compose-mpp/
tinus_hn 4y ago
Is there even such a thing as a Windows-native application?
- ChasingEchoes 4y ago
  yes. There is only one that i can think of. Notepad++
NicoJuicy 4y ago
They are getting there ( after a very long road) - https://devblogs.microsoft.com/dotnet/dotnet-maui-preview-14/ https://devblogs.microsoft.com/dotnet/dotnet-maui-preview-14...

forgotpwd16 4y ago

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.

duxup 4y ago

>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 4y ago
I meant to say — Because Microsoft doesn't lead by example and doesn't offer the correct documentation & tooling.
- MiddleEndian 4y ago
  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?

ushakov 4y ago

speedgoose 4y ago
I’m quite sure Microsoft has enough applicants to filter such candidates and only go with experienced or competent web developers.
- ushakov 4y ago
  yeah, imagine what desktop apps would look like without web developers fast startup time, no battery drain, low system requirements, native look and feel… guess we don’t deserve it
  - speedgoose 4y ago
    You forgot “doesn’t exist for your operating system” in your list.
    - ushakov 4y ago
      i’d love to have an OS that doesn’t support Electron
      - jakear 4y ago
        FreeBSD. Let me know how it goes for you. Genuinely interested.
        johnny22 4y ago
        seems there's a port now (based on electron 13), although not merged upstream
      - speedgoose 4y ago
        FreeDOS perhaps.

tapoxi 4y ago

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?

throw10920 4y ago
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.
TYPE_FASTER 4y ago
Don't forget Silverlight!
yardie 4y ago
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.
aejae 4y ago
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 4y ago
  Please don't make Linux users suffer because of Windows.

drcongo 4y ago

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?

aejae 4y ago
Yep! https://docs.microsoft.com/en-us/microsoftteams/teams-memory-usage-perf#:~:text=Teams%20is%20designed%20to%20use,browsers%2C%20including%20Edge%20and%20Chrome https://docs.microsoft.com/en-us/microsoftteams/teams-memory....
- drcongo 4y ago
  Good lord. I can't imagine Apple putting out an Electron app.
  - raydev 4y ago
    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.
    - heresaPizza 4y ago
      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
    - oscarmv 4y ago
      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.

jenscow 4y ago

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 4y ago
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.
- jenscow 4y ago
  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 4y ago
    None of that Win32 UI stuff is being updated anymore so it’s more “classic” than “native.”
    - marwis 4y ago
      One could say both are native Windows UI toolkits. Kind of similar to when Apple shipped Carbon and Cocoa.
- captainmuon 4y ago
  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.

ravenstine 4y ago

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 4y ago
“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 4y ago
  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).

holbrad 4y ago

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 4y ago
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.

me_me_mu_mu 4y ago

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.

SureshG 4y ago

> because there’s nothing better! You should check out compose multi platform - https://www.jetbrains.com/lp/compose-mpp/ https://www.jetbrains.com/lp/compose-mpp/

tinus_hn 4y ago

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

ChasingEchoes 4y ago
yes. There is only one that i can think of. Notepad++

NicoJuicy 4y ago

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