 First, a little bit about me. I am Chris Mills and I'm the manager of the content writers team on Mozilla's MDN site. I also do our content lead work, so I spend most of my time kind of looking at what's coming out on the web platform now in the near and further future, just so I can inform my team about what we need to document and when. So we can prioritise and have a hope of getting the stuff documented by the time it comes out in browsers. I think it doesn't work, no? It never works. Oh, maybe I can't type. Oh, it's dashes not underscores. Oh, thank you. Sorry. That's it. I thought it's probably me that's made a mistake. So when I find the time, I also write lots of documentation about HTML, CSS, JavaScript and any other web tech that is useful to people. I'm a total accessibility winch bag, as I believe everybody should be. So that kind of informs and is a central theme for all the work I do. And then outside work, I'm also a heavy metal drummer. So if you come and speak to me afterwards, please speak slowly. I've been using that joke for 15 years in my talks and it's still not got old yet. Or maybe it was always old. So why am I here then? So I've been having some thoughts about how we could make MDN more useful to. Framework using web developers, which is, I suspect, probably most web developers these days. Because on MDN, we document basically the whole of the web platform. That's our remit, just a little tiny thing. And I just wanted to, I kind of think, well, more people in the real world these days are using frameworks of some kind than are just writing stuff of raw JavaScript. So I'd like to make the site more useful to these people. So I want to outline the plan of what I've got in my head and just get some ideas and talk about how folks could help if they want to get involved, basically. You know, because traditionally, MDN's position on documenting things like tools and frameworks has always been no. Because the web platform is big enough as a thing to try and document already. And also frameworks tend to change a lot quicker than native platform features do. So to try and kind of maintain all the web platform docs plus docs on loads of frameworks would be an absolute nightmare and we'd just send this all insane. And pretty much any framework or library worth its staff has its own fairly decent set of docs anyway, decent in some cases, I suspect, maybe not so much in others. But, you know, it's pointless just reinventing the wheel all the time. You know, we do get quite a lot of requests come in where people say, hey, why don't you guys just document React? Why don't you guys just document Angular? And we're just like, do you realize how much work that is? Just go away, please. And another big deal that we have on MDN is accusations of bias. You know, we're seen as this kind of platform neutral source of truth of a lot of different parts of the web platform. So, you know, we've had this in the past. Like, there was a time when I was writing some NBC articles, basically to say, you know, this is basically what that NBC looks on the client side. And I thought, well, we need to use one framework of some kind to demonstrate it. So I chose it because it was popular at the time. And even though I stated very clearly in the front of the documentation resource, you know, we've only chosen Ember because it's a framework that works right now. It's not our favorite. We're not advocating this is better than anybody else. We had an absolute fewer of saying MDN biased against Ember. And that's how it always works. It's just so we have to be very, very careful of bias. So. Future direction, then, you know, I want to get framework content on MDN, but kind of in a way that works for MDN and also works as a useful thing for web developers and framework vendors. And it's really, yeah, sure. Does that include note? Yes, absolutely. I mean, we've already started to put browser compact data stuff in there. That makes me so happy. That thing is Alexi Ruffin. Thank you. Again, that's what I'm talking about. I just wish it was a little bit less rough around the edges, but people seem to like it. So there's kind of three things that I would like to add to MDN. I mean, for a start, we have a complete beginners documentation section, you know, just I I write most of that stuff. I like to think that it takes people not from beginner to expert, but kind of from beginner to comfortable, you know, and then people to have the ability to then go and use the rest of MDN because we were getting loads of people saying, hey, I'm a beginner and MDN just sucks. It's just too hard for beginners. And I was like, right, we need to do something about that. So I did. But I'd also like to add some information in the beginner section about modern tooling, because, you know, I still think it's the best way to start. If you're a complete beginner, you should learn the raw technologies first before you go on to using all of the tooling. But at the same time, people are going to meet the tools as they start to progress towards working in the web industry. So it's pointless to kind of at the moment, I dox kind of pretend the tools don't exist for the most part, which is just silly. So I want to have some kind of beginners. This is, you know, this is modern web tooling and what you need to know, where you need to use different things, that kind of section. Of course, I haven't, I've had that idea in my head for about four years, but I haven't written it simply because I'm kind of terrified about trying to write it. You know, how do I say to complete beginners? This is all of JavaScript tooling and how you should use it and when you should use it. And it's just going to be a very hard thing to write, so I avoided it. I probably want to have something that just says, here's the high level concepts of the different tools that you'll want to use, what they are, what they do, when to use them and then for actual low level details, like actual examples, just point them to different tool vendors documentation instead or something like that. The second thing that we have on MDN that might be interesting is, as I've said before, our remit is basically web platform stuff, but we actually have a definition of what that is, you know, explicitly what we have on MDN written down on the site somewhere and it's basically stuff that's part of the web platform and has been implemented in browsers. Now, the trouble was we started getting a whole load of folks coming to us saying, but how about things like EPUB 3? It's a standard, it's used in browsers, but it's not really, well, some browsers have actually natively put support for EPUB 3, but at the time it wasn't and it's like, oh, how'd you deal with that? Because lots of people want to know about it, but strictly according to MDN's remit, it's just, no, we're not going to document it. And the same thing for IMSC, I don't know if you folks know what IMSC is, it's like a sort of an alternative to web VTT, so it does subtitling and captions and that kind of stuff except apparently it's more popular in the main industries that use that stuff like TV companies and stuff that want to put content on the web or use IMSC just because it's more powerful and varied than VTT and it's a bit more robust, but no browser has a native implementation of it, it's just used for JavaScript libraries, but more people use it than they do with VTT, so we have that documented on NBN. Hello. Just under that umbrella, you just talked about the stuff like WebRTC fall under that, are you guys documenting that currently or interested? Yeah, we're documenting that. Is that more within the, is that web specific APIs and so it falls under your... Yeah, yeah, I think that's fair to say. I mean, there's parts of it are natively implemented as well, but it's just there's a lot of stuff that still isn't. So, but yeah, we're trying to get an express again, that's another huge thing to document, but we're getting there. So long story short, because I have started to ramble, I would also be interested in talking to people from smaller frameworks or libraries that think, I'd like to find a place to put my documentation because I haven't got a place yet. I wouldn't mind experimenting with maybe having a couple of small libraries or frameworks, getting them documented at NBN to see how that feels. And then the third part of what I want to try and do, which is probably the biggest part, is I'm kind of thinking again, as I said before, it's pointless for me just to try and regurgitate React documentation or whatever, because React also already has good documentation, but I'd like to create some sort of resource which would contain loads of little tips or tidbits or FAQs or warnings or whatever you like to think of it, different entries, that kind of thing, things that would provide useful information about different frameworks. So, and we could maybe nest all those in context inside our existing reference pages. So you could maybe have something along the lines of, you go to a particular JavaScript method page and maybe it could say something like, blah, blah, blah. Oh, by the way, this doesn't play nicely inside React because of the way React is created just as a sort of vague example off the top of my head. So therefore, to work around this problem, you should do this. Useful little pieces of information in context in MDM, that's sort of the main thing I'm looking to do. And that's kind of a bit of a challenge again because obviously there's loads of information that could be represented in these different best practices. So I'd want to talk to some framework vendors about what are their most common pain points of people trying to learn their framework? What are the most common FAQs that come up and they have to answer them all the time? This is a project that I'd hope would be able to provide definitive answers for those kind of questions and from MDM's point of view, it would allow us to get more readers and more readers means executives are happy, et cetera, et cetera. But from their point of view, it would be more of a kind of, the answers to these questions are now available in clear places, which means that hopefully we'll get asked them less and be able to spend more time fixing bugs on the framework and coding new framework features rather than just answering questions for people all the time. And the way I'm thinking of doing this is like, rather than, I mean, the closest thing we have so far to this is a friend of mine called Eric Bailey, who lives in Boston, went around and basically added an accessibility concern section to all of the HTML and CSS reference pages. So for every single HTML and CSS property, now there's a little accessibility concerns thing that says, you know, for example, for background color, oh, you need to be careful of making sure your color contrast is high enough so that this isn't an accessibility problem, you know, these kinds of bits of information. So, but I'm thinking of doing something like that, but for useful information about frameworks. And the stuff that Eric wrote on MDM is hard coded into each page, but what I'd like to do is something more like to have a set of structured data, which would contain all of these different best practices in the same way that we do for our browser compact data on MDM, you know, we have all of our browser compact data sat in a repo, which is github.com slash mdn slash browser compact data, browser compact data is separated by hash. Those line things, yeah. My brain has just gone, you're 40 now, you're having a senile moment. Hi, friends, that's the word I was looking for. So, we have all of that information in structured JSON files, and then we just use a macro to splurge out into the different MDM pages. I'd probably want to do something more like that for this setup as well. First of all, because it would be a lot easy to do mass updates and things to the information, if it's in structured data. Secondly, because it could then be used in all sorts of different places, you know, as well as it just being useful on MDM, you know, for example, again, taking React as an example, you know, the React core team could just come and say, hey, we'd like to create a website that specifically shows all of the React best practices and they could just grab the data and use it there as well. So it'd be like a useful place to have it as a reusable data. And also, thinking defensively, it would be also a lot easier to remove if it turns out this project is a complete failure and doesn't work. So I could just basically remove it all using one call rather than having to go around and edit hundreds of pages, which is something we've historically had to do far too often than MDM. So yeah, so that's kind of my little elevator pitch. I guess, at this point, I could take questions. So any specific questions or ideas about different subjects to cover or anything else? Yeah. So you mentioned at one point, you want to reach out to the small train tracks to see if they, like, I guess to pilot what it might look like to have their documentation on MDM. Yeah. What do good candidates for that work like? So I guess, basically, one requirement would definitely be having the availability of a team that would be prepared to write most of the documentation. So one thing I have to say straight up is, you know, the MDM team is so busy doing web platform stuff that we don't have time just to write all of this stuff on our own. So we'd probably act more in this kind of advisory capacity in terms of helping get the documentation up there and reviewing it, et cetera, et cetera. We wouldn't really have that much time to write it wholesale, but that's what I've kind of done. I mean, in a way, we treat these bits of documentation similar to how we treat P5 bugs in that system, which is kind of, you know, documentation which would be good to do, but it's not in our remits so we're not going to do it kind of thing. But I mean, in particular with the IMSC and EPUB3 communities, I've basically sort of set them up with a core team of documentation writers and just help them get their stuff written and reviewed it for them and made sure the structure's correct, et cetera, et cetera. So follow up question unless these are follow up questions. Okay, just one more follow-up. Oh, we'll do that follow-up first and then we'll get to somebody else. So if that framework or these other other races have their own documentation existing somewhere already, is that just like on for again? So maybe like, it's okay if they import it? It would be fine if it will be imported, yeah. If they wanted some, you know, maybe if they have their documentation somewhere, but it's not looking so good and they just want to use kind of MDN structure and stuff to make it look better and make more sense, that would also be okay. But I do want to make sure that we don't get, you know, documentation update in two places. But yeah. Okay, at the back there. Thanks, that's a great question. So thank you so much for this session. Like, I like, I love that you can give me your questions. I guess I have a great question for you. Oh, and my name's Amal Christine. I'm Jason Boston. So my great question is like, I feel like MDN is about the web platform, you know, frameworks and like all of the tooling around public development is very kind of like, no standards, wild, wild, wild, and that's cool. That's what makes it awesome and we can iterate fast. And I'm just concerned around like, what it means for new developers coming to MDN without really a lot of historical context over like, what is the standard? What is, you know, what is a web API versus like, you know, JSX, right? And kind of like the kind of message and signaling there that like the web is frameworks, frameworks are your web. And I'm just, that's just a gut check for me. I'd love to hear your thoughts on that. So that is a really great question. I mean, this is something that we do have to be very careful of. I suppose my kind of short answer to that is, you know, the sort of places where we didn't, where we would include the information just in context. I, you know, a JavaScript reference page that's got some React best practices and some Angular best practices or whatever. The primary audience for all of the reference material is kind of established web developers or maybe, perhaps not call them advanced, but, you know, definitely not beginning web developers that are perhaps a bit more likely to have a bit more of that historical context. But at the same time, that's not a given that everybody will be in that situation. So we probably would have to have maybe some sort of little information circle that you can just get a tool tip that says, you know, these are frameworks blah blah blah and then maybe learn more about what frameworks are and then there's a little link to a piece of common information about that. In the case of the beginner's information, you know, that would definitely be very clearly stated, you know, or all of the beginner's information I write has a kind of, you know, when you first get to it, very clearly says, you know, this is what you should, these are your prerequisites for reading these docs and, you know, please go back and read these bits first if you're not already clear on them just to make sure that you understand the whole kind of situation. So, but yeah, you're absolutely right. That is a serious concern. No, it's cool. Okay, welcome back to your follow-up. Okay, so do we have any other questions? Yeah, well, so since we're at the historically Node.js clapper summit, I'm wondering what Node.js being kind of framework like for things, for APIs that are in common between node and the web that aren't just JavaScript like set time out where it's kind of in common. I just checked and I don't, I mean, it's great to have node compatibility here. For that one, there's, if we wanted to document it, then we might have a section that notes differences. Do you think this kind of stuff would be good for end-to-end? Yeah, absolutely. This is exactly the kind of stuff, you know, exactly the kind of stuff that is slightly tricky and not obvious and trips people up with some sort of regularity. That would be perfect for these kind of best practices and all tips or whatever you wanna call them. So, yeah. Do you have an idea of like, if it's important to scope that effort and like how far down to scope that effort because I think a lot of different JavaScript environments have set time out functions and here are any thoughts on that. Because you mentioned smaller frameworks, which is sort of makes the project have a broader scope than I would have expected. Yeah, this is the thing. I haven't really played so much of the scope yet. I'm just kind of at the moment sort of casting that as wide as I can just to see what might make sense kind of thing. And then, you know, before too long, I'm probably gonna arrive on some sort of sensible scoping which will allow me just to remain sane while I'm trying to kind of shepherd all of this stuff. Yeah. So, yeah. I suppose for smaller frameworks, I was kind of hoping to just experiment with having little documentation resources sat there on kind of like my web-related section along with things like IMSC and EPUB 3. But of course, there is the chance that they would also want to put little best practices throughout the pages as well. So I'm guessing probably what I'd start with would just be to start with the best practices stuff and probably maybe start with one existing major framework that's popular and obviously has a lot of users. So it'd be a good sort of low-hanging fruit place to start. Yeah. Cool. Hey. So I was trying to think about what I might like to see from a description of frameworks, like what I can't find on the internet. And one thing that I often come across is when I'm choosing between frameworks, how to choose what framework for what job or whatever. And so you can always find, I mean, there's a million articles always talking about the differences between frameworks, but they publish articles that don't have this ability to contribute to them or update them. And Wikipedia also doesn't really do like a, I mean, the other place where this is kind of like, you might think you might find something like this on Wikipedia, like the description of the framework, what it's good at, what it's bad at, why you might use this one over this one. And you don't really find that they're either, I mean, each framework, Wikipedia pages, like totally different. It doesn't have like that same like format that makes it easier to compare. Maybe something like that would be cool on MDN. That's really cool that you mentioned that actually, that's not the first time that's been said to me today. Oh yeah? So obviously there's quite a lot of interest in this. And I absolutely think, I mean, I suspect I'd probably put that kind of article as part of the beginner's tooling kind of set of module docs, you know, just like, you know, this is frameworks. And by the way, you'll come across a whole ton of them. Here's the advantages and disadvantages. And we could just sort of make an effort to keep that up to date. Right. You know, it's like, this is another thing that I've started this year is the idea of the, this has been the year of maintenance, which is kind of, you know, not the most obviously awesomely cool project to work on that you might think. But it's interesting just to think we've been a load of kind of archeology on MDN just to try and find a load of really outdated stuff and work out with or update it or get rid of it and updating a load of pages that are important to us just to make sure that they're the best they can be. So we definitely include the framework stuff in that regular maintenance. You know, I've never looked at the tutorials in MDN, are these that you've discussed the kind of, I've only ever seen like, you know, of course, it was definitely. But do people contribute to the tutorials as much as they could be some definitions that I get up to date? Or do you think it's more kind of? People do contribute in different ways, I suppose. I think with the beginner's tutorials, people tend to contribute a lot in kind of just fixing grammatical errors and reporting things that don't make as much sense as they should, you know, just so that's also really useful, you know, the idea that we try and write our stuff as free of idioms or slang and things as possible just to make sure that it's understandable for people who perhaps English isn't their first language. So that's always useful feedback to get. I guess I just wanted to like in particular emphasize that this is the kind of thing that will change a lot over time, like comparing different frameworks. Again, they're always. Absolutely, yeah. So definitely it seems like they somehow that it should be like, this is how it would be like on the MDN, like somehow, some way that it's clear that people should contribute to this. Yeah, I mean, that's always a challenge. We have this joke on the team of kind of like every year we say, should we just make the edit? Every year we'll make the edit button five pixels bigger in many directions to see actually what point the critical mass arrives and people actually start flicking on the damn thing. Because they, you know, and I was saying this to somebody else earlier, but like the probably we tend to find in terms of contributing to something like MDN is, you know, the site has a lot of gravitas in the industry. Therefore you get a lot of people, you know, no next, I've known kind of no experts in various subjects that I know would have a very authoritative voice and it'd be great to edit thing A or thing B, come to me and say, well, I've noticed this problem, but I don't feel like I should really edit it because I don't know if I'm really supposed to or whatever. And I'm just like, that's amazing. Like these people that are absolutely, you know, honest experts in these particular areas. And on the other end of the scale, you get the Dunning-Kruger effect coming to play and people just go, I'm just going to go and start destroying this shit. And you're like, would you please stop, please, please. And it's very rare that you get in between the sort of sensible in between. Anyway, more questions. Okay. So it's just like a follow-up on the editing thing. I was just looking at like, I know that the Microsoft Azure Docs do this where they highlight people who have contributed to a page. I think that kind of helps probably to drive that. One of the things, I work at Microsoft, one of the things that I like about the docs is also like somehow, I don't know how they put issues and like into this inline, which is a nice thing of like, here's a way to kind of go see what's happening on GitHub or on whatever platform you're using inside of this and like kind of have that as your comment section, except have it be in a useful way that's like issues. So that might be something to consider as well for that. That's interesting that we've taught you so often with the idea of having some sort of comment section or old style with key help pages or whatever for people to contribute. But again, we decided not to because we're so short staffed in terms of, can you imagine the amount of stuff extra maintenance that would open up? But in actual fact, having it regulated in some way like GitHub issues attached to pages or something would be quite interesting. In fact, long-term we're aiming to move like the whole of MDN just over to GitHub completely just as a huge set of structured data because it will be so much more useful in so many ways. But for the moment we're stuck on the archaic wikis that we're getting there, why? Well, you could get wikis. We could. So I think this touches on the some points of the problems of contributions. One of the issues that I've been having for a long time is trying to use docs offline. And you know, this is my old time at PV. But some of the things that I've been realizing. So there are some tools like DevDocs.io that make this possible for pages. DevDocs.io is basically what it does is it's crapes website and just packages them up that you can download in your browser, except, and I felt very good about that because now I can have this 40-hour flight and I'm disconnected but I can still work except I realizing that actual library I don't have the docs for because I forgot to scrape them and then you go into the Node.js directory and like try to peek into the no modules order and like scrape the information off of the markdown reading files. And so I was like, yeah, I'm just gonna make a, make a package for this. So it can be installed actually and it can be used offline like the documentation of this particular package. The next time I use this they realize that the format is super complicated for making this like scrapers and whatever is tripping all the information out which actually comes back to you. If we would start pulling in the information like we would probably want the framework authors themselves to contribute that documentation into MDM which kind of raises the question is there going to be like a MDM format or like, how are you gonna try to, like is there a, are you striving to standardize some of that, you know, documentation for web things beyond web APIs that people can like, it may innovate to make it easier for framework authors to contribute that. Yeah, that's a very good question and a very good point. So in terms of, it depends which bit of docs you're talking about really. So in terms of, you know, documenting a small framework on this web related section that I'm talking about, there's already established formats for things like API docs and stuff that they could use. In terms of the, like the framework best practices that I want to dump in appropriate parts of MDM pages, this is why I'm on about using some sort of structured JSON format just to write them into, you know, to try and, and this would require a bit of playing around, you know, we could sort of get a few different people from a few different vendors involved and just say, you know, what, what, let's try and break this format and improve it and see how we could make it work as well as possible for different people. The idea would definitely be to keep these different best practices fairly short. And if there's more information, if there's a whole ton more information about a particular thing that you want to get across, you'd probably just want to summarize it in the actual best practice and then just link out to a separate blog post somewhere, because otherwise the pages would just become chaos. So we'd need to think about that carefully. Hey, at the back again. So I'm really glad that you said that, because now I can ask you a question. You know, MDM has the luxury of kind of eating, you know, how, how, how is the information, how, how, how we kind of do the, you know, these areas of APIs and, you know, how it's like, you know, it relates to web interoperability and how it relates to performance test speeds and what's, you know, so forth and so on. And to me, like frameworks, like they're, there's, it's just, it's like, I feel like we're square in a circle and we're trying to like make them the same. You know, I think, first of all, like docs are like, there's no set of standards at all within docs. Like you just, you know, react and your lower spells, whatever, right? They all have different formats. They're constantly changing. They're just like constant pull requests. Like I think like the graphic speed of like framework duration is kind of, kind of like a, it's at a constant conflict with, I think, like the pace that, you know, the pace that I think in the bandwidth is for your team. And so I'm curious, like, I just, I'm really curious what the driving factors were for like you wanting to make this decision. Cause I think there was probably, you know, I'm sure there are lots of driving factors. And I'm, I'm curious if we could kind of shift your, your driving factors off of MVN and maybe to like a separate thing. Because like, you know, I think it's, you know, for me, it's just like trying to get this into MVN seems like, for me, I would not be in favor of it. Okay. Okay, no, it's totally reasonable opinion. Yeah, I mean, this is why I'm talking about it being some sort of a separate structured data thing. So we can, you know, kind of create whatever we want out of it and have it maybe in some sort of standardized format would also be a bonus side effect of that as well. I quite like it to still, that we could still have it in a way that would allow me to kind of just take useful snippets out and put them in places and MVN, that's obviously where I've started from. But I mean, I'm certainly in favor of exploring that. Yeah, I'm sorry, I guess I didn't like fully explain myself while it's more so because there's a high maintenance cost to getting off with the real range. And it's not worth it. Like, people can always go to the briefing of that repo and make sure that they're getting the latest and the greatest reporting to the, I've reported to the, you know, there's a straight to the worst amount, right? So, and so I think we might be causing more complexity here. Okay, yeah, that's a good point. Yeah, I agree with that. And what I see from your document here is that, or what I hear from you as well is that keeping with the spirit of MVN and helping people really learn and understand whether the APIs want to be able to give them the relevant information that might be, information that might be relevant to the frameworks we're already using so that they can better utilize the APIs that they're seeing and using. And when I think about MVN, one of the most, I mean, MVN is my preferred, you know, I like to be through these schools, whatever, as well. But I use MVN, like, if it's on MVN, it's true in my opinion. And the way that I encounter MVN documentation is typically when I'm stuck and I'm searching because you guys have a readable domain authority, you know, you're at the very top of the results patiently. And so I agree that specifically if, and you already said it yourself, but, you know, it would be duplicating work to try to have documentation for frameworks maintained in two places, which is basically a nightmare. And what I hear from you is that you want to be able to have these tidbits of information easily discoverable and in a way that reduces the maintenance overhead for you and also puts it in a place where people are useful, or it's useful for people, and that you're stuck on the Wiki style, so, you know, that can't directly change. But I think one of the most useful things that you have is links, linkability. With the MVN, you know, every once in a while I'll fall down a hole where I learned so much that I didn't know was there by following the links on your site. So I would be, I really like to where you're talking about overviews and being useful to people at all different levels, essentially. So I think something like an article where the difference between JavaScript and Node.js, that would be one, super helpful to a lot of people, and two, with your domain authority, it would be very discoverable. So I think that, and also specifically age as well, in that that's not gonna change as rapidly as, you know, like React coming out with a new version, et cetera, et cetera. So I think maybe it would be a good place to start, might be having like a landing page for a specific framework, like say, MDN's React tips or whatever. And that would be where the structured data would initially live, if it was like, you know, here's a bunch of tips that have been contributed, et cetera, and they can link you out to other parts of the website. And then maybe potentially once you get it figured out, you can pull in those tips into those relevant link pages. And I feel like that kind of content would age really well, especially like what you were saying, what the differences between different frameworks, because of the domain authority MDN has, that would be, I think that would help a lot of people and it doesn't change nearly as fast as the actual APIs of the frameworks. And most of these maintainers on these smaller frameworks, they likely don't have the time or desire to maintain docs in two different places. And so if you figure out a way to make that easy, what's that? Wasn't that the whole point of the G something? I mean, MDN's all about the content. You have these different pages about different things. And then each page has a bunch of different ways that it relates to things. It's the exact opposite of what you're describing. And this is sort of a barrier for new people to write MDN articles, because at least this is my experience in trying to get TC 309 people to write things on MDN. I mean, they just take time to learn this format, but this is like the entire point of it. So like having a single page at that point, there's no real point in having it be on MDN. The point of being on MDN is that it speaks to the different articles. And the JSON, I thought the tooling that you described sounded like a great idea. I think it's probably a great idea too. It's just until that is set up and in place, I think that it would be easier to maintain for the people contributing the stuff, as well as the MDN team, if they were... I mean, it doesn't have to be one where you see problems if someone does hit a theme for structure. Are you like... No, I'm saying that I would be happy to help try to contribute some of these articles myself from the time my company hits me. And that seems like a more reasonable like chunk that we could take on rather than trying to go and you know, add it to... Well, I would love to see the others for you guys to come up with. I mean, it's certainly a reasonable concern what you're saying. And I, you know, part of me sort of sits there and thinks, yeah, it'd be a hell of a lot less effort just to do what you're saying. I quite like both approaches, though. I could see what the sort of stuff you're saying would actually live very well in this kind of beginner's tooling kind of thing that I'm talking about creating. And it might be like a lower maintenance place to start while we do get some of the tooling set up. So I think both approaches could potentially work. I mean, another thing that you've kind of alluded to in what you said is like, I talk about having these little tidbits away. We're going to call them strictly speaking in context, inappropriate places, but things don't necessarily have to be on exactly the right pages for people to just go and find them because this is the web, you know. So... Yeah, to be clear, I'm sorry for John. I'm not opposed to having them put in there. I mostly, like, I'm into that idea specifically. I just want to just just put out there too that, like, I agree that duplicating the full, duplicating documentation in two places is probably a non-starter for most of the projects, et cetera. Sure. I mean, that's why I deliberately want to keep these best practices deliberately very small so that we can just link to other places where the stuff is covered in more detail too. So who's next? You look very excited. Go. I have an idea, which I think we'll end up with a search on you, Chris, okay? Okay. So, and I come from the web side perspective, so I'm advocating for my future, right? So where are they? We barely read the rough docs, or millennials, we skim, whatever, okay? Yeah. So, yeah, no, seriously. YouTube videos. It's all YouTube videos these days. Since people don't read the proxies. So, I'd actually suggest something that I think a better long-term solution, which I think can help bridge the gap in a way that's very, very good with the EGLE system, which is instead of you trying to get the frameworks into MVN, let's get MVN into the frameworks. Okay, so what does that mean? That means if that's, or a core routine API, or a core routine library is like, look at all these cool things I'm doing with generators and it's like, here's the MVN link, right? So, it's about creating a culture of like, link back to MVN when explaining a web API. And then there's a way to scale that up even more, which is actually for tooling, using ASCII-based tooling. We can very easily take a library, parse it, figure out what features it's using, auto add docs to the source code, like if you want, or to the region, or whatever, like makes sense, but there's ways to auto...