 Just wait one second for that We were calling Cool. Thank you very much. You should be able to see Actually, can you see the learns the learn web development? Is that what I'm sharing the excellent so and to cut a long story short what we ended up doing is creating two learning modules and the first one is Not on the URL because the sidebar doesn't seem to be updated Understanding client-side web development tools. I actually approached Remy sharp to write this because I thought he knows that stuff pretty well and I Know him fairly well and he would probably do a good job of writing that so I'm not going to go for every one of these in great detail but you know we have Client-side tooling overview which sort of takes you through, you know, what are all the different classifications of tool that you might use? We split it into Safety net as Remy calls it or basically, you know tools that help you to code more efficiently and more effectively The second top kind of classification we have is transformation tools so Things like build tools three processes all of that kind of stuff and then thirdly we have Post coding tools including things like deployment and testing so We don't go through every tool available, but we give a few examples and give a good idea in general of what those classifications of tools do The second one we have there as you can see is command line crash course because You know the command line is pretty much essential if you're going to be using a lot of this client-side tooling but it's just kind of something that In a lot of courses you see about web stuff these days They all seem to just assume that you know the command line whereas a lot of young folk coming up into this industry probably don't so much So that's real basics of command line Package management basically you know how to use npm and yarn to do interesting things what the point of package managers is etc etc How to use one at a basic level and then we introduce a complete tool chain Which basically provides a very very simple React app It uses post CSS to use a couple of features that aren't actually in the browser yet It uses parcel to do the build it uses ES lint and prettify to do a couple of useful kind of code caring type things and then we use github to Send it up to a repo and then we deploy that onto a netlify instance So it's just like a nice sort of simple Well I say simple it doesn't seem that simple to me but It's a nice simple kind of 10,000 foot walkthrough of the sort of stuff that you should be able to do web tools And I'm kind of thinking well let's keep it relatively generic And not and include as little as possible stuff about the actual tools So but it'll be simpler to Keep maintained and keep actually working So that was that Then I was very quickly going to introduce you to the other bit that I've got available which is the framework section So understanding client side JavaScript frameworks So again JavaScript frameworks is such a big deal these days that I thought well this probably deserves several modules But I thought well let's just produce one module to begin with just to kind of dip our toes in the water and say You know let's see how successful this is and then what people ask for later and then we can always add more later on So the idea here was I've got a couple of introductory guides that kind of say okay as An aspiring web developer who probably knows a bit of vanilla JavaScript Why bother to learn frameworks on top of that? How do they relate to vanilla JavaScript? Why do they exist what problems that they actually solve and that modern apps require and The native platform has a bit of trouble with sometimes What general kind of features do all frameworks tend to have and how do they all work together? When should you use a framework? When should you not use a framework? Which is another important thing that you know You don't really get with a lot of framework vendors documentation. It's just basically our framework is great So use it for everything. This is wonderful kind of thing. I know that they're not all like that But a lot of them tend to so I want to provide you know as neutral of you as possible That kind of says, you know, let's step back a bit and ask why or when you'd even use this stuff so With those bits out of the way in the first two articles there. I then provide I Originally intended this to be a fairly simple and Kind of walk through the real basics for each framework and look an article or so but I very quickly realized that Frameworks do so much and so complicated that you can't really explain even the basics just in a single Articles so we ended up with quite a few articles about react covering all the main sort of parts Covered ember as well because that still seems to be and fairly popular covered view Because views really cool and it seems to be up and coming We also wanted to cover Angular because I think from the last time I looked at the stats Angular seems to be the sort of the second most used framework still after react, but I couldn't Well, I had a few office naffos and authors dropping out and in the end I just ran out of time, but we want to We want to cover react later on and then after I published this stuff And Sebastian scurrano approached me and said he'd love to provide a course about Svelte basics, so we should have a Svelte series coming very soon, which I'm really pleased about because That's why I always wanted I didn't just want to cover the really big ones Even though it sort of makes sense to cover the biggest ones that are in the most demand But I also thought well, let's cover a smaller more often coming one just to kind of You know give a little bit of fairness to the smaller the smaller frameworks and Something I mean, I've already had a bit of abuse about this online, which is inevitable But and I have included this big section here, which is which frameworks did we choose because I Kind of thought well, it's difficult, but whenever I'll just stop sharing for a second, but when Whenever we cover anything that's not pure web technologies and MDN We tend to get abuse because it's like MDN is supposed to be the neutral place to go and learn about web standards And how dare you cover react and stuff. Are you just a Facebook shill rah, rah, rah, rah, rah We have got a little bit of that kind of rhetoric, but most people have been quite pleased about stuff As I say, I have tried to explain the narrative to kind of say, you know We're not being a lot of people said well Are you being sponsored by react and review and ember to cover their frameworks on your site? It's like well, no I literally just wanted to choose a variety of a few frameworks So that beginners had a place to at least start because of course, you know, it's all well and good explaining Generally what framework features do but really you can't learn about them about showing a specific example And for that you have to show a specific framework. So so, yeah, and That's kind of the first part of my talk done and the reason that I was referring to the The issue where I Delivered my talk information is basically the There's a bit there that says to solicit feedback you can either fill in a questionnaire or write some free-form feedback on A Google Doc link I provided or you can tweet me an email me So and if there's any feedback you have about this stuff after the session that you forgot to mention Then feel free to put it in one of those places, but I don't know Did any of you folks have any questions about this stuff or any feedback to share immediately? Well, yeah, sure It's it's fine if you don't because I mean this is quite a lot to throw it somebody and say tell me what you think But please please go ahead if you have some feedback Well the question that is always on my mind is how to make use of this and the thing that I always notice when I have to use MDM is That I have to leave the IDE that I'm in and I know that there are some plugins for VS code but You know I'm a decentralization developer and I was wondering if there's like, you know a clear copy of MDM that can be downloaded So it is just with my with my Yeah, the studio code or something like that and I can just reference to it and it would like The first of course, you would need a version of this like you would need versioning and a Distribution method for this but also What's more important is like it I would like to see in an IDE That if I have this JavaScript method and this is a promise like If in TypeScript, there is a promise popping up that I could see more information about the you know in-depth Documentation or articles around it immediately while I'm editing Without the round trip to the browser Right, that is that is a very good bit of feedback and it's not the first time I've heard it And I do have some kind of interesting news on both fronts really so the first Really it's kind of being unpacked. I can unpack this into two questions really the first one is you know Can we have an offline version of MDM available to you so that we don't have to keep loading it up in the browser And the second one really what you're saying is is there some way that I can have kind of MDN information? Popping up inside my ID, so I don't even have to leave it. I think that's both points pretty much covered, isn't it? So For the first one we have been asked about whether we can have an offline MDN a few times before and I suppose my first question is kind of Would it be good enough to have it? To just do some sort of simple service worker thing where we can just make all the pages available off my line I'm guessing not because that would still involve going to the web browser and secondly what kind of Format would you prefer to have it in what would be most useful in that regard? Since the formatting is in HTML at least the content wouldn't be need to be in HTML, but it should be Semantic in us. I'm not sure If it is feasible in visual studio code to just pop up an iframe and you know Drop the resources in a stat. I'm also not sure how Resized properties work, you know, if it if you have the documentation in the sidebar of the ID The layout should work for that So there might it might be a good idea to have a semi semantic version or like an Advanced HTML mode where you can maybe pass in, you know through the hash parameter of the HTML site You can pass in some visualization Hints where you can say that okay, please use this in dark mode now or not more importantly like broad information or thin information mode something like that I would not be looking for a completely devoid of Branding things so I would be okay with branding I would be okay with the modular logo being in there and stuff like that fine It's just the deep linking is important, you know, like that I can Inside the code like deep link and and see like one example for how it would be cool in the idea, you know, like I'm dreaming here, but If I have the ambient side for promises open that it shows me all the places in my project where I have promises, you know, like This automatic connection where in my code is this How does it relate to the things that are here? Sure So I have even better news kind of on that front. So just this week. I saw what one one of the MDN developers Gregor who's based in our Berlin office and was playing around with an idea of being able to just pull You know pull up MDN data kind of anywhere, you know, they'll the ultimate idea that he's working on is could we present? All of the MDN content is basically like a query queryable API so you can just bring it up anywhere that you can access it That's ultimately what we want to aim for now At the moment that will be a bit painful because all of the MDN data is contained in a my SQL database and All the Indian content should I say so it's not really structured content. It's just big blobs of stuff inside my SQL and So at the moment, we'd probably have to do some kind of scraping of the pages as we queried and I'm not sure how Performance would be on that. I suspect probably it wouldn't be great and there'd be a lot of Troubles of doing that. But I mean he is investigating that to start off with now The good bit of news is around the corner is coming probably end of this year start of next year and we're going to have MDN available In a github repo and we're moving out of the my SQL database and we're aiming to represent the content in a github repo. Initially, that would be HTML files and Of course, if it's just flat files and sat there available like that. It might be a bit easier to query but what what ultimately aiming to do Is we're aiming to turn it into structured markdown And Some like three members of my team are already working on writing the schemas writing the recipes writing a linter to lintel the content pages And, you know, fixing the errors to make sure that all of the pages are totally consistent and then when we turn it into the markdown content and Plus metadata to actually organize the content. This is the point when we should be able to start doing this a lot more easily. So It's a little way off perhaps, but we're already looking into this we've we've already come come into contact with this whole idea. Wouldn't it be great if you can just Query all of MDN's content as structured data and just pull it up where you need it. So that's what we're aiming towards and then of course at that point if we could get it into that state And anybody could just write plugins for their favorite ideas using it or web extensions or whatever they want. So that's kind of where we're going with that. As a developer of my own modules are things I need to invent the wheel reinvent the wheel when it comes to documentation and if MDN wouldn't manage it to, you know, like have a big fancy collaboration with TypeScript That would kind of lead the way towards other tools also being able to use the same documentation concept In theirs. So let's say if the MDN would provide a general purpose, you know, surface layer for documentation for advanced documentation for things or additional documentation of things like Conceptually speaking for me MDN is you have a concept of a promise and yes, a promise can be explained very briefly as a very easy sort of thing but it adds this facets to the documentation it gives more information it gives more It explains it well. There are some nice examples and stuff like that. So it's like you have this raw documentation that is usually coming from the developer and you have an additional layer of documentation that can come on top of it and that is true for pretty much any project doesn't matter what like if you're writing code The developer might do the initial bit of documentation and somebody might do an a top of it, you know, an additional layer on top of it and if there would be like a means how I could write just how I could give this on top of bit of information Pretty to the community that they have a platform to write these sort of things for my tools. That would be cool. Yeah, I mean that would be amazing like we all of the stuff that we provide is generally under permissive licenses and and we'd like to give it all back at the end of the day so if we could provide that sort of layer made generic enough so that it could be used for any docks project that would be brilliant I mean I'm probably going to go back to our developers and share this with them to give them a bit of an idea of kind of How much further we could go with it, you know, that would be absolutely great so I do really appreciate the thoughts on that. Yeah, and we'll definitely be in touch when we figure out some more in that direction. Okay, so thank you for that Martin. People have questions I have more. Well, yeah, what I was thinking is, and we only have about five minutes left and I think we need to rush on to another. I think there's another call going on after that but I mean, I don't really have time to discuss now the second bit of what what I was going to discuss so let's go on to a couple more questions and fill up the rest of the time that way. So, do you want to give me an example. Oh, sure. Okay. The other question that I had is about translation. I have a deep interest in translation and I have worked at a project that does a lot of translation. So, just brief back and it was a big organized at note school. We did the tutorials for note and they were translated in many languages as well, not as many as MDM. But we were struggling with this concept of there is code in our documentation that should be equal in all in all languages and there is text in those documentation that is not equal like We have updates to our tools where we say like, okay, we need to update the code example. It's broken and then all the translations would need an update. But if there is only like a informal piece of text from or it explains it different, you know, like badly in one language and well in another language and we only need to update that language. So there's some responsibility that is only for let's say the Japanese speaker and there's something that is more general. And I was wondering how you figured out to make this process like smooth. Like if you notice that there is an update in code that affects all the translations that you like get to let them know that it works. And if there is like, you know, like kind of like if you want to get the Mozilla docs to be broadly used by react frameworks or other frameworks, giving this sort of guide would help them to do it right. And you obviously know how to do this. So is there a document around this or So the answer I'm going to give you here is probably going to be quite disappointing really. I mean, yes, we do do translations. But what I find is I mean, in terms of purely the technical problem that you're discussing what we tend to do is We just have the English version written first and then we offer the service where if you want to create a translation of that you click on the languages drop down you click add a new translation you select the language that you want to do the translation of and then it gives you a And then it gives you like a little side by side view where it shows you the English and then lets you type in your translation to the right of that. So it's really basic. It's not very clever at all, unfortunately, and the code is just provided as is inside the translated document and there's nothing to stop the translator translating the code examples if they want to it's not. I mean, again, what we're moving towards is we're moving towards more examples being contained in a central repository. So if you look at, for example, our interactive examples which is the little editable examples that you see at the top of all of the JavaScript reference pages these days. They're all contained in a GitHub repo and generated when the static pages are generated. So they're kept that they're kept consistent regardless of the language and then we have some others too but it's by no means consistent yet. This is another huge problem. The main problem that we have is we don't really have any management structure that does the translations properly so we have really good French translations for example but that's totally down to the community having some really passionate members that keep those up to date as much as possible. But a lot of our translations are woefully out of date and we don't have any staff who even look at them these days so this is something that we badly badly need to improve on because at the moment it's really like we kind of pretend to do translations but we don't really and it's very sad. One of the things I'm starting up with a few of my colleagues is I'm doing a research project at the moment to kind of look like as I mentioned earlier we're moving towards this MDN as structured data in GitHub. And we're currently doing a project where we're researching what would be the best way to do localization in that new world of MDN. So I'm afraid I haven't really got a better answer for you at the moment. It's something we badly need to improve on. Yeah maybe like if you're halfway up the mountain you'll still see the rest of the top but if you're at the bottom anybody who is half up the mountain knows a lot more than you do. Yes I guess it's just I mean what ideally what I'd like to do is I'd like to employ like a community manager for each locale and get them to handle the community that would help with that and keep it moving but we just don't have the staff for that at the moment it's a real shame. And yeah, I don't know. But yeah I mean if you want some more information about localization I mean we're pretty much out of time now but my email address is on the OpenJS Foundation issue so feel free to drop me a line about this and the other things we've talked about and that goes for anybody else as well. Feel free to throw more questions at me offline or tweet me about them or fill your feedback in on the doc I've provided so. I will fill out the form. I have to go on too. Thank you for your time. Cool yeah thank you very much folks for coming and yeah I do appreciate you attending and I should hopefully see you soon somewhere on the web. Yep. Thank you Chris. All right thanks a lot. Thanks for having me.