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!
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?
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.
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?
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!
I used to be a big Qt fan but I have started favoring Gtk. Glade is better than any Qt designer. And being C based you tend to get better Gtk bindings in other languages. Who wants to develop in C++ these days unless they are doing systems programming?
My strategy would be Cocoa for MacOS/iOS and Gtk for Linux/Windows.
I don't really dev with Qt, but I thought a lot of folks were using QML and sometimes QtQuick these days. Seems to make it possible to hide a lot of the C++ :)
Although of course, it does mean you probably have to touch C++ sometimes.
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.
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.
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.
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.
“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”
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).
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.
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.
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.
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.
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?
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.
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.
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."
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.
And likely be terrible and would get no market share. I don’t know anyone who lives in excel all day who would be ok with the jankiness of an electron app
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.
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.
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.
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.
> 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.
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
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.
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.
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.
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.
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.
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.
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.
>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.
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?
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.
Is a CS grad really that much more capable of creating a native Windows UI application than a "bootcamp-graduated js-monkey?"
I certainly did not learn anything Windows related as a CS major and little to nothing about UI/UX.
Calling people "js-monkeys" is a bad look. We can have a conversation about the quality of applications on different frameworks without stereotyping an entire group of people.
This is a major reason many companies that start native, then try to scale to 100+ person eng teams often end up incorporating web views, and then switching over entirely.
Saw this happen personally for our desktop client at Dropbox.
I think people might not like this since it causes your clients to "phone home" to Gravatar unnecessarily/expectedly. It's a little out of place for what is essentially a network security application.
It's also not like you'd have to have a separate server/vserver for every such project, a very affordable vserver will run quite a lot of nginx containers. Plus I guess some people will have a vserver or something like that anyway (I have a small one to get around NAT at the ISP level), in which case it might be net-zero.
My ISP puts everyone behind some sort of NAT, which means I can't reach my home network from elsewhere since I can't open ports. They'd let me buy my own IP address for a monthly fee, but I've found that an old Pi I already had, an autossh-ed reverse shell, SSH forwarding and a cheap cloud instance work just fine for checking sensors and the like, cost less and the cloud instance has other uses, too.
Not at all. This idea that kids just spontaneously form ideas from a vacuum is obviously false. Inspiration comes from all sorts of guidance. I would have loved to know more techniques for building things when I was a kid and was stuck in the rut of similar ideas for a long time. I craved books that showed how to build things. I also created my own stuff but instruction material was gold. It took you to more exciting things than you could think of yourself.
My kids are way more creative than I at same age... because they watch speed builds on Youtube compared to me in a Vacuum in the 90's.
I absolutely agree that inspiration comes for all sort of things, not only those videos.
I applaud this app, I hope it evolves to offer more value to older kids.
> Kids don’t need an app like this, they still have imagination we’ve long left behind. :’)
My 5-year-old likes playing with built models a lot, and also likes building with instructions, but not free building. More instructions for the huge pile of Lego we have, he would like.
My 3-year-old is pretty much exclusively into (often quite elaborate) freebuilding. Even when kids are super creative, it doesn't manifest in the same way.
I agree, I observed my 3 year old often and he is more creative by applying his imagination. He tends to lose interest in building it himself he see something better than what he created. When I am helping him color and I color it precisely he just lose interest in coloring and say color it please you are better. If I don't help him at all he will finish the whole piece and even be proud of it. Now I color just like him so he will not lose interest during the coloring.
