> You can include arbitrary HTML tags in Markdown at any place you need them.
That is well known and I am sure the author is aware of it. The problem they are describing is not whether HTML is technically allowed inside Markdown. It's that when you are writing Markdown, you are writing Markdown, not HTML, and that comes with some problems.
> It is perfectly capable of what the author claims it isn't.
In theory, yes. In practice, using Markdown becomes much less appealing once you start dropping raw HTML all over the place. The whole point of choosing Markdown is that you do not want to spend your time typing <p>, <a>, <li> and the rest. You want to write in Markdown, with only occasional HTML when absolutely necessary.
That is exactly where the author's complaints become relevant. If the solution to Markdown's limitations is routinely switching to HTML, then the argument becomes circular. If you are expected to write HTML to address the author's complaints, why bother with Markdown at all? If the answer is just "write HTML", then you may as well skip Markdown in the first place.
> The whole point of choosing Markdown is that you do not want to spend your time typing <p>, <a>, <li> and the rest. You want to write in Markdown, with only occasional HTML when absolutely necessary.
Why is that a problem?
> If the solution to Markdown's limitations is routinely switching to HTML, then...
Why would you do that, instead of only switching if you had to?
Why would the alternative be "just HTML" and write all the nonsense you said one doesn't have to?
Most markdown engines allow short tags to stand in for html, so for frequent features you can just use a short tag.
Alternatively you can extend markdown. I wrote a simple text based game engine that was markdown based but I needed some arbitrary additions appropriate for a game.. so I just added a few elements.
The author addresses this too. Once you start down this path, you go down the road of non-standardization which means losing portability, etc. I don’t see how this is a point against the author?
None of the author's other suggestions are portable either. So what if pandoc markdown is only understood by pandoc's tooling? DocBook is only understood by DocBook tooling. The difference is that pandoc markdown is already 95% similar to every other flavour of markdown, so migrating to a new system (if necessary) would be relatively simple. Also, the difference is that XML is a pain to write and I'm not sure semantic tags matter all that much.
Maybe portable isn’t the right word. I read portable as meaning the format’s semantics are consistent across platforms. The way I read the author’s complaint was that once you start tacking on extensions to markdown, you run into the problem of seeing if other markdown platforms being able to support your variant of markdown. Hence the part about CommonMark vs GitHub-Flavored Markdown vs etc. Having actually run into this before when working on CMSes in the past, I get why the author sees this as a problem. I don’t think everyone will agree with the authors viewpoint, but I just happened to think that this thread is completely missing the point that the author is trying to make.
> I read portable as meaning the format’s semantics are consistent across platforms.
By that definition, a format which is only implemented on one platform is 100% consistent. I agree Markdown is uniquely fragmented, but it's also uniquely widespread.
Markdown is an extensible core for writing platform-specific languages. I think comparing markdown in general to something like DocBook is comparing apples to oranges. Instead compare (e.g.) Pandoc's specific markdown variant to DocBook.
> I think comparing markdown in general to something like DocBook is comparing apples to oranges.
Hmm let me rephrase the issue I have with the comments in this thread. If your position is that markdown doesn’t belong in the same category as the others, then yeah, I agree. But I also think that’s basically rejecting the premise of the article and there isn’t a discussion to be had. If you disagree with the core premise, then it doesn’t matter what is said, there’s no discussion to be had.
However, the original parent comment is stating that the author’s assertion is false because you can extend markdown. I don’t see how that logic doesn’t run into the semantics and “portability” problems that the author is writing about.
I think you can have the discussion, but you also have to be careful about how you have it. Markdown is a family of languages; if you want to evaluate markdown against something like asciidoc for a particular use case, you have to pick the members of the markdown family which are best-suited for that use case and evaluate those flavours individually.
Take the comparison between markdown and asciidoc. You can't say, "asciidoc has semantic structure and markdown doesn't," because pandoc markdown does have semantic structure. If you need semantics, you can use pandoc markdown, which is a very fully-featured language that suffers from none of the issues the author points out. Yes, other flavours of markdown exist too, but so what? This one has great tooling and suits your needs.
Of course, you can't use pandoc in (e.g.) Reddit comments. But you also don't really need semantic markup in Reddit comments. It's a different flavour of markdown in a different application that is solving a different problem. Or consider MDX: Yes, `Command` is a react component, but maybe it needs to be a react component. Maybe it has a "run this command" button, or it generates an interactive graph of some sort. If you mark that up in asciidoc, you need a whole separate system to attach your components to your markup. That's just using the wrong tool for the job.
There are real limitations to this: You can't arbitrarily mix and match HTML and Markdown. As soon as you introduce an HTML block, you're locked out of Markdown syntax.
AsciiDoc lets you mix and match however you want. Or, put differently: AsciiDoc's superiority over Markdown extends even to being better at shelling out to HTML.
While that's true, I'd take Markdown + extensions to allow inline HTML or custom tags over AsciiDoc any day, even at the cost of losing some compatibility - converting that to plain Markdown is usually easy enough.
Not op, but markdown is much more likely to render well in different contexts, without post processing. My editor understands markdown, GitHub understands markdown, the link preview renderer in <random collaborative tool> understands markdown. It’s the lowest common denominator
That's true, and it's why we're all using it. But those different renderers all support different ill-defined interpretations of Markdown. You can forget about all of them accepting raw HTML.
It has sufficient differences to what is already accepted "everywhere" that I would have think about syntax more often than I'd like. That is enough. The minor inconveniences of Markdown incompatibilities are smaller than the inconveniece of AsciiDoc. It simply doesn't offer nearly enough potential advantages to be worth the hassle.
I often use <img> with "width" on GitHub, so that I do not have the scrollbars on the main page, and one can click on the image to see the original size. It is ugly, but what is the alternative in Markdown? Several images instead of one?
I also used pandoc and markdown, and never bothered going back to ascidoc, full HTML, or latex.
Footnotes are the only not always included extension to mmarkdown I need for slides or argument flows that are not killed by sidenotes, and some sites and toolings support that in markdown.
Even table of contents is not a problem, so what else is left? Formula setting? Buttons for UI vs function? Buttons plus Inline JS for step by step state modification?
I am not programming, I want text and something to be easily pasted into Word-like rich text, which seems to be the default text editor for emails for 90% of the population.
I am unsure how this is supposed to work for CSS. To my knowledge, most CSS properties cannot be substituted for each other. If the subset to be enforced is "CSS properties already present", what is a developer supposed to do if their CSS property is not already present? Change the design?
Well, (like C++) new css attributes are constantly added. This means you constantly have to choose between the old way or the new way: either is fine, but “pick old or new at random on a per pull request basis” isn’t.
You seem to assume that old CSS properties can be substituted for new ones. But as I said, to my knowledge this isn’t possible in most cases. Can you give an example of two CSS properties where 'either is fine, but only one should be used'?
Or do you mean something else altogether by 'CSS attributes'?
One sits in my bathroom so I can browse random Wikipedia articles while I'm, uh, busy. The other one sits on my nightstand and plays audiobooks/podcasts when I'm going to sleep.
So nothing critical. But something they are still good at, and being very small makes them a natural fit for these use cases.
I can't speak for the other poster, but I like the idea a lot. Having tools with specific purposes means I can avoid using my phone for everything. No matter what games I play to remove notifications/interruptions/etc. it's always a distraction and easy to be distracted from whatever I originally intended to use the phone for.
I do use the phone for audible, but I started both uses before I had a smart phone (I was very late to the game), and I am a creature of habit. Plus the netbook has a bigger display, more storage, and a real keyboard (again, creature of habit).
I think since they used [todoId] in the example they mean a static page which does not exist at build time. Which both can do, it’s called ISG (or on-demand in the Astro docs), but it requires a server to work, or you can create a static route that accepts any parameters and pass those to JavaScript to run on the client.
I find it sad that Astro advertises itself this way, because I think that it is perfectly capable of building web projects of any complexity, simply by means of the component libraries you can plug in.
What makes it so great is not that it serves a particular niche (like "content-driven websites") but that it provides a developer experience that makes it incredibly easy to scale from a static website to something very complex and interaction-heavy without compromising UX.
Per default, Astro generates static pages. So it makes sense to compare it to an approach that doesn't.
Using a framework has upsides over writing static pages manually. Most notably, you can decompose your website into reusable components which makes your implementation more DRY. Also, you can fluently upgrade to a very interaction-heavy website without ever changing tech or architecture. But that's just what I value. I whole-heartedly recommend trying it out.
Production is more complicated than development. How would I express rolling updates or ingress with docker-compose?
Why not use Kubernetes for local dev (kind or minikube) instead of trying to make docker compose hacks for production?
Docker Swarm is rarely seen, I suspect industry has already settled on k8s as the standard
Working at a large scale I agree that using something like this doesn't make sense. But for indie hackers, small startups, or people wanting to deploy foss, they dont need all the complexities you are talking about. They have a app they want to deploy and generally, as cheap as possible.
You can run your Kube stack locally.. look into kind, minikube etc.. just exclude your LB configs and stuff from your helm charts and dial down the resourcing
So, no, Markdown is not holding me back. It is perfectly capable of what the author claims it isn't.
[0]: https://daringfireball.net/projects/markdown/syntax#html