diff options
Diffstat (limited to 'markdown_is_bad_for_you.html')
| -rw-r--r-- | markdown_is_bad_for_you.html | 80 |
1 files changed, 80 insertions, 0 deletions
diff --git a/markdown_is_bad_for_you.html b/markdown_is_bad_for_you.html new file mode 100644 index 0000000..00e40bd --- /dev/null +++ b/markdown_is_bad_for_you.html @@ -0,0 +1,80 @@ +<!doctype html> +<html lang="en"> +<meta charset="utf-8"> +<meta name="viewport" content="width=device-width, initial-scale=1"> +<meta name="author" content="aki"> +<meta name="tags" content="rant, markdown, web, html"> +<link rel="icon" type="image/png" href="cylo.png"> +<link rel="stylesheet" type="text/css" href="style.css"> + +<title>Markdown Is Bad For You</title> + +<nav><p><a href="https://ignore.pl">ignore.pl</a></p></nav> + +<article> +<h1>Markdown Is Bad For You</h1> +<p class="subtitle">Published on 2020-05-13 17:32:00+02:00 +<p>Markdown is a markup language. It wouldn't be misleading to say it's also a family of markup languages that are +derived from the syntax created by <a href="https://daringfireball.net/">John Gruber</a> et alii. Gruber's creation was +inspired from other markup languages but, as author notes, it mostly follows the convention used in plain-text e-mails. +It is usually introduced as <q cite="https://daringfireball.net/projects/">text-to-HTML formatting syntax</q>, +<q cite="https://wikipedia.org/wiki/Markdown">language with plain-text-formatting syntax</q> or +<q cite="https://daringfireball.net/projects/markdown/syntax#html">easy to read, write, and edit prose. (...) Markdown +is a <em>writing</em> format</q>. +<p>Now that we are on the same page with Markdown, let's make the rant case clear. We're considering creation of +either, a static website or an application providing dynamic set of pages. To be more exact let's say we are preparing +to publish this very article. Remember, we are keeping in mind just one principle: minimalism. I'll not define it, so +I can have some more freedom in what I say. This also gives you more opportunities to complain about me. That makes us +even. +<p>We have plenty of information and a goal: make a simple blog. Those of us who are the best buddies with the Markdown +would be happy to just jump into it and get some static site generator or some dynamic blog engine up and running. +Others, who are not yet that used to it, are most likely tempted by the convenient prospect offered by MD. And, of +course, there is the last group, who read the title and is impatiently waiting for me to finally explain my point of +view instead of continuing this foreplay. Ok, ok, ok. The first sin has already been written down. +<p>If you want to serve a website you need some kind of an HTTP server. Be it nginx, apache or something else. +Surprisingly, it is all you need to serve static content. On the other hand, if you want show Markdown that way, +firstly you need to generate HTML out of it. It's only natural, this format has been created exactly for that. This +means you will end up needing an entire new piece of software. Markdown-to-HTML generator. It goes the same way for the +dynamic blog. The only difference is that instead of some standalone program you will need to integrate a generator +with a parser, and possibly some additional HTML template engine to embed the results nicely. The usage of markdown +always comes with a cost in a form of an additional entity in the architecture or workflow. You can automate it, but it +is always there, and should be acknowledged before you can decide to ignore it.</p> +<img src="markdown_is_bad_for_you-1.png" alt="One new format and one component needed in the flow"> +<p>Previous point implies an additional sin. Markdown not only requires to add more stuff to your existing setup, but +it also at some point stops being Markdown, and starts being HTML. And like I've already said: it's only natural, +because it was designed this particular way. Not only it wants to become HTML, it also allows user to inline HTML. It +means that the design is not minimal in its core. This is because the purpose was to create a syntax to simplify +writing for the web. It never tried to replace anything, and that's probably the worst sin of all. Thanks to Markdown, +you will always have HTML <strong>and</strong> something else. If you are going for minimalism you shouldn't want that +additional thing at all. +<p>Markdown with it's limited syntax encourages users to inline HTML if it's impossible for them to accomplish their +goal in just MD. For that reason people who didn't want to use HTML started to extend the syntax. It resulted in spawn +of a lot of offshoot syntaxes. Discussion of how fragmented ecosystem with a whole lot of plugins to a single component +is unhealthy in a long run is way out of the scope of this article. In short: you will not only need something to +process the basic syntax, but you will also require a possibly great amount of plugins to handle the extended one. That +makes even more components you need to integrate into your software. +<p>These points considered only the problem of increased resources, components or steps in processes or flows. Once you +start using Markdown it may start tempting you to avoid using HTML at all. I've already mentioned the plugin madness, +it may lead to. But that's not all there is. Avoiding the HTML in context of the web is plain stupid. Reason is, +<a href="https://www.petelambert.com/journal/html-is-the-web/">HTML is the Web</a>. Honestly, this one sentence could +summarize all of the previous paragraphs. +<p>Sadly, HTML has its own problems. The whole family, together with XML has been widely criticized for various +reasons. There is very few people who would try to argue that they are minimal. I won't, because I think they are not. +Adding one more layer of syntax on top of that won't solve the issue. It will only make it worse. HTML5 tries to +accomplish commendable goals and one could use it to create a rather minimal web pages. On how to write somehow minimal +HTML5, make it readable in plain-text, properly mark content within it, extend it to your needs and break the +specification in unimaginable ways... Let's leave it as a topic for another day. Or even more than one. +<p>In a very roundabout way we can take one more thing out of the Markdown. Perhaps HTML shouldn't be the web? Why are +we building everything on top of a single stack. It's convenient, yes. However, won't it crash if we try to reach too +far? What if we try yo break the concept of the browsers as they are now and make it more modular? Leave the HTTP, but +allow more freedom in how the content is served to the user. +<p>All in all, I've fooled you from the very beginning. Markdown isn't actually bad for you. It really shines as a +syntax to describe comments, short plain-text documents or messages like e-mails. As long as it is used as a +replacement, it's nice and easy to use. It provides a great way for external users to post their content on your +platform in a quite safe way with only minimal restrictions. However, the moment you use it as a HTML extension, or as +an intermediate format to generate whole HTML pages. It crumbles. It starts to build up on top of your stack, throwing +at it more and more inline HTML and layers of layers of plugins. Keep it simple. +</p> +<img src="markdown_is_bad_for_you-2.png" alt="It may collapse any time now"> +</article> +<script src="https://stats.ignore.pl/track.js"></script> |