Can you scroll to the bottom of that page and use the "Report a problem with this content on GitHub" link?
The raw content is not Markdown. It's HTML with some macros (called kumascript macros).
And yes, you can "host MDN locally" now. Before you had to write a web scraper, now you can just iterate over the files after a `git clone`. But you might need Yari to build the raw HTML to fully formed HTML that you can open in your browser.
It's not that easy. We have 60+k pages carried over from 15 years of organic evolution. It's unstructured and messy.
A move away from HTML to something "more popular syntax" (like Markdown) is NOT easy.
This is just the beginning. Finally we can do the kind of web performance improvements we couldn't do on the old platform. But to boot, we gained 10-20% on the First Render metrics.
And because of the whole new way we deploy, we went from a 27% hit ratio (of popular pages) to 96% in the CDN. That means ~70% of the time you gain about 300-500ms on the initial load.
And besides, before, cold cache misses in the CDN would result in a backend server rendering whereas now a cold cache miss just means an S3 lookup.
PostgresSQL is better. We're all aware of that. But it's miniscule in importance. Especially if you use the ORMs and other decent tooling. The move to git isn't MySQL's fault. It's so more and bigger than that.
1. That's right! But it's not really on the roadmaps either. One can hope that someone in the community writes a fancy web app wrapper for GitHub's API or something.
2. Yeah, it's really really convenient to submit a quick PR entirely in the GitHub Web UI. But I admit, we have some work to do make the previewing experience a bit better.
What's cool about git as a persistent storage, is that you can use vscode, emacs, vim, or notepad. Or you can write a little web app that starts a WYSIWYG editor on localhost:8888 or Heroku and have it dump to the file system and then you just need to write a script that takes care of submitting the PR from there.
What I'm getting at is that we're misconstruing a storage system (git), with a user-friendly interface. Ideally we get the ubiquity and interoperability of git with a WYSIWYG editor. A website that lets you edit files in the browser and is backed by a git repo could be helpful. But maybe in edge cases, it'd still be too complex. Using git here seems like overkill.
This, plus there are many server-side WYSIWYG markdown editors that make it transparent to the end user that they are even using Markdown. This is really the future IMO, you get the best of both worlds. Hopefully they'll add some extensions though to Markdown. I hope the community will create even more as well.
Also, keep in mind all the tooling GitHub offers. Comments with reactions, quoting, permalinks, blocking, etc.
Yes, it can be built in-house but would cost a fortune.
The raw content is not Markdown. It's HTML with some macros (called kumascript macros).
And yes, you can "host MDN locally" now. Before you had to write a web scraper, now you can just iterate over the files after a `git clone`. But you might need Yari to build the raw HTML to fully formed HTML that you can open in your browser.