Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I get the hate that Electron gets for it's weight and overhead, but this is a perfect example of why Electron has value.

This app has no dependency on native OS for anything beyond writing data. It doesn't need to compile heavy code bases, it doesn't need fast GPU or other access. It could have very well been an electron app, and it would have the benefit of being widely available on many platforms.

I'd love to be able to use this app, but as a Linux and Windows user, I'm unable to. So I'll be searching for an alternative that runs on the platforms I have access to.

That said, no hate on the author for building the tool to their needs and desires. It's a fantastic looking app, and looks well executed. Wish I could use it.



It would not be possible to do this in electron.

To have the same great native feeling UI you’d need to use AppKit - not HTML.

Don’t get me started at the usual shortcuts and general platform behavior most electron apps get wrong.


The insistance on native feeling UI and shortcuts is something I only see from Mac users. I think the app would work perfectly well in Electron but would just attract the usual complaints from Mac users.


One potential conclusion: Mac users understand the productivity increase and the value of apps feeling native, since the Apple ecosystem is one of the primary places to get such a native experience today.

This shouldn't necessarily be interpreted as "Mac users are special flowers", but rather, "Mac users may have stronger opinions about this because they've experienced the benefits of native apps".

I've been around the block with operating systems, and was primarily a Linux user for many years. Later in my career, I started to appreciate the simplicity and consistency of the Apple ecosystem, and while I recognize that's not everyone's thing, it lets me focus on the job at hand and spend less time learning how to use new apps/tools. This is valuable.


That's a great conclusion. Sadly the way it's usually felt is through entitlement. I can't count the number of time where I've seen an electron/Flutter/anything app presented, and Mac users are once again asking for a native app while pretending to not understand why the app is cross platform in the first place.

If they're so attached to native apps, maybe they should build a website/community where people ready to pay more for native apps can say they want for example a native client for slack, discord, spotify, and then the companies can see if it's viable or not.

My problem is that these complaints are exactly like "the back button is broken", it doesn't bring anything new or interesting to talk about, people never propose to help a project or to pay money for new features, they just complain and never stop. This isn't good content for Hacker News in general.


I'd say that if you had to choose a desktop platform to build paid apps for Mac OS is the best choice. Mac users tend to spend (more) money on software.

BTW. there is a paid native slack client: https://shrugs.app


Another take on it is that Mac decided to go a different path on a few different UI things in the past, and that has persisted to this day.

Look at how *nix, Windows, Sun, BSD, Chrome OS (which is basically a linux anyways) all use Ctrl, Meta (alt), and Shift for their hotkeys, compared to how Mac uses Hyper (cmd).

Also look at how Mac has one instance of an app's tool bar/menu that all windows share.

I'll agree that the consistent UI is a boon, but there's a large lack of discoverability imo, and some things that are just entirely lacking, like the ability to move windows around with hotkeys.


You've got the order reversed. Mac pretty much defined the modern WIMP UI and was the only real game in town for consumers & professionals from 1984 - 1990 when Windows 3 was released, and during this time an entire industry (DTP) was built atop Mac's strong UI foundations.

It's more accurate to say that in modern UIs the others decided to each go their own different paths and replicate part of what made the MacOS experience special, but they also tended to forget to include a lot of the little details that made it great, and have never had the same dedication to consistency.

Re: discoverability, there's an order to discovering advanced options in MacOS - hold Option and click on menus. You'll be surprised how far that gets you. The whole idea of MacOS and native apps is you learn how to use the system once, and you're rewarded from thereon out. Not all things are discoverable without these keys because not all things are relevant for everyday uses and can add clutter - its a design choice to make simple things easy and hard things possible. They're not always perfect but they're still the best game in town.

RE: moving windows with hotkeys, just get an app like Magnet, problem solved.


Because some of us are shut down with responses of "be happy you got this app at all" (Linux users) or somehow get ignored when we speak up (Windows users - though I guess Windows hw often having more cpu power and memory leads to less complaints?)


I'd rather not have the app than have a version that feels out of place on my system.


An Electron app always requires extra muscle memory. Every Electron app is different from the other, they all miss the UI consistency that makes the Mac so productive to use.


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.


One 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.


That'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.


It's totally possible to do this in Electron. I've used plenty of Electron apps that were simply ripped off MacOS and dumped on Linux (Kitematic, for example). The entire Mac-native UI works perfectly fine on Linux, the only issue I ran into involved some Mac-ified ini files.


What do you mean by `Mac-native UI`?

I guess they tried to make the app look like a native app?

The interesting part is that this is even worse IMHO. Because you get into an uncanny-valley pretty soon.


Given the rapid development and maturity of virtualization, container, sandboxing, and emulation technology: to me it seems rather silly that it's not yet trivial to run macos and windows apps (and anything else one would want) transparently, side by side on the same machine. I'm not normally a microsoft fan, but their direction with WSL2/WSLg/WSA feels very interesting...


I like seeing devs embrace native frameworks. Electron apps just do UI so differently that its just a pain to use. For example dragging a file tab out of vs code doesnt create a new window like every other editor.


Just because it's not implemented yet doesn't mean it can't be implemented. Electron can do anything a native app can because it is a native app itself.

Anyway, you can do it without dragging which is actually even better. Just do Ctrl+K, O or on a Mac Cmd+K, O.

You can track when this feature is implemented here - https://github.com/microsoft/vscode/issues/8171


"you can do this thing in a completely different way than the native OS trains you to expect to do it, actually this is even better!"


Pfffft. Yeah, imagine using the mouse more than the keyboard for a coding tool though?


it's an art program ffs


No, VS Code is a coding tool.


I think you underestimate a lot of the APIs for a platform and how they influence an app; Cocoa provides a lot for an application; for example, it can provide a lot of the structure for a document related app in terms of i.e undo/redo, window management, etc.


Get a Mac :) I would have not bought this app if it was not native. I love using it because the look and feel. I value this kind of beauty, call me a weirdo…


Lol. Had one for almost 3 years. Not interested in going back. I personally prefer my Linux laptop and home lab, with my Windows desktop for all things gaming and 3d CAD related.

I appreciate the vertical integration Apple has in all its products, but after feeling like I was fighting the system for almost 3 years, I was happy to no longer have to use it for my work machine.

To each there own though! I'm glad you enjoy it, and I'm glad to see Monodraw get the attention it deserves (it's genuinely a very cool app).


> It could have very well been an electron app, and it would have the benefit of being widely available on many platforms.

There's nothing so intensive about it that it needs to be an Electron app either. It could just have easily been a cross-platform native app as well.


This is why Qt or Flutter are interesting.


And think about how much more work it was. And how much more work it'll take to maintain and update.

It's an interesting choice to do native.

That said, very impressive work.


> And think about how much more work it was. And how much more work it'll take to maintain and update.

This isn't really true when supporting a single platform, assuming the author is fluent in AppKit etc.


AppKit apps also don’t usually break that easily. It’s surprisingly simple to get an abandoned OS X 10.0-10.4 era Cocoa app compiling and running on modern macOS, I’ve done it a couple times just for kicks.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: