While you see yourself as objecting to Markdown, I see you as objecting to other templating languages. For example, a PHP file can do what you are doing, but it will have the full feature set of PHP available and it doesn't necessarily have a great API for working with a DOM. You could say the same of something like Apache Velocity.

Of course, there are a lot of template languages out there: http://en.wikipedia.org/wiki/Comparison_of_web_template_engi... and I don't know how yours compares to the best of them, but the problem you're tackling is different from the problem that Markdown is tackling.

Let's not forget all the static site generators: http://staticsitegenerators.net/

The main strengths of Markdown are simplicity, readability, and standard feature set. Markdown is entirely usable without being transformed into HTML. Plus, the lack of extensibility means that services like GitHub can enable pretty views of Markdown documents without having to process costly and/or dangerous user-provided extensions. Once you introduce variables and calculations and lookups into a DOM, you largely lose all that and you have something entirely different.

The author's complaint that Markdown isn't expressive enough doesn't really make sense. Expressiveness is most valuable when you need to support a wide range of functionality. Writing a single page app with extensive javascript gymnastics, complex layout, etc, is where expressiveness is needed, and, not coincidentally, it's also not where Markdown is designed to be used. It's designed for documents which are embedded in web pages, like blog posts or comments or github READMEs, or whatever. In these cases you're only (typically) concerned about a very small subset of HTML -- the ability to italicize, bold, underline, insert code, etc. Markdown's raison d'être, and the source of its popularity, is that it provides these features with almost no effort, and often in the most intuitive way possible.

My objection to Markdown is that its just a proxy for something else and only fixes a very limited set of HTML issues. If you have to learn Markdown you may as well learn HTML. The security issues need to have pressure applied to the browsers to fix.

Markdown requires far less typing than HTML for common use cases.

    *This is italic.*
    <i>This is italic.</i>

or (semantic version):

    <em>This is italic.</em>

The second has three times the markup overhead as the first and the third has four times the markup overhead. That matters. If you're writing long-form text it matters a lot.

Paragraphs are even worse. In Markdown you just hit return. In HTML you have to write <p></p> or <p />. That really adds up for a long piece.

Learning HTML doesn't solve squat. The value of Markdown is that it's easy to edit with multiple tools and it's easy on the eyes whether you're looking at as plaintext or in a Markdown viewer.

Learning HTML doesn't help people who want to stay in the text editor.

I edit a webpage, its a modern page with php, JSON and jquery elements - but the large majority of it is in html, markdown does nothing for me, because I'd need to convert it anyhow back to HTML for the webserver.

Markdown however would be very useful in replacing the groff code used in man files for example, if perhaps it were a little more expressive - it has the advantage of being easy to parse when not render, and easy to build a renderer for.

The great thing about markdown is that it's basically readable as plain text.

So you get something that's easy to write, works with plain text formatting, and can be viewed with full HTML styling.

Strange that there isn't a comparison between Pollen and TeX/LateX in the documentation..