Can people stop using electron for editors? This is why software quality is dropping. People are ok with shoddy slow bloated apps as their primary editing interface.
I dislike Electron as much as the next person, but I think a big part of the issue is that there really aren't great cross-platform options out there and it's hard to keep a consistent UX across platforms if you're reimplementing things for each OS.
I guess I'd ask: what would you (or other people here) use? There really isn't one that offers a great native experience cross-platform.
Flutter won't ship Chromium, but it'll bring along its own runtime, widgets, and rendering engine rather than using what's provided by the OS. .NET MAUI uses native widgets, but it's difficult to create one API that uses native widgets on different operating systems given that there are subtle differences between similar widgets on different operating systems. MAUI Blazor Hybrid solves that issue and doesn't ship Chromium, but you aren't getting native widgets.
I think for an editor to be successful, it needs to be available on Mac, Windows, and Linux and it's really hard to maintain parity if you're developing the UX separately. As I said, I'm not an Electron fan, but it does allow for easy parity across platforms.
In this case, the reason it's Electron is that it's not just meant to challenge VS Code, but it's essentially the same codebase as VS Code - like how Edge is the same code base as Chrome. The point of the project was a VS Code that was truly free software rather than an open source core with a bunch of Microsoft stuff around it.
As someone that is programming since 1986, wrote software across multiple 16 bit platforms, and has his own share of Web and desktop development experince, it is more like people aren't willing to put in the effort, more than anything else as lame excuses.
> but I think a big part of the issue is that there really aren't great cross-platform options out there and it's hard to keep a consistent UX across platforms if you're reimplementing things for each OS
All that's needed is taking TextAdept or KDevelop or Kate (these are all cross-platform already) or some such editor code-base as a starting point and (A) bringing in VSCode's NodeJS-based extension host and (B) implementing out VSCode's surface extension APIs against that native backing mature editor code-base. Voila, all the great VSX extensions out there are salvaged and ready to use, with no more Electron or MS dependency.
Quite icky and boilerplatey though, not as sexy as starting yet-another-whole-new-editor from scratch... plus the whole latent "ever-having-to-keep-catching-up-to MS VSCode" responsibility ... no wonder no one's on it. Neither am I.
VSCode's extension APIs' restrictions wrt GUI extensibility are a god-send to any theoretical alternative implementors of those APIs. It's just that there aren't any =)
I think they're saying that the point of each OS having different UI frameworks is so that all apps on that particular OS have a cohesive aesthetic and "feel native." That necessarily contradicts the desire to have the same UX across various OSes, however. (And I think "feeling native" is something no popular programs have done for a long time.)
> "Feeling native" is overrated. Most users want a fast reponsive UI, THAT kind of "native".
We seem to have forgotten it now, but back in the day we had this idea that a platform should have a standard UI to which all applications conform, so that the user can transfer knowledge in using one application to all the others, and they don't have to memorize a dozen different ways of operating to use a dozen different applications.
To that end, dating all the way back to 1984, Apple developed user interface guidelines that specified things like how dialog boxes were to be laid out, what the various menus and options should be, and what were the keyboard shortcuts for common operations.
This was the revolution that enabled all sorts of creatives to integrate computers into their creative work, and for the longest time it was Apple's advantage in the marketplace. Mac users, many of whom were creatives in the print, graphic design, music, and film/television spaces, were very picky about their UIs because they spent so much professional time in them. If you did not conform exactly, down to the pixel, to Apple's user interface guidelines, the users would notice right away, and you would be one-moused so hard in MacWorld your business might never recover. (That's another quasi-lost thing about the Mac ecosystem: people liked paying for good quality software.)
Accordingly, it was accepted dogma to never, ever, ever use a "cross-platform UI framework" if you targeted Mac, because the cross-platform frameworks never got the fine details right, and the fine details mattered. It's called "polish", and it's something the open source world never got (thanks in no small part to fucking X windows and all its stupid "toolkits"), and now that open source and the web have eaten everything, the rest of the programming world has forgotten.
Cohesive is important but what's also important is playing nice with the respective OS's design guidelines. For example, take dialog boxes and the order and positioning of "OK, Cancel" buttons.
If .NET is an option (since you mentioned MAUI) I would have gone with Avalonia.
It's like WPF, which was used for Visual Studio, except it's cross-platform and can target Windows, macOS, Linux, web, iOS, Android (and from what I can tell, even TV). Personally I've had nothing but a great time with it.
Unfortunately Microsoft has too many Web devs taking over the old Windows development culture, when it isn't Electron, it is Webviews all over the place.
See all those efforts with Blazor integration across all desktop stacks, MAUI (!), and the use of React Native in WinUI, Office and XBox.