Aw...this makes me so sad.

I need to fix my brain. Every time I see "static sites", I think "oh great, no dynamic server or client code, just static HTML/CSS for fast loading".

If I'm going to have to undergo a "compile step" for my website, it's going to do something worthwhile, darn it.

I keep waiting for someone to write a program that consumes as input Markdown text and emits as output a pure HTML/CSS site literally like this http://bettermotherfuckingwebsite.com/ except with the text from the Markdown file instead of swear words. Maybe it could even accept several Markdown files and make them into blog posts or something.

If nobody else does I guess eventually I'll get fed up and build it myself :\

Plenty of static site generators, as they're called, exist to do this. Good jumping-off points would be investigating Jekyll (written in Ruby) and Hugo (written in Golang).

https://github.com/jekyll/jekyll

https://github.com/spf13/hugo

Yup but they're bloated.

I agree. In Hugo's case there wasn't even a way to generate a completely static website for the longest time (i.e. not a blog or anything like that) and I'm not even sure they've fixed it yet.

I've used Pandoc.

You can generate a HTML fragment, or an HTML file, or HTML with table of contents, CSS, and footer, etc. http://pandoc.org/demos.html

It has some pretty heavy dependencies, but so far I haven't found anything better for generating a true static site from Markdown. I probably haven't looked hard enough either.

The only thing more fragile and hard to setup than a static site generator is probably pandoc. All of these are terrible Yak Shaving opportunities. Yet, I still do it.

The Pandoc site appears to provide binary downloads for the major platforms. Myself, I just always do `apt install pandoc`.

Pandoc is written in Haskell, but when built it's just a regular binary.

+1 for Pandoc

I use it a lot, I've collected of quite large collection of long form articles/"opinion pieces"/etc from websites and used pandoc to translate them into epub. (after manually pruning some html)

Instead of HTML/CSS why not parse markdown to a something even more direct like terminal output. My biddle application does this. Try it out let me know what you thing. Here are some commands to get started:

  git clone git@github.com:prettydiff/biddle.git
  cd biddle
  node biddle    (parses the readme.md file to the terminal)

  node biddle get http://example.com/document.md
  node biddle markdown downloads/document.md

  node biddle markdown downloads/document.md 60 (word wrap at 60 character width)

Link to biddle!

Pandoc does this. However I've found that you really quickly run into limits. I prefer a slightly-more-elaborate-but-still-no-database solution like Kirby. Throw it onto any budget web hoster with php enabled and you get easy Markdown-based content management, but still separation of content and templates, plugins for a contact form or picture gallery etc.

I found something exactly like it: https://github.com/alexanderteinum/simple-website/

Example: https://alexanderteinum.github.io/

Lately I was searching for static site generator that would require no configuration. It is written in single file of straightforward go. It gives you just two sections: posts and pages.

This is pretty much what I have in mind. Awesome :)

Org-mode can do everything you're describing.

Here you go. I use this to create my personal website. https://github.com/dirkk0/microCMS

If you don't want anything complicated you could actually use Pandoc to generate the HTML for you. Then you could either insert the resulting HTML into a layout template yourself or have Pandoc do it (by creating a template for Pandoc).

EDIT: Oops, Pandoc was already mentioned. I should have refreshed the site.

I totally agree. Make it worth the extra layers of junk.

There is server side templating and asynchronously loaded js. Just because it loads quickly and efficiently and without massive js bloat does not mean it isn't useful or dynamic

Set of Markdown files -> set of HTML files just seems so obvious of an approach, I don't see the advantage of anything else.

yep, i completely agree. The only reason it's JS heavy is because it's a MVP. If this project turns out well it will end up being a simple HTML with bare-minimum javascript.

Thank you for this, kristerv.

At first I agreed with many of the other posters, that this just had more overhead than it needed, so I didn't take it seriously.

But when I saw this comment, I got it.

It's an MVP! You launched it before it was ready, but not before you were ready. Which is exactly what we're supposed to do. Grow a thick skin, share it, and take your lumps. This way, your baby will grow up much faster than it would have it you went it alone.

Many of us here, including myself, are too chicken to do that as early as we should. Thank you for showing the way.

Respect.

thank you :)

... the only reason it's complex is that you didn't have time to do something simple?

I think the quote "If I had more time I would have written a shorter letter" applies.

haha, best quote i've heard in a long time :D

Even though the site is simple development time has been severely dropped thanks to choosing a fairly heavy platform.

> Even though the site is simple development time has been severely dropped thanks to choosing a fairly heavy platform.

I don't think it is because the platform is "heavy" (I assume in productive features) but rather it is what you are probably most recently familiar with.

For example I have built similar CMS tools for internal documentation with Java + Postgres (markdown and mustache.java) in less than a day. The development time was quick because I know Java and SQL... and basic HTML + request response handling.

The fact is it is even easier to pump this stuff out if you don't do Javascript heavy stuff because you can use so many different languages for basic HTTP + HTML + storage. Hell you might even be able to have a RDBMS (like postgres) with a couple plugins itself power the whole thing.

you are certainly right about the familiarity. Also some of the ideas proposed here have been very valuable, i'll be sure to check them out.

The development time has been severely increased thanks to a poorly choosen and heavy platform.

A Minimum Viable Product could be done in a few minutes with pandoc, a popular and standard tool that supports markdown to html conversation out of the box.

Add a few CSS styles and here you go! Awesome looking static pages, with 0 javascript whatsoever, based on proven battle-tested software ;)

Like any MVP, time to market almost solely depends on your knowledge of the tooling. If the OP is familiar with what they've used, then I'm comfortable trusting that it's faster for them instead of having to learn something new.

  apt-get install pandoc
  # convert from markdown to html
  pandoc -f markdown -t html article.md

Just to be clear. Pandoc is a rather trivial command line tool. It's not comparable to learning a framework or a toolset.

But that's exactly my point. The presumption is that he didn't learn a new framework or toolset - he already knew it.

There's also a nice API solution for Pandoc -> html/epub/etc conversion: http://www.docverter.com

nice. thanks for the tip. I'll see how plausible this is for my usecase.

totally right here.

Or just use jekyll. But it seems to purport to be different from jekyll, so I am not sure.

perhaps I didn't understand what jekyll was capable of. I'm going to have a proper look at all the tech suggested here.

I really like your attitude in these comments. Rather than get defensive, you seem to be open to suggestion and not afraid to admit that there may be a better way to do things and that you still have things to learn.

I've learned a great deal reading these comments, so thank you for posting your project.

How is it easier to go in this direction?

I think it's completely fine to use JavaScript here. It would be nice to have instant page pushes.

But it should be rendering the site without a loading indicator. There's no reason that should be displayed

> I think it's completely fine to use JavaScript here. It would be nice to have instant page pushes.

I'm not sure I follow on the instant page pushes. Are you talking about a little dialog that pops up and "says a new version of the page" kind of thing?

Second is there features you saw that required Javascript (as it appeared to me most could be done with CSS)?

And no I don't think it is "completely fine" to use JavaScript particularly if you are trying to spread the word as quickly as possible and don't care about looks (ie most devices, loads fast, low power). There are also a growing amount of people that have Javascript disabled in general.

One solution is to just send all the linked pages on first load (all the markdown content, so when transitioning they only load images, or of seen before get them "from cache").

Typically this behaviour, page prefetch, is built into a modern browser. Thus, writing it yourself is probably not a great improvement.

Really?! I need to upgrade my browser. :)

What is a page push?

I think in this case "page push" means that changes get sent automatically to the client via javascript (as opposed to "pulling" changes by pressing refresh.

Completely useless for static sites, but nice to have while authoring.