Having just installed SolveSpace, a parametric 3D CAD tool which includes a solver in 1.9 MB, I can't help but feel a bit sad when a minimal Markdown editor is a 34 MB file :(
I wonder if there's a better option for crossplatform apps than Electron. Maybe Rust? Or Python+PyQT?
While I agree and upvoted you, I think the realistic answer is that the alternative to this 34 MB editor is no editor like this at all. The author made what they wanted with the tools they knew.
If the binary size is big because of the (lack of) tools the author knows, the alternative to this is an editor made by someone who knows tools that don't bloat the binary.
This exists because the tools existed to enable the author to make this in a reasonable timeframe/effort.
If something better/smaller exists, use it. If it doesn't exist, it might be because making it smaller requires tools that take more effort/time to use and thus no one has bothered.
I've traditionally liked crapping on bloated software too, but have come to realize that the plethora of software is fine and I can use whatever I like and abstain from what I dislike. The simple fact is that the alternative to bloated software is a subtraction of that software. And sometimes they happen to be useful, despite their size.
But my comment was really in response to your second line here. I disagreed with your assertion. The alternative is that this editor doesn't exist, meaning "no editor at all" with this specific featureset/design/etc. And if this editor is better than a less bloated editor, why shouldn't it exist?
I agree with you, I just think we need to find/publicize/develop a better solution for writing lean applications for the desktop. It's really sad that our easiest option right now is something that results in a 35 MB distributable package.
I think we've lost the binary size battle, just as we've lost the bandwidth battle. I agree, there has to be a better way, but development convenience is being prioritised.
I still remember the days of C64 and the 640kb limitation in DOS. What we got was first optimization then full on hacks and mostly assembly language.
To use a tool and give up on size really doesn't bother me. I rather have elegant solutions then full on hackery or difficult memory management type solutions.
I'm really glad we're finally starting to win the dynamic library battle; it was a kludgey fix for a transient storage bottleneck that has been plaguing us with unnecessary complication for at least a decade now. Predictability is a good thing.
Meh, I feel like it is even better because even if you could update the library indvidually you have no idea about the ramifications of such an update and what potential other vulnerabilties/bugs doing so will uncover.
You could install the electron or nw.js runtime separately and then just download/distribute a compressed file with the JavaScript source code. Witch would be smaller then most programs.
SolveSpace looks exactly like the sort of "user-unfriendly" tools I build for myself and am absolutely personally productive on but would never release to the general public. Maybe I need to re-think this ;)
That said I'm getting back into GUI editors. Anaconda for research computing. And Atom for text and code. Including Markdown.
The advantage is Atom's module system. 5000+ third-party creations. Including really edge cases. That, I believe, is due to the reach of JS/HTML/CSS.
Yep, I was stunned when I realized the total distribution size for a tiny script I wrote that used numpy+scipy would run over 300mb. And here I thought Electron apps were big...
Qt is not bad.
I got interested in libui (https://github.com/andlabs/libui), but it stalled a bit, after a couple of months of very promising activity.
i wish D had good, complete qt bindings. it seems like the best option for a new standard compile-to-native desktop gui app language. i have a personal preference for ML-family languages, but i think those have already lost the war for mindshare; D on the other hand is solidly C-family and therefore familiar, but is a way more pleasant language than C++.
I do agree with everything you said, but a) I'd still rather the giant than jupiter and b) Nim still has a long way to go to prove itself. Just like D, it is in the awkward position of being high performance without fully addressing either the performance or safety concerns of the preceding languages. This may be an acceptable tradeoff but neither have any killer features that make it an obvious good fit for a given problem. Rust has memory safety-like, actual memory safety-and go has utter simplicity. What is the Nim two word pitch? Small binaries isn't going to win anyone; that's what deflate is for. Meanwhile, you don't have the language stability and, erm, prudent design that D has hammered out for over a decade. Even if I don't agree with the decisions I can't say D has executed poorly.
Nim though? Who knows! I've never seen it in production, so I can't tell the downfalls!
I live in Australia, but despite it being a first world nation, the Internet speed is miserable and bandwidth is precious. (I pay $50 a month for 100gb, at 1.5mbms). Size still matters.
I do quite like D and the structured process of developing the language they use.
But I also find it incredibly depressing that Nim has a better optimising compiler.
go-qml and forks don't support Go >1.6 due to the cgo breakage; some manage to compile, but with a memory leak.
There's github.com/therecipe/qt which is a full Qt binding (not just QML). You have to set-up a proper dynamic linking build process if you don't want 100MB binaries though, and the bindings require a default Qt installation or a folder full of symlinks to fake one if your Linux distro splits Qt in different folders.
Very different beasts. :) Writing CAD software can be done with a surprisingly small number of libraries, which is not at all withe case when it comes to typesetting.
If creator reads this: I note that its currently free and in Beta. What is the expected cost, and the transition from a beta client to the paid one? e.g. can I just stay on beta forever and only pay if I want to upgrade to get the new features? etc. Looks very nice so far!
I use this daily on macOS and it is a fantastic user experience. The Markdown editor doesn't have a separate preview window. It auto detects your blocks and toggles between editing and rendering. Overall very polished. It has Mermaid ASCII diagramming support, which I love, but I wonder whether the diagrams should be imported images since you would need Typora in order to see it rendered.
Reminder that it is still beta. I'm still hoping for a more unified Evernote-ish side bar since right now it depends on using a file browser of some sort, with no built-in search across notes.
FoldingText.app on OSX and "usecanvas.com" on the web work similarly.
I really like that editing model for markdown. (Hiding all the markup except that which is surrounding or adjacent to the cursor.) I'd love to see someone implement it on top of draft.js or something. (I haven't gotten around to yet myself yet - too many projects, too little time.)
I just tried it. You can drag images into the doc and it will show the image WYSIWYG, but the image url looks to be an absolute path, not a relative one.
I think I may be missing the main usecase here but how come I see so many different markdown editors on here all the time? Markdown is pretty simple and easy to read in plaintext, or with simple highlighting so what's the point?
Or am I just being one of those weirdos that's like "WHO NEEDS SYNTAX HIGHLIGHTING YOU SCRUBS!"?
Just wildly speculating here (with some wishful thinking thrown in): maybe the intent is to indirectly encourage non-technical audiences to use git-based, public version control for authoring public and frequently revised documents.
For instance: imagine if federal legislation, and amendments to federal legislation, were published in this manner. You could examine diffs to see how passed (or proposed) amendments altered (or will alter) the law. You could even have a 'git blame' sort of feature that let you to see which members of congress voted for or against particular amendments. It would definitely aid political transparency, and make it easier for the public to participate in the legislative process.
Maybe. But I guess my hidden objective here would be to open up the legislation making process to the public. At the moment (at least in Australia), the best we can do in this regard is 'exposure draft' consultation.
Basically a draft of the legislation is put on some consultation website, and people can send in big long essays via email. The participants don't see each others' comments, it's just a 1-1 type relationship between the government department and the 'consultee'.
I'd like to see infrastructure that would allow:
(a) consultation participants to see and comment on each others' suggestions (think Greenpeace commenting on Shell's submission regarding fuel tax credits, and vice-versa); and
(b) for participants to be able to make pull-requests, forcing the government department to answer in the positive of negative and give reasons.
On the second point, under the current system they can simply put your submission through the shredder if they don't like your suggestions. By making it very public, government departments will feel strong pressure to acknowledge and respond in a reasoned way. Many government departments do a big song and dance about 'transparency'. I think this provides a concrete and actionable way to significantly increase this wonderful 'transparency' thing that I hear so much about.
> Markdown is pretty simple and easy to read in plaintext
That is actually the main reason for markdown's existence [1], so I have the same issue with these editors. I don't understand attempts to hide the formatting.
"The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions."
I often like to preview how text works as I work on it.
e.g. if I bold this, does it look out of place
or to check that internal links work.
However, I currently just use my normal text editor and open the output in a browser (if compiling to html)/terminal (if compiling to man pages)/evince (if compiling to pdf)
Markdown is simple and easy to read to coders, and others with (for a lack of a better term) mathematical inclination.
It would be really awesome if we could get the current "Word for everything crowd" to use markdown too, and assistive WYSIWYG editors are a lot more attractive to them.
Being able to see what I write the same way as a reader would helps me empathize with them. Perhaps now I can have just one window open instead of Sublime Text + Marked.
I read the page a few times through and I can't find answers to a couple questions. If someone has already installed the app, can you clarify:
- When I save the document, is it just plain markdown as text?
- If I copy and paste it into an input element in my browser that expects markdown, will it be copying just plaintext markdown?
- What if I copy and paste it into something like Microsoft Word?
If the creator is listening, I have some comments for your site:
- I tried clicking/typing on the opening page before realizing I had to scroll down.
- I eventually found that there were some clickable words that changed displayed images, but it wasn't obvious.
- After finding I could click some words, I expected to be able to click the menu options under 'Accessibility' and found it a bit ironic that they weren't clickable.
On the positive side:
- The moving image showing a user typing markdown in and the text transforming is awesome and looks great.
This looks pretty but I can't see myself using it much, I'm usually writing markdown in vim.
Anyone know of a vim plugin to split the window to a live preview for markdown? It is pretty much readable as plain text, but it would be nice to see a preview to know if I've made an error in the markup.
this does not make this a Linux platform solution. Currently I think
1) Provide a RPM and a DEB
2) Provide a tar ball of the source so it can be compiled
3) Using a Linux application installer like flatpak, appimage or snap would also make it acceptable to me instead of RPM/DEB
Thank you for your work but being on Linux isn't simple and I don't think it is accurate to say cross compatible on Linux when all we got is a deb. Hope that in the next 3 years it gets easier.
The best solution I believe for providing packages for multiple of distribution is SUSE Build Services https://build.opensuse.org/. It provides the ability to build once and SUSE build solution will make packages for other distros. So it will make a deb, rpm and you could even have a package for Arch.
Very pretty. I like how it hides the markup, but still feels like you are editing markdown (e.g. <Backspace> removes the hidden formatting characters).
Unfortunately, there is quite some input lag for me (Windows 10, reasonably fast laptop, HighDpi (Yoga Pro 2). I have this in many Electron apps, some less (Simplenote is very snappy, VS Code is OK), some much more (Atom), but it almost alway feels wierd.
Looks nice but isn't the point of markdown pretty much that you can still do your typing in clear, explicit plaintext and then merely generate properly formatted html/pdf/whatnot from it, effectively avoiding any wysiwyg editing?
That's what different mark-up languages such as SGML (HTML/XML), LaTeX, even Org mode, etc generally try to achieve: to separate content and presentation. That is, to write the meat of the text explicitly and not even able to worry about how it will look.
There's a page[1] detailing how to get get the .deb file without apt, and then use dpkg for arch [2] to install it if you wanted to. Of course you'd have to manually update, and pacman won't know about it.
I've been using Typora for several months now. It's the best native markdown editor I've found. Extremely smooth to write in preview mode using markdown notation. Inline math support is nice, but I wish it had block/equation math support. Code highlighting, table support, and YAML front-matters are also great. I love being able to switch between source and preview with command+/.
I want to love org mode, but I don't know it well enough. I've only seen a video that reviewed how great it was, but I haven't seen any tutorials/videos on how to actually use it that went into detail.
I used to use Haroopad [1] unfortunately the author seemed to stop its development some time ago. This seems like a good alternative, in fact, it looks and works so well that I can justify its dependency on Electron. Props to @abnerlee for its work. I will definitely recommend this application to my friends.
I just found Haroopad myself a couple weeks ago, but did note its lack of updates. I may try out Typora for comparison. That said, Haroopad seems to work pretty well for me at the moment.
Fool that I am, I stared at the page for quite some time wondering when the loading animation was going to end and the page load. Then I saw the scroll bar...
Looks nice. I've been using Writemonkey for a few years, but might consider switching to this if the price won't be too high.
The showstopper for me, at the moment, is the non-international spellchecker. I need my native language (Norwegian).
I would also like the option to have a tiny clock in the bottom right of the page (like Writemonkey has). It's useful for fullscreen writing.
Writemonkey is probably the best alternative for Windows. It has way more features, and it's free (unless you need plugin-support). It does not, however, have inline live preview.
It's a little laggy when I'm typing, I keep notes for my whole class, not one file per lecture so the files are decently big. I have found all markdown editors with live preview have this same problem as they redraw on every keystroke and this is fairly slow process with a big document and slow computer. My note taking laptop is not very powerful.
This program looks great and I really want to use it, so I may need to start creating a new notes file for every lecture and then using a script to combine them later and export to PDF.
Nice tool. Like it. Especially like the fact that it does syntax coloring for different languages. There is nothing like this as far as I know. Usually Markdown editors are not WYSIWYG.
Huge fan of Typora. My one issue is with line breaks. I like to edit GitHub README's directly in Typora and add line breaks around the 80 character mark, but Typora's window seems to wrap them differently.
I posted a support ticket, and the developer responded that "the difference is that Typora will render single line break, while Github will ignore those single line break". That's fine, but GitHub parity seems like a top use case, so AFAIK this remains an open issue.
I like it. Used it for >several months. If you have used mou before it is similar. You can edit the themes (ive downloaded some from github) and you can configure a couple markdown flavors out of the box iirc.
It renders in place in real time unlike some of the ones that load on half of the screen.
Worth a download. They smoothed out a lot of the issues with updating content & cursor movement.
Best markdown editor ive used, if viewing the rendered markdown matters to you. You can export as a pdf and a couple other doctypes which is nice for sending to non-technical teamenbers who have no markdown reader.
Not familiar with that. Probably not. Its a few MBs of diskspace & works out of the box. Prob be quicker to dl & dump it if you dont like it.
All editors/notes/workflow are highly subjective, i tried macdown, mou, a bunch of similar os x notes clones, notes, evernote, ect.
I like this for notes & simple docs. I would really like it if it had a sidebar with directories but the reason so many of these things exist is that everyone angry enough just builds their own.
Electron does a bit more than that (full-blown nodejs in background), which of course only increases the footprint. But apart from the final binary size, it's an okay-ish development to work with. Especially for rapid prototyping.
I just installed this and what I found was that it works nicely but, at least on OSX, it renders correctly but doesn't copy # or ## elements during a copy / paste operation. It correctly saves them to do disc but doesn't put them in the paste buffer. Pity. Its a pretty app but if they got that wrong, I wonder what else is lurking.
I don't need another editor that writes files. I could, however, use something I can paste markdown into, fix a formatting issue, and move back to a text buffer in a browser / Github readme, etc.
* paste in a Jekyll formatted markdown document
* select all (which it couldn't do with something of 3,103 words - I had to do it manually)
* shift+command+c to copy it as markdown
* paste it into a TextMate window
* The initial ---- markup to denote the header block is missing
* The tags: [] array statement is converted into a header
Update: I just dug into it some more and there is a specific Copy to Markdown (shift+command+c) command so that does make it a bit more interesting for me as a command+tab paste / fix / shift+command+c way of debugging markdown hell. Apologies for the initial error.
If you just select all and copy a lot of formatting is lost. However, you can go Edit > Copy As Markdown (shift+cmd+c) and that keeps all formatting, even headings
It is a great software. Much better than paid options out there.
I tested it on Mac and Ubuntu. I wanted Windows version too but was reluctant to install it. Is there a portable version of it? I like to keep it on pendrive.
Edit: Don't mind, I loved it so much and I could stop myself from installing it on my Windows machine too.
But I still want the portable version so that I can use it when I don't have admin privileges to install software.
No idea, to be honest. I'm not really using Windows actively any more, but complaints about heuristics detections crop up all the time.
EDIT: I've just uploaded a test electron binary I made myself to see whether it triggers on all of them. 0 detections for mine, but mine are always digitally signed. I'm not sure whether and how that affects heuristics, but theoretically it should.
Isn't that called vim (or insert your actual editor of choice)?
Markdown is meant to be readable while editing, I actually find having the rendered edition on top of your edition really confusing, when you can just open the .md file in your editor while having your preview outside of it updated after each save.
What’s missing in most of these markdown editors (including this one), is the ability to copy the formatted document as clean rich text, for pasting into email and other apps.
For example, a simple document with a list gives you this very clean HTML if you “copy code”:
<p>Here is an email with a bunch of lists:</p>
<ul><li>
<p>Item one</p>
</li>
<li>
<p>Item two</p>
<ul><li>
Item three</li>
</ul>
</li>
</ul>
But if you copy the rich text and paste into a contenteditable field, you get this (ugh):
I'll forgive the application size, because I like it. I hope there are plans to add tabs, because the current approach is a bit clunky, you can switch between open windows with Ctrl+Tab but the windows are independent.
used various markdown editor these years, I now settle down on vscode for editing and if I need export to PDF I use remarkable which does the job well including various utf-8 fonts.
tried typora quickly, it looks nice, however it can't handle export-to-pdf with some asia fonts in it for me, hope that can be improved.
it's fair to say pandoc can't do utf-8 fonts for PDF reliably either.
Makes sense, Typora uses Pandoc under the covers for it's import/export.
I use vscode for my markdown editing also, but the lack of help with tables and other formatting hurt along with the lack of a offline spellchecker makes vscode a bit painful.
it is weird how you could ignore new startups, then use their products later
this is not just an app i like, i actually was going to build this, but when i saw it, i downloaded, tried it, then forget about it
don't be disappointing if small people are using it at the beginning, just keep improving it
Just curious if a WYSIWYG is planned for this. With all the possible languages one can learn, learning one for documentation alone seems like cognitive overload, especially if an application can do it for you
The only draw of markdown is that it's just plain text. If the overhead of learning it doesn't appeal to you then I think a standard WYSIWYG word processor would be a better choice.
I don't see how WYSIWYG conflicts with markdowns version controllability, which is it's real advantage over something like MS word. FYI, markdown has WYSIWYG editors already, and this is one of them. This one relies on keyboard shortcuts versus clickable hints, which MS word offers, making it appealing to a non programmer
I wonder if there's a better option for crossplatform apps than Electron. Maybe Rust? Or Python+PyQT?