but anyone can create an electron app these days with total control over the UI polish with way less effort.
in fact electron seems like the perfect use case here for a ffmpeg UI wrapper. surprised no one has done it.
in fact electron seems like the perfect use case here for a ffmpeg UI wrapper. surprised no one has done it.
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.
Disclaimer: I work at Microsoft, but not in Developer Division.
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.
Why would anyone want something taking up literally 1000x the resources it needs to?
No, there is not but there is consistency between platforms of the same electron app. Something that's much harder to do if you write a native app.
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.
And generally speaking, yeah, people are happy to use Microsoft Office. The Mac version is nearly identical to the other versions. The "branding" is ignored or even applauded, because it enhances the overall consistency of the app. You might even be able to argue that Office on Mac only feels native because it goes out of it's way to not look Mac-native.
Regardless though, for non-Microsoft-sized companies it's not really realistic to ship, test and maintain multiple versions of the same app. It's much easier to pick one cross-platform framework and commit to it whole-heartedly, which is why we really only see native apps for single-platform or Microsoft-scale apps.
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.
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)
Most of the time it's people who only know javascript and have never even heard of GUI libraries that say this.
It also looks shit on every platform then.
And eats all your RAM