Zato VS ruby-slim

Yes, the article is correct, there is a market for Markdown sites and related products.

Our Zato website is in Markdown: https://zato.io

We have a purpose-built static site generator, which makes sense in our case because:

* The resulting site is very fast, seeing as there is no need for runtime generation of any assets / HTML / any kind of resources

* It is easier for developers to work on documentation because they already know Markdown

* It is easy to statically apply filters such as spell checkers for multiple languages during the build

* Various optimizations can be applied, e.g. incremental builds or on-demand builds

The drawbacks are:

* Non-technical translators may have a difficult time working with anything but either their own specialized tools or MS Word and they consider Markdown to be "advanced"

* Sometimes you work with writers who are not technical at all and who will not understand what a build system is even if they are open to the idea of learning Markdown itself

Thus, there is a market for a lightweight CMS that would enable non-technical people to author Markdown in their browsers, without a need for any command line usage.

I like Markdown and use it at work, but I think Asciidoc is a better markup language because it is more consistent and has support for more things than Markdown does (e.g., better table support, callouts, tips, etc.).

I currently use 11ty with the Asciidoc plugin for building websites. This setup is nice because I only have to fiddle with HTML and CSS during the design phase. Once that's done, nearly all my website maintenance is done in Asciidoc. Easy!

I don't think I'd want to directly write an entire website in either Markdown or Asciidoc. I think, eventually, doing so would result in these markup languages becoming as cluttered and weird as the HTML/DOM/JavaScript/CSS mess is now.

I think a better step to improving HTML and CSS would be to have the browsers support Slim (https://github.com/deepin-community/ruby-slim) and Sass out of the box instead. That would make my design phase less wordy and redundant while keeping my Asciidoc experience nice and tidy.