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 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.
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.
My strategy would be Cocoa for MacOS/iOS and Gtk for Linux/Windows.
Although of course, it does mean you probably have to touch C++ sometimes.
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.
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.
> 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.
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.
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).
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.
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.
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."
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.
Mac Messages was comically just a plain webview for years. Again, that changed with Catalyst.
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.
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.
https://techcommunity.microsoft.com/t5/microsoft-teams/teams...
> Evergreen distribution. Rely on an up-to-date version of Chromium with regular platform updates and security patches.
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!
Because of this, I write longer emails in a text editor and paste it into Outlook when I'm done.
Try this if you haven’t already: https://superuser.com/questions/989951/is-it-possible-to-dis...
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.
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.
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.
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?
You should check out compose multi platform - https://www.jetbrains.com/lp/compose-mpp/
Notepad++