Is there a list of static site generators that strictly support CommonMark?
There is a list of editors,
https://github.com/commonmark/commonmark-spec/wiki/Applications-supporting-CommonMark
but what about publishing on the Internet?
1 Like
Assuming your static site generator supports third party libraries, you should be able to use any of these implementations that share your static site generator’s language:
https://github.com/commonmark/commonmark-spec/wiki/List-of-CommonMark-Implementations
You don’t understand me. I don’t have my own generator. I’m looking for a generator.
Or do you mean that I should look for a generator that is built on an implementation from this list?
He means that if a generator supports pluggable markdown renderers, then you can choose any from that list that’s written in the same programming language (e.g. Python or Javascript).
I don’t think it’s that simple though. I’m pretty sure many if not most static site generators layer some additional functionality over Markdown, and thus require a bit of integration code to work with any particular Markdown library. That’s why, for example, Jekyll supports four out of the box: Kramdown, RedCarpet, CommonMark and GFM (which is a CommonMark superset). Someone had to code those integrations. You’d have to write some code or find someone else’s to use any other Markdown library.
I agree, it would be worth adding a list of known SSGs that support CommonMark. I know Jekyll and Hugo do (Hugo recently via addition of GoldMark as a Markdown renderer).
1 Like
Ok, i just added a section with the two that I mentioned. If you, @anon62197958, or anyone else come across or know of any others, please add to the list.
1 Like
If you don’t have a generator yet, I would first question why you need CommonMark straight away. If it’s just a blog, you could probably go with whatever default Markdown renderer it comes with and it will likely be mostly compatible with CommonMark if ever you need to move the content. As @vas said, you can look at writing a CommonMark integration or using an existing one, but is that a valuable use of your time compared to going with whatever the main static site generators come with by default?
1 Like
Not everyone understands the technical details, so it is important for such people to have a list of tools for creating their environment and to write text, rather than integration or programming. In addition, the list of tools will save you a lot of time searching for them and selecting them, because you do not need to understand low-level details, but immediately pay attention to the General features of the tools.
I am thinking of a future where it will be easy to change something without going into technical details, so there is nothing in my workflow that is not a specification-based standard. If there is no such standard, I create it myself, but all my workflow must be documented to protect against inconsistent steps and banal forgetfulness. That’s where the real time savings will be, which will infinitely cover the losses at the beginning of the way when organizing the workflow.
If this is the case for you, maybe start with Jekyll since it’s well documented and has a big community around it for support? Here’s a page which shows how to integrate CommonMark or GitHub Flavoured Markdown (a spec built on top of CommonMark):
Thanks, I’m thinking about Jekyll, but I want to get a little familiar with the entire ecosystem of generators first.
The main indicators for me are CommonMark support out of the box by default and confidence in the existence of static site generator project in the future.
The ideal static site generator for me on Windows is cmssg.exe (commonmarkstaticsitegenerator.exe) with full control from command line. Themes in the same folder as cmssg.exe and only the site structure and settings in _cmssg_setup file in project folder with md -files.
But this does not exist …
actually it’s called Hugo. It’s the only SSG I know of that is delivered as a single executable. It’s lightning fast. And has lots of features.
The caveats are its complex, inconsistent, non-intuitive behavior (and a developer that doesn’t prioritize the opposite). You have to embed its proprietary “shortcodes” in your Markdown to do advanced things, but part of the reason for that is Markdown has no standard extensibility mechanism.
I’m actually working on the latter problem right now. After I get that out in the wild I’ll resume my earlier project, which you might also be interested in, TextAssembly (previously known as Markaround). There’s nothing there now except the readme and the manifesto. I actually had a working version of it implemented as a fork of Hugo, but I abandoned it because I lost faith in the Hugo team’s philosophy (see above) and decided to start over from scratch.
Still, Hugo might be exactly what you need.
1 Like
Yes, the reason for the complexity of the choice is mainly that developers think about themselves, not about the authors. Therefore, all these tools almost never go beyond the developer communities and do not come to the author communities, where it is easier to install WordPress, and not to study templates and install interpreters (for example Ruby for Jekyll).
If you want to organize this into a standard, then this is good. But, probably, in this case, it will be more correct to use the name CommonMark, rather than Markdown.
I’d add, personally I admit as the main implementation of CommonMark through cmark, because in any case, everything is based on the operating system (or computer or server), and operating system is based on the immortal C. When I saw cmark, I realized that it was serious, people deeply see the issue and on this standard you can base your workflow.
I think that this list Static Site Generators should only include those generators that are CommonMark adherents out of the box. Otherwise, we can add almost everyone to this list. I am sure that the restrictions should be extremely strict, then this will be a real list from the standard, and not a simple listing as in blog reviews.
Now you’re thinking like a developer and not an author!
Non-techie authors don’t care that much about Markdown vs CommonMark… What would serve them far better is a plain text standard that wasn’t like a programming language, which I’ll contend Markdown/CommonMark still is, albeit a couple of orders of magnitude better than HTML. CommonMark can’t escape this shortcoming because its first mission is to be as backward compatible with Markdown as possible, with a few exceptions where it corrects gross flaws.
Non-techie authors certainly don’t care whether it’s written in C vs Javascript… though I’d argue that (pre-WASM) Javascript is the better choice as it works in a browser, or even that Swift/Kotlin is better because it works on their phone natively. Hugo is written in Go, which compiles just as well as C down to a native stand-alone executable, so again, C isn’t important.
by that standard the best implementation would be written in assembly or machine code!
My understanding is that Markdown was originally created after analysis of a large amount of plain text, to see how people naturally formatted it. I’m not sure what methodology or reduced feature set would be less like a programming language.
1 Like
Brian, I’m working on it! I’ll try and remember to tag you when I have something to show 
2 Likes
Neuron is not exactly a static site generator, but it is effectively one - but more specialized to note-taking and publishing them (as a website) on the internet.
This GitHub template will get you going to the point of publishing on the internet within a minute:
My own personal website is published in this manner, so you can take a look what the result would look like:
PS: neuron uses @jgm’s excellent commonmark-hs pure Haskell parser.
1 Like