3 ms·
> All of these languages are seriously flawed half-baked solutions to a problem that's already been solved. I tend to think so aswell but there is a big except
by taink 4y ago
> All of these languages are seriously flawed half-baked solutions to a problem that's already been solved.
I tend to think so aswell but there is a big exception: code highlighting. Having a no-js solution to code highlighting implies having a build step to handle just that (unless you actually do it yourself while writing the docs, which would be insane). I haven't spent a lot of time researching it, but I have yet to find a tool as simple to use as e.g. Pygments or Chroma (with Sphinx and Hugo, respectively). What would you recommend?
- russellbeattie 4y agoJust treat HTML like any other markup text. Markdown doesn't concern itself with images, CSS or syntax highlighting either, why does HTML have to? Since Markdown requires a build step, there's no reason to dismiss the idea for HTML. The big difference is that HTML is simply more flexible. In both cases you need to add some sort of markup to identify the code, right? In HTML it looks like: <code class="js-syntax"> let a = "foo"; </code> And Markdown looks like: ```js let a = "foo"; ``` But in HTML, you have a bunch of options built into the file itself: A WYSIWYG editor could add the syntax highlighting before saving, a build step could add in the appropriate styles before publishing, or a JS script could be added to the page and the browser could deal with it. A Markdown file only has one option: Here's your blob of code in plain text, go find some library to convert it. HTML is just a text document that happens to have had 30 years of work put into its spec and millions of man-hours put into optimizing its Object Model and parsing engine. It can be as simple as bog-standard Markdown output, or contain all the meta data needed without relying on custom tags and other hacks.