Clearly not. The least effort is to use the platform’s native widgets, or at least a decent toolkit. Those shiny web-based interfaces suck because the developer never put the effort to make the widgets behave as they should, and that’s because it’s actually very hard and expensive to build a UI framework from the ground up. Have a look at UITextField or NSTextField and what they do out of the box for free, for every single application. Nobody is going to implement half of that in their fancy text boxes. The only reason it takes less effort is that everybody half-arses it.
The consequence is that most Electron apps are a dog’s breakfast and the polar opposite of consistent and well made.
In my experience, producing a polished Electron/web app takes substantially more effort than it does to produce an AppKit/UIKit equivalent. Those don’t get you multiplatform, but that’s why a lot of devs who care about these things only publish for macOS and iOS.
Going the Electron route is the first and strongest signal that the developer doesn't care about the tid bits that makes a great app. Have never saw a good designed Electron app.
I actually think VSCode is one of the best use cases for Electron. It enables a robust and well-documented set of APIs for extension and theme developers, which IMO is why it has one of the most thriving extension ecosystems out there.
Disclaimer: I work at Microsoft, but not in Developer Division.
> It enables a robust and well-documented set of APIs for extension and theme developers
Didn't VIM and Emacs have that for ages? Look at https://vimawesome.com/. I think the remote development extension is nice, but most people would just SSH and run their editor on the server or sync their project's files.
Do you as a user seriously want a 400MB binary that takes up 1 GB of memory at least just to have a sluggish interface to run a command line program for you when it could be an instant GUI that takes up 1 MB of memory ?
Why would anyone want something taking up literally 1000x the resources it needs to?
Electron and consistency?? I get Electron being easier to develop for, but it achieves portability by ignoring platform native UI guidelines. There is no consistency at all between electron apps.
Hey, maybe I want to learn two dozen different slightly incompatible UI paradigms! If I don't have constant impedance mismatches I might get lazy and be able to operate my computer with continuous partial attention and actually focus on the task at hand! Shit, just imagine the horror if two different applications could grab keyboard focus correctly without clicking some input field. My fingers might never leave the keyboard!
I grew up with this mindset on macOS/iOS, and went with it for many years.
Apple itself isn't consistent enough anymore for it to matter / there to be one true way. Pick a design system and roll with it, definitely - but slavishly trying to figure out the One True Way on a particular platform A) isn't likely to work out, even just focusing on design B) is a long-term handicap. Most people have a mix of devices in their life.
A soothing thought if that's hard to process: Jony Ive always had something to say about how the hardware becomes the app, especially post-iPhone. People expect the app to be familiar across platforms. (of course, there's all sorts of nerd-sniping caveats from there. Of _course_ you should use the platform's print dialog, etc. But don't get hung up on ex. what the Apple Reminders app looks like this year on iOS and OS X)
The reality is that for most people, they use an app on a sibgle platform (typical end users don’t constantly switch between Windows, Linux, and macOS) so that consistency does not primarily benefit the end-user.
Exactly. The consistency being extolled here is not from the perspective of the users but of the marketing department that wants to warp basic UI conventions in service of making their branding a more pervasive part of the user experience. Users basically never want you to give them an app where even the buttons and scroll bars are changed to comply with your corporate style guide.
I remember raging with our designers over this, when building a mobile app. They were insisting on controls that look and feel exactly the same on iOS and Android because of some vague need to have consistent marketing/branding. Which ultimately meant custom controls (sometimes 10x development effort) that were not familiar to users on either platform. No user wants this. It's desired entirely by companies whose design department is too focused on their own designs.
The same is true for desktop applications. No macOS user wants their application to look like a Windows application and no Windows user wants Mac controls.
On the other hand, if Google Docs had system-native controls for every useragent that could connect to it, nobody would have any clue how to do anything and search for a new online document editor. It's not the overwhelming love for Material design that makes Google Docs look non-native, it's the experiential consistency for enterprise customers and less computer-obsessed end-users. If that amounts to sacrificing usability for branding, then Apple is just as guilty. Design is just part of building a product, and prioritizing your specific OS is not a realistic expectation from cross-platform products.
And for professionals, I don't even wager this consideration takes place at all. I don't see anyone protesting Ableton Live or Pro Tools because their developers didn't use the native MacOS button widget.
The complaint that Chrome eats all your RAM is because it starts a new process for each tab, with all the overhead that entails. You’re not using multiple tabs in an Electron app.
Clearly not. The least effort is to use the platform’s native widgets, or at least a decent toolkit. Those shiny web-based interfaces suck because the developer never put the effort to make the widgets behave as they should, and that’s because it’s actually very hard and expensive to build a UI framework from the ground up. Have a look at UITextField or NSTextField and what they do out of the box for free, for every single application. Nobody is going to implement half of that in their fancy text boxes. The only reason it takes less effort is that everybody half-arses it.
The consequence is that most Electron apps are a dog’s breakfast and the polar opposite of consistent and well made.