4 ms·
I'd be interested to hear as to why you couldn't achieve the functionality of this app in Electron. I agree with you that it's almost impossible to get a nativ
by ajford 5y ago
I'd be interested to hear as to why you couldn't achieve the functionality of this app in Electron.
I agree with you that it's almost impossible to get a native UI feel in electron, but that's not always the first priority.
If the end goal of the application is to present a custom interface for drawing on a monospace grid for ASCII art, I'm not sure I see the argument that a native UI is necessary over any cross-platform kit like QT or even an html based UI. I totally agree on shortcuts being a problem. Dealing with those cross-platform can be a headache when sufficient care is not being taken. Especially from an outsider to the platform.
As a long-time linux user, most of the interactions on OSX feel wrong to me, but I know it's me that's the problem. If I were to write shortcuts for the OSX platform, I'm sure I'd get most of them wrong. Conversely, if an OSX developer was writing shortcuts for a linux or windows platform, I'm sure they'd face the same issue. It really benefits to have a platform expert you can consult for testing.
I'm not trying to eschew the need and benefits of native apps here, I was trying to point out the fact that the large amount of hate for Electron (and similar web UI on desktop solutions) have their place.
Heck, this entire app could have been a web app. I'm sure a few out there exist to do very similar things.
There's dozens of ways to accomplish things in the wonderful field that is software development, and the whole "this tech is bad" cargo-cult is more a disservice than anything. There are pros and cons to every decision that goes into an application, and taking a stance against one method without considering the use cases and how it could benefit or hinder runs the risk of loosing out on promising tech or excluding people from using your project.
I've seen Monodraw a few times over the years, and I've lamented the fact that I haven't been able to use it, which is what drew me to make my original comment.
- robertoandred 5y agoOne example: native document-based Mac apps have file handling functionality in the window's titlebar (rename, move, tag, etc). It's very convenient. Electron apps don't. Another: native Mac apps by default reopen where you left off. Open windows, open documents, etc. Electron doesn't get this functionality automatically; you could spend time recreating it, but it still would integrate with native settings. Another small example: native Mac UI controls reflect the system-wide accent color the user's selected. With Electron, you'd have to either spend time rebuilding the functionality or omit it. Mac users like Macs because Macs work like Macs. Electron apps ignore the benefits and features Mac apps usually get automatically and just revert to the lowest common denominator.
- ajford 5y agoThat's less of why the app couldn't be written in Electron and more of why Mac users wouldn't like an Electron app. Perfectly valid reason why someone would want to write their app as a native app though, and I appreciate that. Some of those are definitely things Electron gets wrong and should correct. Handling system-wide accent colors is exactly the kind of thing my UI kit (Electron in this argument) should be handling and not forcing everyone to re-invent. I've never used or even heard of the titlebar file handling functionality and had to search that right now. This is exactly the kind of thing I've said about discoverability. I used OSX for three years daily, and I've been using it on and off as needed since around 2010. Some things that people love and use all the time are just not obvious to everyone.