In terms of cross-platform development I understand wanting to use browser technologies, but these off-line web-applications always feel so flaky and unintegrated. The Atom editor for example still can't switch languages for the spell-checker at runtime, even though browsers themselves can.

> I don't have any recommendations for Linux, unfortunately.

Vim works just fine for MarkDown, Gedit is not too bad either. The whole point of MarkDown is being readable both as text in an editor and formatted by a renderer.

MacDown and MarkdownPad Pro are the editors I use on Mac and Windows too. The Pro version of MarkdownPad has nice support for GitHub flavored Markdown, either using the GitHub API or with an offline renderer.

As much as I like MarkdownPad [Pro], it has its own bloat problem. It uses Awesomium [1] for the preview HTML rendering, which can really chew up a lot of memory.

The original version of MarkdownPad used the native Windows WebBrowser control, but the author didn't know the trick that allows that control to render in IE11 mode instead of IE7 mode. I reported it on their forum over a year ago [2] but it still uses Awesomium.

Anyone who needs to use an embedded web browser on Windows should grab the code in that forum thread. Getting the native WebBrowser into IE11 mode instead of the terrible default IE7 mode makes it a useful control. Since you don't need to bundle an entire web browser with your app, it cuts down the app size quite a bit.

[1] http://www.awesomium.com/

[2] http://forums.apricitysoftware.com/t/why-is-markdownpad-spaw...

It's pretty horrible, but it's the future unfortunately.

The web is ubiquitous. Everyone knows it, and so it's much easier to scratch whatever itch you have in a tech you know than a scary one (C!) that you don't; building for situations you understand (your fast piece of expensive apple tech connected to your fast internet) than ones you don't.

This is exactly what they said about Java in the late '90s and early 2000s, but I have never had any trouble avoiding (non-server) software written in Java, and I doubt I'll have any trouble avoiding non-web software written with web technologies, either.

Sometimes you have to do a lot of detective work to know what technology was used to make the software. Web-tech doesn't ask you to "install Java", for example when running the "web app" with Electron or nw.js

If it ever gets good enough that I can't immediately tell when using it, I'll probably have to change my opinion.

When developing in a higher level language like JavaScript you are less prone to buffer overflow code execution vulnerabilities, witch seems to be the most common security hole.

That's a non-point. There's nothing intrinsic about higher level language that prevents security holes. There are plenty of low-level languages that are immune to buffer overflows—Ada, Rust, D† (to an extent), Oberon†, Cyclone....

D and Ada have real and important software written in them, Rust has hype, Oberon is still actively developed, Cyclone influenced new languages (particularly Rust).

† Garbage collected by default

These days, it seems like XSS/CSRF are just as common.

There are plenty of options beyond C/C++ and JavaScript.

Sublime with MarkdownEditing is what I use. Does everything I need.

While I personally use emacs (spacemacs) now, but ReText is pretty decent editor for Linux.

It's available in ubuntu repos.

What does this have to do with Electron or desktop applications? It's a web site.

> I don't have any recommendations for Linux, unfortunately.

For Linux and any other platform. Emacs' markdown-mode (including its GitHub-flavored gfm-mode) works very well.

> "secure" - what do you mean, it's a text editor, isn't it?

One of its features is that you can easily share your document with someone else across the internet with transparent encryption built in, so that the owner of the server and those on the network route never see the document.

Most other text editors don't have that feature, without combining them with other programs and services. They certainly don't make it as easy to do.

It also isn't secure as a few of us have noted, since it suffers from a Cross-site Scripting (XSS) vulnerability: https://github.com/TailorDev/monod/issues/122

See my other comment about MacDown having 100% CPU issues, it's a relatively known issue with that app.