I somewhat understand the hate for electron but as a non-Mac user I'd much rather have access to this app - and I suspect the author would rather have me pay them for it. For such niche software it seems silly to build it so platform specific.
To get that kind of native feel in an electron app is either impossible or going to take a lot more work than just using native SDK's. There's a reason people hate on electron, because it's a bloated alternative that merely comes close to having a native feel.
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.
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.
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.
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.
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.
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.
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?)
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.
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 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).
What's the purpose of being able to embed an image in the sheet? Is it intended to be an aid to `tracing' an image when creating ASCII art, or does it have some other purpose?
I’ve used images scattered around the art board for reference. I like to copy brandur’s diagrams a lot, so I’ll usually have a couple of his on my board to reference.
This looks pretty cool, though unfortunately I'm not near my Mac so I can't really check it out. I'd be interested to know how its freehand pencil tool compares to JavE's (http://www.jave.de/). I always thought that was the coolest feature of JavE.
The post even mentions a Big Sur / Monterey visual refresh currently in development. As "maintenance mode" projects go, this looks like the best of the best.
An implicit assumption in software seems to be that for it to stay relevant, it must be perpetually evolving. But there is something to be said for deciding a piece of software has reached it's intended potential and simply maintaining it.
Granted, it sounds like the author feels like there are more meaningful things to add or change, but that doesn't mean the software is any less relevant than it was 3 years back.
Long-time user here. Laying out newsletters, flow charts, diagrams, and figlets. It has very few issues these days, and only a couple minor points of frustration in the UI. For my purposes, it's the best thing out there.
A couple of workflow tips for using Monodraw:
* Open a few docs in Monodraw at a time and leave them open for your different needs: text boxes, figlets, diagrams. Each with a few elements already waiting to be filled, cut & pasted, etc.
* For larger docs (e.g. newsletters) finish the writing in your text editor and bring it into Monodraw. Think Publisher or InDesign. Yeah, you can edit in here, but it's weird. Best for layout.
* Browse the sample file that opens by default when you load Monodraw. Good fodder in there.
* Snippets!
* Yes, it is just text but there is FILL to give order (front to back) of elements. This is really handy for making slides that expose a list one item at a time.
* Cut and Paste chunks in and out of your Monodraw file with your main document or take a clipped screen capture for dropping into a graphic or fancy format document (e.g. Illustrator). No need to export and paste.
ASCIIFlow is a less full featured web app with similar functionality to Monodraw, for all the windows/linux/chromebook users wishing for an electron version
I was looking to see if this had been mentioned yet. As a Monodraw owner who recently has been forced to only use a Windows laptop for work I was pleasantly surprised a couple months ago by another article on hacker news that referenced this great web app. Just so happened in the comments here I also learned about Moebius which I also want to try out.
I learned about Monodraw from Thorsten Ball’s interpreter / compiler books. The book has really beautiful illustrations and ASCII drawings, when I asked the author they directed me to Monodraw
Ha! I was going to comment in here that I used Monodraw for the book and really fell in love with the tool.
What I did more recently is to use Monodraw to create diagrams of CFGs and put those next to the test cases (see [0] or [1]) which exercise those graphs - the power of ASCII, you can just copy the graphs into your code.
While Monodraw seems to have business related features I feel the need to mention "Mœbius ANSI Art Editor"[0] a cross platform open source alternative.
Moebius is a new ANSI and ASCII Editor for MacOS, Windows, and Linux.
With a neat Moebius Server feature that allows collaboration by multiple users on the same canvas through a server instance.
Electron is a runtime environment that evolved out of a browser, not a browser. This app doesn't have any browser functionality I can see, like open arbitrary websites, but it does have its own system menus, icon, it's directly executable by the OS. By that logic no software written in an interpreted language can never be cross-platform, you'll always need a runtime environment.
Desktop files (on Linux & Windows) are just nothing than a text file with description/meta info and a link to local executable or any other sort of file* - that is NOT related in any way to executable at all.
> it's directly executable by the OS.
Because it is browser (Chromium) with a custom browser-extension by design.[0]
This has like...none of the features of Monodraw? Drawings aren't objects - this is just a canvas. This is not an alternative to Monodraw - but an ASCII painting app.
Remember, when embedding ASCII art in HTML, hide it from screenreaders and provide alt text. Otherwise it's an incomprehensible mess of seemingly random characters.
A simple approach is best. I don't have a screenreader on my current machine (as far as I know) so I can't verify actual behaviour right now, but according to MDN:
> ...most screenreaders will consider the element with role="img" set on it to be to be like a black box, and not access the individual elements inside it.
Neat! I'll make sure to do it this way. That makes me wonder, what else on the websites I (not a web dev) maintain might need special treatment for accessibility. Pity the Chrome dev tools don't seem to help with that.
This is why I love the Mac. Even obscure apps have a beautiful interface and easy to use web site. I know this is incendiary, but I must say it: on Windows, this app's site would have seven giant, fake download buttons, the actual download would play an ad, and the app would look like something from a fever dream.
There was a windows compatible app posted here and I can't see ads or fakery. I do see the fever dream aspect, but you have to concede that we are talking about ANSI art here. Which is basically fever dream art in a lot of cases.
This allows you to write Markdown-style documents, including ASCII-art diagrams, but which render beautifully in any browser with JavaScript. Using Monodraw or ASCIIFlow as the front-end editor, you can drop most results in a Markdeep document. Bonus: good inline math typesetting plus loads of other awesome document features.
But I actually need more types of diagrams, so slowly, as one of many little side projects, I've been building a little library for all kinds of ascii diagram generation
108 comments
[ 3.3 ms ] story [ 175 ms ] threadI bought this app years ago - I have a feeling it might even predate electron?
It's awesome for embedding simple diagrams.
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's an interesting choice to do native.
That said, very impressive work.
This isn't really true when supporting a single platform, assuming the author is fluent in AppKit etc.
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
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.
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.
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.
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.
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.
BTW. there is a paid native slack client: https://shrugs.app
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.
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.
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.
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.
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).
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.
Still works well though.
Granted, it sounds like the author feels like there are more meaningful things to add or change, but that doesn't mean the software is any less relevant than it was 3 years back.
A couple of workflow tips for using Monodraw:
* Open a few docs in Monodraw at a time and leave them open for your different needs: text boxes, figlets, diagrams. Each with a few elements already waiting to be filled, cut & pasted, etc.
* For larger docs (e.g. newsletters) finish the writing in your text editor and bring it into Monodraw. Think Publisher or InDesign. Yeah, you can edit in here, but it's weird. Best for layout.
* Browse the sample file that opens by default when you load Monodraw. Good fodder in there.
* Snippets!
* Yes, it is just text but there is FILL to give order (front to back) of elements. This is really handy for making slides that expose a list one item at a time.
* Cut and Paste chunks in and out of your Monodraw file with your main document or take a clipped screen capture for dropping into a graphic or fancy format document (e.g. Illustrator). No need to export and paste.
Locking should prompt you on any attempt to change the document to unlock or duplicate.
Stationary Pad will automatically create a local copy when you open the file, and instead open that copy.
https://asciiflow.com
Then started using monodraw. Love it.
Here is a sample chapter from the book (in PDF) - https://compilerbook.com/sample.pdf
What I did more recently is to use Monodraw to create diagrams of CFGs and put those next to the test cases (see [0] or [1]) which exercise those graphs - the power of ASCII, you can just copy the graphs into your code.
[0]: https://twitter.com/thorstenball/status/1363053307409932288 [1]: https://twitter.com/thorstenball/status/1368802505963016197
Moebius is a new ANSI and ASCII Editor for MacOS, Windows, and Linux.
With a neat Moebius Server feature that allows collaboration by multiple users on the same canvas through a server instance.
[0]: https://blocktronics.github.io/moebius/
Not a cross-platform, but JavaScript-extension with cross-platform Chromium browser bundled.
Without browser this "browser extension" (Web-app) could not run on any platform.
Desktop files (on Linux & Windows) are just nothing than a text file with description/meta info and a link to local executable or any other sort of file* - that is NOT related in any way to executable at all.
> it's directly executable by the OS.
Because it is browser (Chromium) with a custom browser-extension by design.[0]
[0] https://en.wikipedia.org/wiki/Electron_(software_framework)
Some past threads:
Show HN: Monodraw, an ASCII Art Editor for Mac - https://news.ycombinator.com/item?id=9545252 - May 2015 (53 comments)
Monodraw: Powerful ASCII Art Editor for Developers (Mac) - https://news.ycombinator.com/item?id=9145945 - March 2015 (3 comments)
Show HN: Monodraw for Mac, ASCII Art Editor – Beta Available - https://news.ycombinator.com/item?id=9138039 - March 2015 (11 comments)
ASCII art editor designed for the Mac - https://news.ycombinator.com/item?id=8445087 - Oct 2014 (107 comments)
> ...most screenreaders will consider the element with role="img" set on it to be to be like a black box, and not access the individual elements inside it.
(https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...)
Demo: https://www.youtube.com/watch?v=LDbi56U5qRw&ab_channel=gnuma...
git://bitreich.org/gramscii
This allows you to write Markdown-style documents, including ASCII-art diagrams, but which render beautifully in any browser with JavaScript. Using Monodraw or ASCIIFlow as the front-end editor, you can drop most results in a Markdeep document. Bonus: good inline math typesetting plus loads of other awesome document features.
But actually more often I've needed things like https://github.com/weidagang/text-diagram as it is much easier to maintain
But I actually need more types of diagrams, so slowly, as one of many little side projects, I've been building a little library for all kinds of ascii diagram generation