This service apparently runs a Markdown-to-HTML converter on your Dropbox subdirectory whenever you change a Markdown file.
What about client-side rendering of Markdown? You'd have an HTML file which includes a separate Markdown-to-HTML converting JavaScript, and an invisible pre containing the markdown. That HTML file, consisting mostly of Markdown text, can then be edited in a simple text editor.
I've taken to doing basically this with PHP for static websites. A lot of websites I work on are really just a handful of static pages--- needing logins and a database and a "theme" and to fret about security patches just for that is like swatting a fly with a bazooka.
It's a supporting site for a marriage seminar being put on by a local church---the content on that page is being sourced from http://8cities.org/content/newyork-left.txt and http://8cities.org/content/newyork-right.txt , so it's easy for the staff to make changes to the files without needing a ton of technical know-how, but there's less overhead than with a whole CMS.
Another way to do it that I've found works well is to have a php file with a little <?php ?> block at the top where you set template parameters, etc, and then have the markdown content following in chunks separated by a marker (like #######). Then you include the file in your processing code, use PHP's output buffering to capture the content, split it into chunks, and run markdown and smartypants on it. Then you have HTML blocks in $content[0], $content[1], etc, which can be included into the template PHP file.
An approach like this would work really well with a Dropbox backend.
So instead of rendering the markdown to html once on your computer, you're going to do it every single time on your users' computers? What possible benefit could there be for this, besides unnecessarily burning peoples CPUs?
You don't need to regenerate any HTML and changes are instant. Also, I honestly don't think one can burn through too much CPU with occasional JavaScript. This is some hardcore environmentalism.
It's not environmentalism, it's just common sense politeness. There is no reason a users web-browser should have to render something twice just for static content. All just to save you a single `make` before uploading.
I've been joking for a few years that it's only a matter of time until some joker implements a browser in javascript/html5 and the rest of the web development community enthusiastically adopts using it as standard practice. I'm starting to fear that this is more of a possibility than I initially thought.
I doubt that translating a few hundred lines of Markdown into HTML with an efficient JavaScript JIT is noticeably more expensive than, say, decoding a big JPEG picture or displaying a Flash ad, or having menu items slide in and out.
What about client-side rendering of Markdown? You'd have an HTML file which includes a separate Markdown-to-HTML converting JavaScript, and an invisible pre containing the markdown. That HTML file, consisting mostly of Markdown text, can then be edited in a simple text editor.