MDN's audience and self-fulfilling prophecies: a rant

MDN
#1

Hello to whoever is in charge of MDN policy,

It is indisputable and well-understood that MDN is a resource first and foremost for web developers—those learning and working in front-end development. What I think may sometimes be less considered is that it has also been a valuable resource to many others working in adjacent fields: back-end developers, JavaScript engine implementors, tooling builders, etc. etc.

As such a user I have in the last year or two noticed that some of the bugs I file against MDN are met with a reply along the lines of ‘your use case is not important to us, because most of our users are web developers and so don’t benefit from <whatever change I suggested>’. (E.g.: re: links to older versions of the spec, re: polyfills)

In each case the reply is pretty reasonable in its individual context, but I think there is a danger that the “this feature is not useful to our core audience” attitude becomes self-fulfilling, because my experience has been that MDN is becoming less useful to me (and therefore, I posit, to other non-webdev users).

When I started working on JavaScript implementations in 2017 I would nearly always begin work on any particular feature by looking at MDN, and could usually do an initial implementation of the feature based on the material here; inevitably I would eventually have to go read the ECMAScript spec to get the corner cases correct, but I didn’t start there. By comparison, I now rarely bother consulting MDN at all. Partially that’s because I am more familiar with JavaScript in general and less intimidated by the relative complexity of the ECMAScript specifications—but it’s also at least in part because MDN no longer contains the information I previously came here to find.

The ultimate result is one less non-webdev user, and so even less reason to maintain whatever useful-but-not-to-webdev information remains. Not coincidentally, it also means less pair of spec-savvy eyes to spot, report and/or correct incorrect or misleading information here.

What audience MDN chooses to cater for is of course up to you—but let me suggest that the audience you have served in practice has historically been rather broader than the one you now appear to be focused on, and that being a little less narrowly focused could increase the total value that MDN provides for comparatively little additional effort.

Or, tl;dr: please don’t keep deleting information from MDN just because it isn’t useful to web developers.

Christopher

#2

Hi Christopher,

Thanks for your thoughts here. I appreciate and understand your feelings. It is always very frustrating when resources you’ve relied on or found useful in the past change for the worse, and become less useful.

You are completely right that we used to have a broader focus — we used to not only document the whole web platform, but we also used to document Mozilla internal technologies and all manner of other technologies. It was about three years ago now that we decided to narrow our scope to web platform only, and start getting rid of some of the web platform-related content that didn’t seem to have many users.

We did this out of necessity — we were having enough trouble keeping up with web platform changes as it was, without everything else in the mix too. And fast forward a couple of years, and we now have less full time writing staff on MDN than ever before, so we need to prioritise what we work on carefully.

I think one thing we need to note here is that it is not just about deleting something off MDN, or not. Everything we choose to keep on MDN is something else that we have to maintain, keep up-to-date, triage and act on bugs filed against it…

In the case of the JS/ES spec tables, we stopped listing the historic specs because we received a large amount of feedback that they were confusing, unhelpful, or harmful. We’ve received very little feedback asking for them back.

In the case of the Polyfills, we totally understand why they are useful, but we just don’t have the time to keep them maintained. Polyfills after often complex bits of code, and every time someone files another bug to say that a polyfill no longer works in IE11, or whatever, that’s potentially half a day of debugging and rewriting, which we just don’t have the time for. In the case of polyfills, we are looking for a different solution, such as linking out to a service like polyfill.io, to provide an equivalent solution.

2 Likes