I'm not sure if this counts as a "static website", since the page is not delivered exactly as stored. It requires JavaScript to actually renders the page, which seems like an overkill.

That's just client side templating. Which has the same problem they all do of being greeted with a white page until ALL the content is ready.

If someone is prepared to accept this it's not that hard to accept generating the html page yourself and uploading that.

> That's just client side templating. Which has the same problem they all do of being greeted with a white page until ALL the content is ready.

Or being greeted with a white page period if you're using a non-JS enabled HTML client (noscript, CLI browser).

In this particular case, wouldn't they see the plain text markdown? (which in many case is just as good the html)

Kinda, it looks like they add a bit of CSS (basically make everything monospaced & pre) so the Markdown text is visible when JS is disabled (noscript), but in a CSS-less browser (e.g. links) the file is received as HTML, and the Markdown code is directly interpreted as HTML, which makes for an unreadable mess (the whole thing is a single "line" with newlines collapsed to spaces)

You're really better off using a static conversion tool, or using markdeep as a static conversion tool (with ?export)

It's 2016, if you use a non-JS enabled HTML client you better be used to the breakage.

Sure I'm used to closing the page, because really screw you if you can't display half a dozen paragraphs of text without JS.

Well, most of those websites would rather say:

Don't let the door hit you on your way out

Than spend time catering to outliers...

I fully agree. Why render it in every client when you can do it only once on the server? This feels like a waste of CPU resources.

compared to all the other things your cpu is doing, and all the time your cpu sits there doing nothing, the "waste" in this case pales to total unimportance. you've got a supercomputer; you might as well use it.

An idle core will definitely use less power than one constantly processing. That is what drains the battery in your laptop. I'd rather not spend my battery power if it can be done on the server instead.

Thanks. That's a nice idea... but if it's that simple I might as well just use a static markdown to html converter, if I don't need the support for diagram generation (which admittedly looks like a killer feature). For example, pandoc supports that (or latex -> html or pretty much anything else), and the results are similar, e.g. (in this case, specifying a very small amount of additional css): http://pandoc.org/demo/example3.html

I'm currently using couscous (http://couscous.io/) to convert markdown to html but it's far more work to use, and does a whole bunch more than that, such as twig templates, so I'll consider switching to markdeep or pandoc.

Since the website is rendered with JS onload, doesn't this make your site a second class citizen in regards to SEO? If you want people to actually read what you write, static content from the server is still superior.

> doesn't this make your site a second class citizen in regards to SEO

Not with any search engine that matters.

That's impressive! It even has math support! I do wonder about generating the diagrams at every page load. Seems like markdeep might as well have been a static generator?

Yeah, but you can easily copy-paste the generated html into a file. Just append '?export' to the URL. I definitely would use it in that way.