MDN is obviously an important reference. They've done a great job, because documenting the complex mess of modern web technologies is hard.
I have 2 small complaints:
- I sometimes read some dubious content on MDN. For instance [JavaScript frameworks and libraries]^1. I don't think these tutorials for 5 frameworks provide any value over the respective official tutorials. Even more so with outdated tutorials: the Svelte one is 5 years old, and there have been major changes since then.
^1: https://developer.mozilla.org/en-US/docs/Learn_web_developme...
- The quality of the webextension doc is low. A clear problem is that it's mostly for manifest v2, with a few incomplete pages mentioning a transition to v3 or the compatibility with Chrome. In practise, I started developing an webextension with this doc, then had to switch to Chrome's, though Firefox was my primary target.
Hey, I'm from the MDN team. Thank you for the compliment and the feedback, I really appreciate it! <3
I hear you on the complaints, I'll take this to the team. You might like this, in case you'd still like to learn building Firefox extensions → https://extensionworkshop.com/
While I believe that the tutorials for frameworks do not replace the official ones, I still find great value in having them available on MDN. Perhaps you are not seeing this because you are viewing the problem from the perspective of someone who already knows very well what these frameworks are and how they should be used.
I remember clearly how years ago MDN taught me what libraries and frameworks are and why I should (or not) care about them. I didn't have a CS background nor anyone to teach me. I would probably have been too intimidated to approach them if it weren't for MDN guiding me. I'm very grateful.
Hi, I'm from of the MDN team. While the team was briefly scaled down to just two members and a few contractors, we've since grown significantly.
Today, MDN is supported by a thriving team of 15, comprising core staff, contractors, and a broad network of partners and contributors who generously share their expertise to keep MDN strong and up to date.
I'm always happy to see organizations that are able to learn from their mistakes.
But yeah, your reaction was also my first.
I really dislike how much I worry about Mozilla. I'm not an anxious person, but Mozilla is so important and so frequently seemingly unaware of the reasons.
tl;dr: a slight majority of the recent top contributors do not appear to be Mozilla employees: I'm seeing Yale, several freelancers (paid by Mozilla?), and a bunch of random companies.
Hi, I'm part of the MDN team, and you're absolutely right! We’re fortunate to have a wide network of contributors, contractors, and partners who help us keep MDN accurate and up to date. As an open-source project, we deeply value and appreciate the incredible support we receive in building and maintaining extensive MDN content.
I want to say that the game play was really well done, I really enjoyed the progression (speed of enemies, number of enemies, how quickly they descended) and mechanics (being able to shoot their bullets!)! I don't recall exactly how the original invaders worked, so I'm not sure how much was copied vs changed, but I very much enjoyed this as a brief break. Thank you!
Thanks! I'm glad you enjoyed the game. The original Space Invaders was quite different. My version wasn't meant to replicate it, but it was certainly inspired by it.
For instance, the original didn't have health levels, whereas mine does. The invaders in the original were packed more densely across the screen, and the player had defensive bunkers that were gradually destroyed. My version doesn't include those. So while the two games are quite different, the original was definitely the inspiration that motivated me to create my own invaders-like game.
I've used MDN as my go-to web documentation for the majority of those 20 years. It's an essential resource: typically easier to read than the specs; practical info, cross-referenced, with examples (and some playgrounds).
It’s hard to learn about features you’re unfamiliar with on MDN. There are times that I read MDN docs and think “who is this for?” You can read two paragraphs and not even get an idea of what the feature is supposed to do or what problem it solves. If you’re not intimately familiar with the topic you’re not going to get anything out of reading it.
Sometimes it’s better just to read the spec because there’s more background information.
I’m glad that MDN exists, but I also wish it explained topics as well as CSS: The Definitive Guide. I failed to learn CSS the MDN docs for years before reading CSS: The Definitive Guide. I was up to speed in about three months. Everything made perfect sense.
I’d love to get a wiki that has the explanations of CSS: The Definitive Guide, kept up to date with the reference material of MDN.
Hi, I'm part of the MDN team. Thank you so much for your feedback, I'll be sure to share this with the team, and we’ll explore how we can build on it further.
Re: “Who is this for?”
Most of our reference pages are grounded in real-world browser implementations. Rather than documenting specs in isolation, we focus on features that have been implemented across browsers. We aim to present this information in a clear, neutral way, accessible to developers at any stage of their journey.
That said, we have expanded our efforts to create more learning-focused content, free resources designed to support new developers through a structured curriculum. Additionally, we’ve started publishing more in-depth guides on niche topics on our blog, which complements our core documentation but serves a slightly different purpose from what you mentioned.
I have in the past, about 4-5 years ago found some aspects of documentation on MDN in the examples that did not work in browsers because not implemented at the time, as well as some lack of clarity in documenting differences between fit-content function and fit-content keyword therefore I raised an issue https://github.com/mdn/sprints/issues and got the documentation amended. However of course that no longer works for the reasons already mentioned, not sure if there is some other place or process whereby you can raise issues and get documentation changed.
Thanks so much for sharing this — and for taking the time to raise those issues back then! <3
You're absolutely right that the old `mdn/sprints` repo is no longer the active channel for suggesting or discussing content changes. These days, we encourage folks to file issues directly in the mdn/content¹ GitHub repository. That’s where all our documentation now lives, and it’s actively maintained by MDN staff and contributors.
If you spot inaccuracies, outdated examples, or unclear distinctions on any page, we now have a way to report straight from the page, you can find this at the bottom of every page → "Report a problem with this content." Please feel free to open an issue² or even suggest edits directly via pull request. We also try to prioritize fixes based on how widely used or confusing a topic might be, so calling attention to edge cases or under-documented differences is genuinely helpful.
Let me know if you’d like help filing an issue or want to connect with the folks maintaining a specific area of the docs. We’d love to have you involved again!
not sure why people feel the need to complain in the comments of this anniversary post for a free service. been using the MDN docs for 5+ years and its been an invaluable resource that also promotes exploration - ive stumbled upon so many incredible APIs and capabilities i never wouldve have sought out otherwise. congrats on 20 years!
This feels a bit like Stroustrops comment “There are only two kinds of languages: the ones people complain about and the ones nobody uses”. If MDN was not such an invaluable service, not nearly as many people would end up forming opinions!
As someone who only dabbles in the web platform I’ve always found the MDN pages to be very refreshing compared to a lot of documentation out there
Is there a way to donate to MDN directly without donating to the larger Mozilla organization? I find MDN absolutely indispensable and would love to contribute in an earmarked way where it wouldn't be diverted elsewhere.
But I’ve grown increasingly frustrated with Mozilla as an organization. They’ve been actively draining resources away from Firefox, and honestly, I have no interest in supporting them further until they get their priorities straight.
Since the team is apparently reading this, I ran into SVG docs being less than great (to me). I was trying to use SVG and I think the way the docs are presented for SVG elements could maybe use some TLC. For example the 'g' element
What attributes can be used? All it says is "This element only includes global attributes.". Yea, ok, why isn't that a link to what are the global attributes are? There's nothing on the page that gets you to the attributes. Ideally they'd just be on this page so the user doesn't have to go digging.
Clicking "attributes" on the left brings up a list of attributes. Which ones are "global attributes". Why is it organized like this? If it was docs of structures for an API I would not expect each property to have its own page and not be described in that struct's page directly.
struct Person {
name: // links to /docs/name
age: // lines to /docs/age
}
struct Country {
name: // links to /docs/name
population: // links to /docs/population
}
struct Vehicle {
name: // links to docs/name
price: // links to docs/price
}
You'd expect (well, I'd expect), that docs for properties are include in the page.
But that's how the SVG element docs are organized.
Which at least has that element's unique properties listed. Even their though I have to go digging through the hierarchy to find what other properties. It would be way more useful to, at a glance, at least list all the attributes and methods including inherited ones, even if they are just links.
I use MDN as much as I can, and will pick a page from it even if it is lower in search results. I don't know how page ranks can put something over an MDN page.
Long ago when I first started seeing MDN references, I had assumed the M = Microsoft. That meant I avoided it like the plague not wanting to see IE specific or .NET type cruft. Boy did I feel dumb when I finally learned that's not what the M stood for and realized I could have been using it even earlier. Yet another example proving you know what happens when you assume
Hey, we try to maintain attribution from our wiki setup, still. Our contributors are of the utmost importance to us, and if you can tell me about the page you contributed to, I can share more.
Is this the same MDN that ruined their docs by having AI hallucinate answers instead of linking to working examples? Mozilla really forcing the AI angle on their poor teams :(
Though to be honest, if each answer was validated I have no issue with AI generated answers. When I ask ChatGPT or Gemini an API question, it often provides doc level details (it also often provides invalid and wrong info, hence my saying "if each answer was validated".
I have 2 small complaints:
- I sometimes read some dubious content on MDN. For instance [JavaScript frameworks and libraries]^1. I don't think these tutorials for 5 frameworks provide any value over the respective official tutorials. Even more so with outdated tutorials: the Svelte one is 5 years old, and there have been major changes since then. ^1: https://developer.mozilla.org/en-US/docs/Learn_web_developme...
- The quality of the webextension doc is low. A clear problem is that it's mostly for manifest v2, with a few incomplete pages mentioning a transition to v3 or the compatibility with Chrome. In practise, I started developing an webextension with this doc, then had to switch to Chrome's, though Firefox was my primary target.
I hear you on the complaints, I'll take this to the team. You might like this, in case you'd still like to learn building Firefox extensions → https://extensionworkshop.com/
I remember clearly how years ago MDN taught me what libraries and frameworks are and why I should (or not) care about them. I didn't have a CS background nor anyone to teach me. I would probably have been too intimidated to approach them if it weren't for MDN guiding me. I'm very grateful.
I couldn't agree more. MDN should expect to outlive userland libraries and frameworks.
I'm curious if Vercel will find a way to funnel MDN users right into their frameworks.
Or did they re-hire?
Today, MDN is supported by a thriving team of 15, comprising core staff, contractors, and a broad network of partners and contributors who generously share their expertise to keep MDN strong and up to date.
Our team → https://developer.mozilla.org/en-US/about#our_team
Can you share how many people are actually full time employees vs freelancers?
But yeah, your reaction was also my first.
I really dislike how much I worry about Mozilla. I'm not an anxious person, but Mozilla is so important and so frequently seemingly unaware of the reasons.
https://openwebdocs.org
If you'd like to take a look at our partners page → https://developer.mozilla.org/en-US/about#our_partners
https://github.com/mdn/content/pulse/monthly
tl;dr: a slight majority of the recent top contributors do not appear to be Mozilla employees: I'm seeing Yale, several freelancers (paid by Mozilla?), and a bunch of random companies.
The excellent documentation for the Canvas API [3] and OscillatorNode [4] on MDN made it quite easy to get started with developing the game.
[1] https://susam.net/invaders.html
[2] https://github.com/susam/invaders#why
[3] https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API
[4] https://developer.mozilla.org/en-US/docs/Web/API/OscillatorN...
For instance, the original didn't have health levels, whereas mine does. The invaders in the original were packed more densely across the screen, and the player had defensive bunkers that were gradually destroyed. My version doesn't include those. So while the two games are quite different, the original was definitely the inspiration that motivated me to create my own invaders-like game.
Thanks for keeping it relevant all this time.
Sometimes it’s better just to read the spec because there’s more background information.
I’m glad that MDN exists, but I also wish it explained topics as well as CSS: The Definitive Guide. I failed to learn CSS the MDN docs for years before reading CSS: The Definitive Guide. I was up to speed in about three months. Everything made perfect sense.
I’d love to get a wiki that has the explanations of CSS: The Definitive Guide, kept up to date with the reference material of MDN.
I’d pay for this.
Re: “Who is this for?” Most of our reference pages are grounded in real-world browser implementations. Rather than documenting specs in isolation, we focus on features that have been implemented across browsers. We aim to present this information in a clear, neutral way, accessible to developers at any stage of their journey.
That said, we have expanded our efforts to create more learning-focused content, free resources designed to support new developers through a structured curriculum. Additionally, we’ve started publishing more in-depth guides on niche topics on our blog, which complements our core documentation but serves a slightly different purpose from what you mentioned.
on edit: the issue, 5 years ago https://github.com/mdn/sprints/issues/3723
You're absolutely right that the old `mdn/sprints` repo is no longer the active channel for suggesting or discussing content changes. These days, we encourage folks to file issues directly in the mdn/content¹ GitHub repository. That’s where all our documentation now lives, and it’s actively maintained by MDN staff and contributors.
If you spot inaccuracies, outdated examples, or unclear distinctions on any page, we now have a way to report straight from the page, you can find this at the bottom of every page → "Report a problem with this content." Please feel free to open an issue² or even suggest edits directly via pull request. We also try to prioritize fixes based on how widely used or confusing a topic might be, so calling attention to edge cases or under-documented differences is genuinely helpful.
Let me know if you’d like help filing an issue or want to connect with the folks maintaining a specific area of the docs. We’d love to have you involved again!
¹ https://github.com/mdn/content ² https://github.com/mdn/content/issues/new/choose
As someone who only dabbles in the web platform I’ve always found the MDN pages to be very refreshing compared to a lot of documentation out there
But I’ve grown increasingly frustrated with Mozilla as an organization. They’ve been actively draining resources away from Firefox, and honestly, I have no interest in supporting them further until they get their priorities straight.
Since the team is apparently reading this, I ran into SVG docs being less than great (to me). I was trying to use SVG and I think the way the docs are presented for SVG elements could maybe use some TLC. For example the 'g' element
https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/E...
What attributes can be used? All it says is "This element only includes global attributes.". Yea, ok, why isn't that a link to what are the global attributes are? There's nothing on the page that gets you to the attributes. Ideally they'd just be on this page so the user doesn't have to go digging.
Clicking "attributes" on the left brings up a list of attributes. Which ones are "global attributes". Why is it organized like this? If it was docs of structures for an API I would not expect each property to have its own page and not be described in that struct's page directly.
You'd expect (well, I'd expect), that docs for properties are include in the page.But that's how the SVG element docs are organized.
Compare to HTMLCanvasElement
https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasE...
Which at least has that element's unique properties listed. Even their though I have to go digging through the hierarchy to find what other properties. It would be way more useful to, at a glance, at least list all the attributes and methods including inherited ones, even if they are just links.
Much of this seems semi automatable from IDL?
For example when Tailwind came out, all my searches for Css stuff moved to tailwind related searches.
And of course the LLM hit.
Long ago when I first started seeing MDN references, I had assumed the M = Microsoft. That meant I avoided it like the plague not wanting to see IE specific or .NET type cruft. Boy did I feel dumb when I finally learned that's not what the M stood for and realized I could have been using it even earlier. Yet another example proving you know what happens when you assume
If Mozilla could trivially put AST-explorer-esque metadata and interactivity into every <code> block would they want to?
If anyone wants to reach out I can show you what I mean and how it's done
Here's a wikihistory for the lexical grammar page → https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Though to be honest, if each answer was validated I have no issue with AI generated answers. When I ask ChatGPT or Gemini an API question, it often provides doc level details (it also often provides invalid and wrong info, hence my saying "if each answer was validated".