4 ms·
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
by limmeau 16y ago
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.
- mikepurvis 16y agoI'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. Here's an example: http://8cities.org/newyork http://8cities.org/newyork 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 http://8cities.org/content/newyork-left.txt and http://8cities.org/content/newyork-right.txt 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.
- eoghan 16y agoWhat about just using HTML?
- limmeau 16y agoEasier to mess up the syntax when no specialized HTML editor is available (e.g. when editing your Dropbox site through your phone).
- mckoss 16y agoI've posted my demo of something similar about a month back. http://wiki.pageforest.com/#mckoss-3535 http://wiki.pageforest.com/#mckoss-3535
- burgerbrain 16y agoSo 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?
- mitjak 16y agoYou 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.
- burgerbrain 16y agoIt'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.
- limmeau 16y agoI 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.
- burgerbrain 16y ago1) It's the principle of the matter. 2) That it might be even comparable to those things is a pretty strong argument against it, afaic.