 Hi, I'm rich. That's Anna. Hey, I'm Anna. Yeah, and This is weird, we don't know what to do that we're recording this weeks ahead of time This is not how we planned on on this happening but We're gonna we're gonna try this out. So yeah, this goes welcome to we'd like to level with you about no JS Yeah, I guess that's what means I should introduce myself. So Like rich I On the not just technical steering committee, we both have been contributing to not just for a long time now In my case, it's I think Four and a half years now rich probably even a bit longer So yeah, what so I work for a company called me a firm and Particular in the department called neo-firm research, which basically means I get to do Work on cool next generation not just features And I'm rich trot. I work for the inverse California, San Francisco in their library. I've been involved in the course since I think 2015 I Don't want to take credit for work. I did not do so I should point out that I did all of the slides except for this one And the next slide So, you know more importantly, she also wrote most of this talk So if there's anything technical and cool, it's probably because she came up with it So, yeah, we're recording this ahead of time Because of the COVID-19 pandemic. This is also in the midst of a lot of protest in the United States and beyond about police brutality on black bodies and As we speak the no JS website now looks like this for one week we have decided that we would Have a list of black people who have been Killed by Police brutality and it's just a really really Strange surreal time to be sitting here with my friend Nana and recording this talk about You know, it feels a little bit like naval gazing about note, but I hope you like it anyway so We go right from that to a rough transition to happy birthday, you know at 11 years Wow Yeah So so so that's like refers to the first release of note The kid block goes a bit Gives a bit further into the past, but this was the first release of note and it's been a Whole 11 years since then Yeah, so we're here today to talk about what went well and what hasn't gone well and We'll talk about do you know a little bit, right? I'm sure and You took a look at this the zero zero one commit and like all the files are gone now or something Yeah, yeah, so as the commit message says it like fixed something to work on free BSD In the build files and everything that the commit change is long gone by now and none of the files in there have existed for years Which kind of like it shows that no just code. It's not the same as it was five or Or more years ago and certainly not 11 So, so yeah, this is This is the contribution graph for node Because I'm a Graphics design pro. I just did a screenshot of the github page and inverted it So it's dark if it's with the dark teams. I'm sorry way lots and lots of things have happened since the first release of note The the most significant Impact points are the ones that I've labeled here. Well, I wouldn't call node 14 like significant Particularly, but it is where we are right now And so so some people might remember these zero to ten time. That was a long time ago, but it was It was when lots of people got into no chess in the first place. It was definitely during the hype phase It was also that hype that got me into note in the first place. Some people might remember the IOJS fork Something that that grew out of out of unhappiness with the governance model of node and that ultimately led to the to the governance structure that we have now when When that fork IOJS was merged back into node. Yes, it came with all new governance. It was no longer copied back Yeah, so so the the time when that happened was the before release that was the first post merger release of of node and And and that was kind of like when what I think when modern note development started not just because of the changed governance, but also, you know We we got some of the ES6. I think features. Yeah, we can now use Said the the next thing on the timeline here is the is the IOJS fork Which like it also grew out of unhappiness with no justice governance And and like I don't know if you want to call it successful or not but the at the very least we did I would say we did get some good governance changes out of that and Definitely also work our threads where you know, it kind of provided a green field to like play around with new ideas Work at threads was definitely the main one that first got developed there Yeah, and then there's a big gap more 14 All right I mean, they're like there were some nice important things that happened since then like I know the introduction of async await Like I mentioned the the for release was the first one that actually came with you know, some of the Things that you would consider modern JavaScript And and it also had a very different governance model and those things basically meant that you know the the the reason there are so many comments in that time was not Because there were so many contributors like they're like what the current situation is It's more just like, you know Work was done in a very I would call it like move fast and break things away People were just pushing commits to master and you know, they were writing cope that would not be considered legacy code And that that one was all fine for the time. I would say But it definitely kind of left us stuck with with you know legacy code. So so things that come from that time Are are all these streams versions? No, just says three different versions of screens basically and They are all from the time There's http one the http mod p module that everybody uses and And in particularly the TLS code and these are all things, you know In the context of the time it makes made sense to just get something together that works and and you know kind of say if we want to Make this a bit cleaner we can do so later and then as has so often that Kind of didn't happen. So these are things that are like That have not seen all that much change since that period They are basically I mean they have been changed a lot, but the basic structure is still there And that's kind of because you know, we didn't have good end encapsulation there no symbols So basically everything was easily accessible from from npm modules No clean apis that would you know Would allow npm modules to not hook into the internals of these things Not It's definitely one of the things that you know, I if I could redo them in node I I would completely replace them from scratch or or not not put them into note at all And and none of the people who originally wrote these are all that active anymore Which is also kind of a bummer In particular early for TLS like one of the you know, if there's this security issue with TLS we can fix it Or if there's something else it it just usually takes a long time until somebody gets around To to actually putting the work enough understanding what the code does and and how it needs to be changed So yeah, that's not a great situation for node to be in Right so So so one of the really nice things of the last year and note. I would say is so so a new collaborator joining Node.js team He's called Robert and he just put in a lot of work into You know figuring out how should screams actually work What changes need to be made? How can they be made in a way that does not break everybody? And and those of those 194 comments that he has made since then I think most of them are actually All like almost all of them are screams related scrims improvements And it shows that like if you if you really want to fix something That's possible. It just it takes a lot of work Yeah, it it would have been nice to not have HTTP one and node core I Guess that was also one of the things that just made sense at the time And I can totally see that but it would also have been so nice to have things that can be implemented outside of note And that includes HTTP to have them implemented in npm modules and and Yeah, so I mean like there was there is this concept that Node should have a small core and lots of people are in favor of that Which basically means the thing that I just said if it can be implemented outside of node core, it should be But that's in practice not the way that Node.js is currently moving At all I would say to me there's always been this tension between two things that that are supposedly tenants of One is small core which you see here and the other is batteries included and Those are like those are opposites, you know, like Well, yeah, they're opposites. I mean I mean batteries included means that like you shouldn't have to go out and find a module to do fundamental things and I do think that, you know, as much as it's a pain point for us now to have HTTP and core rather than, you know This stuff implemented elsewhere. Um, I Do think that that having it in core was pretty important to early adoption So two things there One I so I don't know how I would have felt about going the Python route But I think that would have been something that you know would have alleviated the small core concern to some degree Like basically ship node and ship a bunch of packages with it, but don't put it in the binary and Then develop it separately That that is something that I could I would have preferred that over like putting everything into into the main repo and shipping it as part of the binary and And and for things is like HTTP to or basically the same situation with HTTP one I mean, yeah, sure when no was created. We didn't have things like wasm But I kind of hope that you know that technology is Would be able to provide something like, you know, take this C++ library that does a lot of HTTP to state management And and put that into wasm make that usable from JavaScript and just let that be it no native code involved I think that's doable and I think that would be a lot nicer than Then having native code involved at all in the actual result. Hmm. Yeah, um, obviously that wasn't an option back in the day, but right So, yeah, this is the list of all modules that are currently available from the Node.js repo directly That's basically the list of built-in modules that are exposed by default without any flags And and yeah, it just turns out so like for lots of them, there's no native code involved And there's really no reason why they should have to be a node core. I mean, like we said for HTTP HTTP to TLS There's currently native code involved, but you know, it doesn't strictly have to be the case You know, they're so so what this says is basically there's quite a lot of Node core that doesn't really need to be in there or where it's totally reasonable to have user land alternatives If you're participating in the Node.js main repo if you're watching the repo you get hundreds of get-up notifications each day And that's that's kind of like so that kind of makes it an all or nothing thing You can't just like be involved casually or it's it's hard to do so if you really want to keep up with what's going on And and I feel like splitting that up into multiple repositories Would be really nice. I know people are thinking about that for some Items, I know I suggested it when we added async local storage, but Unfortunately, there weren't enough people who who agreed with me. I guess Like one thing that I don't like about this, you know Is that it makes it difficult to implement like a low-level internal API that you can build things on top of nicely and And you know, have that be more valley-fined I Would like to see that You know have have more modularity inside of Node core itself Not have every part of of note region to every other part of note Which is kind of what we are currently doing in a lot of a lot of cases Yeah, and a lot of the cases the way we in past the way we did it ended up exposing stuff to end users who then write modules that reach Welcome Pat Right and and that kind of like drives into the whole other direction Which is basically that we are adding more things to note that that kind of feel like they should go into note core because Well, we're going for web compatibility here and in browsers. They are also shipped by default as part of the browser And we're we're fine with that basically I think so So these are all things that are being added or have been added I mean, this is like a good thing and at the same time like it means that we end up with like multiple conflicting Like we now have two URL implementations the old one and the web combat one and we now have to to two module implementations the old one and In the new yeah, yeah, exactly. Yeah And we do keep adding stuff to note core and right Oh I don't know if you remember but do you like know the number of deprecated API's I Know there's over a hundred deprecation codes. I don't know that corresponds one per API Yeah, so it's like just short of 150 deprecation codes for node. I Have strong feelings about what is on that slide No, just has the purpose of being stable and not like, you know breaking changes are just like something that you can't do to Sort of thousands of not just developers need to update their own code That is usually legacy code and that makes upgrading from not just version to not just version Painful in a lot of cases and and so keeping the number of breaking changes low is is kind of really important to me personally As far as the future of no justice concern Okay, I have I feel like we've made like like certain missteps that I Mean, I'm not sure a lot of people in node core would agree with me that they're that they were They were missteps. I should actually like your opinion on this one. I To this day Think that adding error codes was a mistake. I Understand the motivation. I think the motivation is great. Um, But We're not particularly set up to manage large sets of Things like that well and We end up with like a Million far too specific ones and a bunch that are just catchalls and like we we all have debates about whether that this one of that one Should be a type error or or a regular error and so, you know Job script comes with like five or six different error types and we only probably would need like three or four of them Just use them in the big motivation Wasn't actually to help end well What in my opinion wasn't actually help end users as much as you could argue it helps end users to like be able to like Have an error code that they sniff or although I don't think it actually does in practice that anyone does in theory But the big motivation was that error codes It says we have our codes it meant that every time we change an error message We had to treat it as a breaking change because somebody in in in the ecosystem was probably Checking the text of that error message. I consider that kind in retrospect at least I consider that kind of friction a feature not a bug. I don't know if anybody How do you feel? I agree with a lot of what you just said, you know, so so the big thing is yeah our error messages Our error codes are way too specific They're not specific in the way that's useful because any single Method or you know, whatever it's only gonna Have like five or six errors. Maybe at most that it's gonna possibly emit You don't need to have the full list of all I don't know hundreds. I guess off error codes it What I don't like about how we did this is that the purpose was you know, like you said to keep people from from parsing error messages But we kind of like didn't go all the way on that. Yeah, they're still doing it and they're gonna keep doing it Yeah, and I'm pretty yellow because we're not providing a reason not to do that because for example, you know There's error messages that are parametrized where you know, there's some value that that goes in there and and That's not good because if we want to keep people from parsing error messages. We should make that We should make that information Programmatically accessible. We should put it on the arrow object that we're creating Instead of just like having a nice way to farm it here. Don't give any one ideas about making this more complicated I I have that that idea and I've thought about doing a poor request, but it's also like something that that's massive change But it's it's one that I would I would argue makes a lot of that sense then thirdly the so So one thing that I actually believe Java is doing right is Is that it differentiates between? You know runtime exceptions and programmatic errors programming errors and And our error codes don't do that and that's not helpful and then fourthly You know for programming errors It does not make any sense to put that sem for major restriction in place. I would say Because people should not be expecting that kind of error to happen And then fifthly, I I feel like we have just been lacking common sense in dealing with error messages We have been just applying the rule blank way that error message changes or error code changes a sem for major And not really thinking about how people actually would use these things in practice Wow want to talk about ESM Let's talk about ESM Ecoscript modules Right, so so this slide this is basically what everybody wants People want to be able to require ES modules With the required function and import common. Yes modules like existing ecosystem system modules just with import And these things are not going to happen Kind of sucks Yeah, and and And we will for be explaining why until the end of time and that's not anybody that's not people's fault It's just the nature of yeah Yeah, and we've gotten some flak for it. Not that not that. Anyway, let's we'll get to the flak Yeah So, I mean the basic story here as I understand it and I know you said you agree with it It's like well the JavaScript language one would say at modules because lots of people are using JavaScript in the browser And they don't really have a module system. It would be really nice that they did and That was kind of developed in a way that didn't work well with node because the first the existing ecosystem of modules Was just not really taking an account into at that at that point and And the reason how that worked out is that you know in browsers you want to you have things like network latency that you want to think about and and And you don't really have that in nowhere. You'll just load everything from disk, which is pretty fast comparably And we just like so The way that this ended up working is not has a synchronous module system The web has the somewhat asynchronous module system or at least that's the way it's kind of designed and No, just just wasn't really fast to to stand up in the committee meetings and say hey, this is incompatible we're not going to be able to to implement this in a way that makes the existing user base happy and That's kind of how we ended up with two Pretty incompatible systems some some things are going well I am I am really happy about this ratio It's like obviously not saying that every node contributor has about 10 commits but It's a lot better than other open source projects and yeah I don't know lots of these are from these spikes that you mentioned earlier when we're looking at the contribution graph Where we had people in a room that did their first kind it's but even without that it's It it shows that there's Significant community involvement Yeah, I'm happy about that. Yes, there's a people invested So an API is actually one of the things that I really do use as a module developer I maintain a couple libraries that use an API for native add-ons And this screenshot is from one of these libraries from the conversion to an API and and I love an API It makes writing clean code for nodes so much easier You don't have to understand all the Idealments that you need to know when you're working with VA directly anymore So it's it's a lot easier to write correct code And it's a lot easier to just write code and C++ or other languages that that are then Turned into native add-ons So such as to be clear the code on the left here it contains tons of misunderstandings about how the V8 API or its NAND wrapper works Because it was written before I like got into node core and started understanding all of these things and how to actually deal with With things Properly and and now I don't have to care about that anymore when I'm writing out. That's nice We talked about this bit earlier with the with what we could do with HTTP HTTP one if we were to like write these from scratch now. Yeah It's it's just it's cool that you can write code in other languages and let node run that and you can ship it Anywhere you don't need to worry about operating systems or platform architectures Or shared objects or anything like that You can just use node to run other languages code. I think that's awesome. That's awesome Well, let's talk about since yeah, since Ryan will have given his talk yesterday at this point Yeah So so obviously we have no idea what Ryan is going to say But if necessary, I think we can get into that in the Q&A The the then a release one zero zero is pretty freshly out and And obviously people have been talking about the future relationship of of note and then a lot But so it always seems like people think that that you know It's going to split the ecosystem that you know, they're going to move people in different directions and we end up with with like People who use only the one or people who use only the other and only write code for one of the other and and I don't think that's what's gonna happen I yeah, I Think so, I mean, it's it's already showing node. Jess is adding Compatibility for the web API because while people write JavaScript for the web a lot and it's really popular I think Dino has some kind of no Jess compatibility mechanisms that they're working on I'm really looking to it too much, but I saw that you know, they have commits of that kind in the Dino Rapo Get up. I think they're just all gonna move closer together in terms of what they can do Share more API's that everybody can code for and and and if people are happy or running that code with with Dino Then with note or vice versa, then great. I Whatever works for people, but what if we're wrong? Yeah, I mean so what get a good run I Don't think it will I don't think I don't you know, like I think I think you know the killer the you know There's there's too much too much riding on you know, too You know the NPM module system and things like that That you know, it's gonna make gonna create a lot of friction through the switch to Dino But they might and they might like it better and it might work better for them. I don't know. We'll see So it's Q&A time