Paul: Hi there and welcome to PodRocket. So today we have a very interesting episode that we're going to bring you on Node.js, and what's happening in the land of Node 18, which is coming out now. So today we have Beth Griggs with us. Beth is a senior software engineer at Red Hat and part of the Node.js Technical steering committee. Hi, Beth. Welcome to the show. Beth Griggs: Hello. Great to be here. Paul: Thanks for coming on. So you're working at Red Hat and you're on the Node.js Technical steering committee. From my point of view that does look like two very separate and intense positions and areas of responsibility for you to uphold. Is it kinda like the same job that you do, are they one and the same? Beth Griggs: Yes, I'm in the... We have the Node.js runtime team at Red Hat. It was previously at IBM, but I hopped over about 18 months ago. My whole role is related to both Node, the open source project, and also some Red Hat Node.js spaces. It's a nice mix of the two kind of priorities. Paul: And are you a fan of the JavaScript ecosystem yourself? Love developing- Beth Griggs: Yes. Paul: ...it, because... Okay. Then you're a senior in a senior position, I'm sure you've run through the gamut of languages. It's good to hear that you're working in what you love, in the ecosystem you really like. Yeah. As I mentioned in the intro, I'd love to talk about the new node version that's coming out. I think that this is one of the things that kind of flies under the radar, unless you're like in the weeds, or you're in that senior position where you have to make decisions about different paradigms that you might change, or different languages. This is something that I might not look at, but when you go search what's going on, "Oh, there's a new Fetch API that's coming out." That's huge. Paul: Right. If you're listening and you want like the latest updates, let's get into it and talk about what those are. And I'm also curious if we can sprinkle in there, how you guys do release cycles. Beth Griggs: Mm-hmm (affirmative). Paul: For anybody that's stepping into this and being like, "All right, I want to start keeping up with how these things get released. How do I check it?" And stuff like that. Maybe we could start there, with how you perform the release cycle and your responsibilities. Beth Griggs: Sure. Yes. So I am a very active member of the Node.js Release working group, and they have delegated responsibility over all of the release policies and processes. It's our group that really sets the schedule, and prepares the releases, and does all that. And, the main, the key thing we aim for in the release working group, for the release cycle, is to be predictable. And this came about probably not long after the IO.js and Node.js merge. They realized it was very valuable to have a predictable release cycle, because that helped the larger enterprises start adopting Node.js. Because, you know, way back then it was still an early open source project. They were probably used to the Java kind of ecosystems more, where they had a predictable release schedule and cadence, and the long term support policies. That was introduced into Node, and we've tried to keep to that. Beth Griggs: It can be a little bit complicated if you're not reading through the policies every day, but generally the policy is odd numbered releases only ever current, and current is what we use. You could think of it like a beta release. It's how you get the latest features, how you play with the latest updates, and get your hands on all that stuff. But it's actually the even number releases, which get promoted to long term support. And those are the kind of release lines you want to be building your enterprise grade applications on. So, what we find is a lot of businesses like Red Hat and our clients, because they are operating massive deployments, they all stick to the even numbered release lines. And maybe just test against the odd numbered ones, because they're more featured release lines. And Node.js 18 is very much exciting, for particularly for many people because they will adopt Node 18 at some point, probably in October when it reaches long-term support. So, it may be the first time they get their hands on quite a few features. Paul: And so that's because, as you were saying, this mechanic of Node 17, which we're all using right now, that's the beta we can think of that as, or the beta I would say... Beth Griggs: Yes, yes. Paul: So we can call that beta. So now there's going to be almost a two major version shift for the enterprise folks. Beth Griggs: Yes. Paul: Okay. Gotcha. Very interesting. And yeah, Node 18 does seem really exciting. I didn't have... I probably can't read this at the same level of depth that you can. I did see the Fetch API was becoming standard, and that's huge for me because I'm in the server list and Lambda type of stuff, but I'm sure that is just the tip of the iceberg. If we want to jump right into it, what are some of the features that you're most excited about, or you think other folks might be... have their eye peeled on? Beth Griggs: Yeah. In the release announcement, the three key things we tried to put out there is one, the V8 JavaScript engine upgrade. And with every major version of Node.js, we tend to upgrade the underlying Google Chrome V8 engine. And it's actually through that update that we pick up some of the JavaScript language syntax features. I think in this release, because we've gone up to V8 10.1, we've picked up some of the new array methods, like find last and find last index, those kind of things. That's always exciting, because it's how Node developers get their hands on the new JavaScript language features and some texts. But generally each version of V8, they'll be working quite a lot, investing a lot of effort into performance improvements and tweaks. In theory, over time, maybe things like private classes or things will be optimized slightly differently in newer versions of V8. Paul: Now the V8 engine, you said that's coming in a 10.1? Beth Griggs: Mm-hmm (affirmative). Yeah. Paul: So I don't know much about the V8 engine. Is this update we're getting now more of a performance update, more of a... Beth Griggs: Yeah. Paul: ... A semantics update. Cause I know there have been some years that the V8 engine just got a ridiculous performance boost or something. Is this a similar year like that or what's the nature of it? Beth Griggs: I think it's more of a typical upgrade. There's no massive new, to my knowledge, groundbreaking performance change that I know of. But it's a mixture. It's a typical update, what we'd see. We see a few new features, like the array API's being available, and also some performance tweaks and improvements. Paul: Gotcha. Okay. And the Fetch API, I'd love to talk about that really quick. I know I've mentioned it twice already, because it's really exciting. Before I had to pull in a package, and now this is one of the things there's just going to be shipped. Are there any concerns about security of being able to contact different websites, or directly in the engine, or it being shipped by default? Or is there anything that you think is going to change with the development of the Fetch API? Beth Griggs: That was quite an interesting story to this one. The Fetch API was introduced via the Undici. So it's based on the Undici implementation, and Undici was created... Paul: And how do we spell that? Sorry if I'm being... Beth Griggs: U N D I C I. Paul: Okay. Awesome. Beth Griggs: The Italian word for 11, I think, but don't quote me on that. And it's an implementation from the ground up of HDP.1.1. They added the Fetch API into that project and now we've, in Node 18, we took the decision to expose the Fetch API that's based on the implementation that's in that project in Node 18 by default. It is experimental, so the Fetch API in node can change. We have this notion of experimental features, and if you're using those you should use them with it in mind that these things may change based on feedback. But our motivation there is we want to get these features out, because people will only tell us what they want from them. If they can actually start playing with them, and start using them. That's why we have the experimental status on it. Beth Griggs: I believe there is a difference between Node Fetch and Fetch. Certainly it's early days in the implementation in Node I'm seeing quite a few feature requests coming in from people saying, "Hey, this is supported in this package I use, could it be added to the Fetch API that's in Node?" But generally the motivation is Node saw value in having a Fetch API inbuilt, it was very much requested. They are trying to stick to the Fetch Spec, where it not completely, but where it aligns with Node. Some things in Spec may just not make sense in the concept of server side development, but in the places we can align with Spec, that's what they value and aim for. Paul: And so this is going to, if you're just a regular user of HTTP.1.1, probably this is going to cover the majority of use cases we can assume. Right. Okay. Very exciting. Beth Griggs: Yeah. Paul: All right. Beth Griggs: Yeah. That's the thing that's, to me it's best use case is so often I'm creating little proof of concepts or demo apps where I just need to get some data into my app and pause it. Having a very simple covering most minimal cases, API available by default. I think it will help quite a lot of developers, particularly if they're coming from the front end space conceptually, they will know roughly what a Fetch API should do. And they should be able to hop and pick it up a bit more, without having to learn "how would I do this in Node five years ago?" Paul: Do you ever worry that there're Nodes becoming a little too magic? I mean, this is a conversation you ask somebody that programs in Rust or Go, they're going to go, "Yes, of course it's too magic." But then you ask the majority of developers who are making really cool stuff, and it's like, "No, it's great." What's the perspective from yourself in the hot seat here on the iron throne. Do you get a lot of people asking for things and you're just like, "That's ridiculous! We're not even going to consider that." Beth Griggs: I think there's a mixture. And certainly in my experience, I've been in the project maybe about six years in total, varying levels involvement over the years. But I remember when I first started, there was a very big notion of, we need to keep Node as small as possible. It has to have the smallest core possible. We shouldn't add all of these extra features, even things like the Fetch API, because you can just npm install them from the ecosystem. Paul: It's kind of a keep it modular sort of... Beth Griggs: Yeah. Modular, way customizable run time. But now actually I have seen that change over the time, at least in the past five years. There seems to be more acceptance that actually having some of these things built into the run time is helpful. Like the Fetch API, and the test runner that's now bundled, because- Paul: Right. We should talk about that, it's certain... Beth Griggs: I think it's really good for the new comers to Node, because choosing which Node module to use is a whole challenge in itself and requires context of landscape. If people can just pick up Node, and for the first time they're building with it or where they don't need all these enhanced features or enhanced customization. If they can just pick up the run time that can make their life easier from learning, from even an enterprise you often have to verify all your dependencies, and get them vetted by your company, and get them approved. If you don't need to do that, because you can just have the run time approved and build things up from there. That's helpful in that case too. Paul: And we're getting to the, correct me if I'm wrong, but I feel like we're also getting to the area with computers, and personal, and devices where we can... You have more liberal space to have a bigger run time if that's what need be to make the ecosystem stronger. Is that something you guys consider? Beth Griggs: It's very much a trade off. In the project we have recently tried to define our technical priorities, and even tried to order them. And I think at the top is developer experience. We need to look at these things on a weighted basis. If people are coming in saying, "This API would have this many benefits. Yes, it has a cost." Those are the kind of decisions we're making. And we're adding things to improve the developer experience. I think that's our priority. Paul: You need the builders. It's this thing with the Web3 space, that's going on the projects that survive, the projects that have good developer experience where actually cool things are being built. I feel like everybody will vet that decision as a really good one just by natural selection now. We I'm just running down some of these things I wrote down, looking up at in the Node 18. I didn't know it was such an amazing update. As I said I'm mostly excited about the Fetch API, but we touched upon the testing suite that's coming through. I'm a huge fan. There's Mocha, there's all the Jest, there's awesome stuff out there. But tell me about the testing API, the unit testing stuff that's coming out, and what you think about it. Beth Griggs: And that's some great work done by Colin, who's also on the node technical steering committee, contributed a... It's experimental again. People should use it with it in mind that it may change slightly. There may be some breakages or breaking changes, but that will be based on the feedback we get. And again, it's a similar motivation, at least I see it is. For a lot of people when they're building very small prototype apps, which I think Node's perfect for, to get demos, proof of concepts running quick and easy, front ends backing some data. I think that's the perfect use case for node. A lot of the time though some of the only things in their package, Jason would be a test run, a test framework and a linter. We're looking at these things, thinking if everyone needs one of these, could we save a lot of these folks' effort by providing something minimal in Node core. It's not setting out to be a replacement for these fuller fledged test frameworks, which each have their place. Beth Griggs: But again, it's for the case where I think from newcomers coming to the language, would you have the knowledge to choose between Jest and Mocha for your project? I don't know. I don't think you could come to that decision until your project got complex enough that you need a specific feature from one of those, or you know what one would work better. While were providing a test runner that has a minimal interface, and covers the minimal set of requirements that you need just to test an API, or just to test. I think that's really helpful. It saves that decision making process until peoples applications maybe get a bit more complex, and they know what they need. They know what they need from a test runner. And then they can go out and find one that suits that need. Paul: So the role of this unit test framework is sort of all encompassing for people getting into the language, for people that just need to get testing done. Maybe when you get to the bigger enterprise projects, you're going to want to choose between a fully fledged framework like Mocha or Jest. Beth Griggs: Yeah, for sure. And if you're using building react type applications, maybe you would lean towards Jest or something like that. We want to provide something that's useful universally for a good set of people, but we're not setting out to like replace all of these great test frameworks that have all the customizations and the more fully fledged features. Paul: Gotcha. Okay. That, that's a good distinction to make. I wasn't sure if I should change all my Jest stuff over to the new one and try it out. Are there any features in this release coming out that you think are really cool, or novel that we didn't talk about so far? I know there are more, I know there are more, but I just wonder from your perspective. Beth Griggs: To be honest I think, to me, when I'm talking about the release the Fetch one's going to be so useful for so many people. And also the test runner, those are the two key ones I always tend to call out. Our release process is interesting because when we get to 18.0.0, a lot of the changes that were included in that initial Node 18 release are the breaking ones. Breaking changes aren't often the interesting ones. It's the sort of minor. The feature full releases that pick up all the new features, and we ship current releases every two weeks. Every two weeks you could be picking new features up with the current release line. Sometimes I feel there's an expectation that, "Hey, Node 18's come out with all of these new features." Beth Griggs: Some of the ones we talk about actually have been released in like 17.10 or the most recent 17 release, because we are shipping features every two weeks. It's an interesting, we get a lot of hype around the Node 18.0.0 release. But when you look at the breakdown, that the things that are queued up waiting to go into 18 are the things that have breaking changes or breaking consequences. They may not be as exciting, all of the other things that you see listed in that exact change log, but that's because we've been picking these features up. Paul: Right. I guess we could say all those other features that have been picking up, now it's putting the rubber stamp of approval. You're shipping the PR now. Beth Griggs: Yes. Paul: Okay. Speaker 3: Hey, this is Emily. One of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you, there would be no podcast. And because of that, it would really help if you could follow us on Apple Podcasts so we can continue to bring you conversations with great devs, like Evan You and Rich Harris. In return, we'll send you some awesome PodRocket stickers. So check out the show notes on this episode, and follow the link to claim your stickers as a small thanks for following us on Apple Podcast. All right. Back to the show. Paul: Is there anything that didn't get in there that you feel should have been in there? Beth Griggs: Yes, there was. I was preparing the release and up until... I tried to set a release freeze seven days before the release, and then four days before people opened to PR, "This cool new feature is going to hopefully make it in." And I was waiting to see if I had enough time to merge it in. One of those that just missed a cut was a pass arguments API. Typically, you'd use something, is it [inaudible 00:19:41] or something to pass command line arguments? Again, there's been a lot of work from a great group of people prototyping what a pass argument API would be in Node. And they opened a PR to actually get it merged into Node, with the view of hopefully getting it into 18 0.0., but just about missed it. Beth Griggs: But actually that should be in a new release in the next couple of weeks, probably in two weeks time. Because even though that feature missed 18 0.0., it's not breaking, it's something minor. We'll just ship it in like 18.3 or something like that. Again, that's a similar motivation. It's a simple command line argument passer, because that's very common action that people need to do in their programs. Shipping a minimal version of it by default helps folks out. Paul: Do you ever get angry people. People who say, "Listen my thing should have been in there, and Beth didn't let me. So I'm mad at Beth." Beth Griggs: Not so much. I think people are mostly quite respectful of the release of time. If a releaser says, "Look, I do not have the time to update the release on a Saturday," really builds. Part of that is we run a tool called Canary in the Goldmine, which is called... We shorten it to CITGM. On every release, we've got a hundred npm modules that we run their test suites for so that we can test whether we've broken the ecosystem. Paul: Wow. Beth Griggs: We've got the obvious things, like Express in there. And that takes like three hours- Paul: Right! Beth Griggs: ... To run. And then you've got freedom results. So it's like, yes you might say, "Hey, can we quickly squeeze this PR in?" But the consequence for the release is, we got to rerun all our release testing. We got to rerun all our smoke testing. We have to go through the results, rerun the builds. To me, people don't really get angry because normally the things can just wait until the next minor release, which will only... For the current will only be two weeks away. A few things have missed it, but they've normally missed it because consensus hasn't been reached, and the Node project does value having those discussions. Because we don't want to land things, revert them, break a bunch of folks because we haven't had those lengthy discussions. Paul: Talk about exhaustive when it comes to running your tests. You're really running a trick. You got to be sure. I mean, you really hold a lot of responsibility. I'd say the majority of the world runs off of this ecosystem in some part of the business, right. Do you ever feel nervous being in this position of actually going into the weeds with scissors, and cutting down the grass- Beth Griggs: Yeah. Paul: ... That's just an inch too tall, so the lawn looks nice. Beth Griggs: I remember the first time, we literally have a script that's like promote release and it's yes or no. And I remember the first time pressing yes on that, it was quite nerve-wracking. Our processes are pretty sturdy to the point where if something did go wrong, we know that we can revert, commit, do a follow up patch release. I'm confident enough. I know the path to resolving most of these things. The nervousness does come from having these discussions. And sometimes we're trying to guess the impact of what some of decisions we're making will be. But then we do have tooling that helps with that. Like that tool I mentioned, citgm where we test a bunch of a hundred most popular modules to see whether they are we're going to... Paul: Right. Beth Griggs: ... Break everyone. Paul: These discussions, who are the other people discussing? Do you guys sit around like a big round wooden table with pints of beer? How does that work? Beth Griggs: The Node project works on a consensus space model. Anyone in any PR could go in and say, "I have concerns. I'm going to block this." And we don't have to work through the resolution process. That is partly why we have a technical steering committee. And in general, in my experiences, we don't like things to fall onto the technical steering committee. It's an escape hatch for when consensus can't be reached among the community, the wider community, all of contributors, all of the collaborators. And actually I prefer consensus to be reached among those groups, because you're bringing in people with sometimes more context. For example, when the test runner core request having maintainers from some of the other test frameworks being involved in that discussion is very valuable. They can raise points that maybe that Node core folks haven't appreciated. Our pattern is, we're trying to reach consensus in a core request, or in a commit. Beth Griggs: If it really can't be reached, it will go to the technical steering committee. We meet weekly and talk about any PR'S being blocked because someone objects to them. Generally, we don't try to go to a vote and we will try to find a path to resolution. But if we can't, we do get to the point where we vote on an issue. And the TSE will say, "Who prefers option a or option B?" And the result of that vote will be what happens in the community. But we try to avoid that, actually we prefer consensus to be reached amongst- Paul: It's like a typical decentralized open source project, and you want it to function in that holistic way. Right? Right. Okay. Beth Griggs: Yeah. Yeah. And it can be great, but it can also be exhausting for some folks. Because your PR could span a massive discussion that takes a long time to work through. But I personally see that as a feature, particularly with the age of Node, and where it's at, and where it's being used. If something is controversial, we should have that discussion, and having that discussion to meet a feature of having so many people involved in the project. Paul: It's like a global vetting process on top of the technical steering. Beth Griggs: Yes. Paul: All right, got you. Now this might be a little not directly in line with just the V8 engine and stuff, but I just did a podcast recently talking about web assembly. Beth Griggs: Mm-hmm (affirmative). Paul: There's some really exciting stuff coming out there in browser databases, things that let you query really fast, things that let you stream really fast. I know there're streams, API update coming with this one. What's the way you guys view web assembly coming onto the block, and the role of Node.js working with web assembly or against it? Beth Griggs: I think generally, Node.js is seen as a complimentary technology with everything that's happening in web assembly. The Node project does have a library, the web... It has some web assembly system interface API's, so that you can load, and execute, and interact with your web assembly applications through Node. It is of interest to us. We think Node's in a good place to compliment everything that's happening in that space. Paul: Right on. Because the types of benefits that are coming with web assembly are... they're wild. The gentleman who was on the podcast, Andre, a few days ago he was saying, "The amount of speed up we're going to get with these dynamic front end applications and stuff. It just, you cannot not have it moving forward with the big amount of data coming out." It's great to hear that you're coming from a situation, or a perspective of we want to work together. We want to continue to make these complimentary technologies. Beth Griggs: I think there was also some discussions. I'm not sure where they led, around whether we could use web assembly within the call. Paul: Mm-hmm (affirmative), interesting. Beth Griggs: And to get some speed enhancements in those certain places where it makes sense. But I believe those discussions are still happening- Paul: Gotcha. Beth Griggs: ... Up to this point. Paul: Is there anything you think is too messy in Node right now? That maybe it didn't make it into the release, but it's on the roadmap of we want to clean this up or this API needs to be like changed very quickly because it's getting too updated. Beth Griggs: I think just generally, the Node project doesn't have a roadmap as such. We don't have a list of priorities or a list of features that we want to land. I think that fact in general can make it quite hard to follow what's next. Generally what lands in a release will be what folks have, or contributors, have invested effort in to contribute. They may be contributing because they're representing a need from a client they know. For example, at Red Hat, if we were speaking to lots of customers and they said, "This API would be really useful for us", we could then go and contribute that API. But then otherwise it could be, "I have an interest in creating something, and someone will just put PR and add something else." Not knowing exactly what features are coming up can be slightly confusing and slightly hard to untangle. Beth Griggs: We are trying to fix that slightly. We have kicked off the next 10 effort. And the next 10 effort was kicked off with a view of saying, "Node had a really successful first decade or so. What would Node need to have in the next 10 years to continue to have the success it's had in the past years, in the future years?" And in that group, we are getting together talking about features, technical priorities. When we have had mini summits, virtual summits, where we've had two or three hour sessions where we've talked about web assembly for example. We will have a web assembly session and ask ourselves, "What can we offer in Node to compliment this technology?" Or, "What do we need to do to stay even stay competitive?" We have competitors now. I think that's a great thing. There are other run times, innovations happening in other spaces. We can look to see what they're doing to see what our wider developer ecosystem wants. And if it's proved out enough and run times that it makes sense for Node, that's great because we know it's going to be valuable. Paul: Do you see that this conglomeration of all the packages that, or I want to say run time improvements that you're bringing in. Is this also motivated in any way by the security of the ecosystem? We had a show a few weeks ago talking about your source packages. And as you said, when you're an enterprise, you really want to make sure you're bringing in the right code from the right repos. And there was the Faker JS problem, and stuff like that. Is this in any way reactionary to this sort of move in the ecosystem. Or was it purely, "Oh, there're newcomers, it's convenience based. Do we want to improve the core API?" Beth Griggs: I think there's been, particularly in the context of security, I think every few months we get quite a high profile npm problem or attack that's happened in a high profile dependency. And I think there's actually been discussions in Node space for quite a few years about implementing policies on what you load, how you can verify dependencies. We've got folks from npm involved in the Node core project. They're obviously focused on improving some of these issues. I'd say most folks in the community are aware of these problems. We have some significant efforts around how we can improve the security, the security model and dependencies, lots of various efforts going on in different places. It is definitely played a part. Paul: Right. And there's a lot of new tech coming out to help play that part. That seems very interesting too. Beth Griggs: Mm-hmm (affirmative). Paul: There's this one visualization I saw where it shows all of your packages in one cube, and you can see how big they are by how big that little cube is, and how they're together. Never seen like that before. It gives me security thinking about I don't know where these packages are coming from and if I can pull in the Fetch API right there, you don't even have to get it. I don't care who's posting it, because it's right there. Beth Griggs: Yes. Paul: I think that's an unspoken really cool feature of bringing things into the run time. Beth Griggs: And it is interesting you mentioned that, because that's a key problem we're trying to tackle at Red Hat. And that's one of my more Red Hat fixes, to try and work through this problem of understanding your dependencies, understanding what makes sense to be used in a production enterprise grade environment. The way we've tackled that problem at Red Hat is we are trying to produce a reference architecture, where we have some internal guidelines of good defaults. For example, for a web framework in our preference architecture we say, "If you have no reason to use anything else, Red Hat clients, and Red Hat teams have had a lot of experience and success with using Express, here is a good default." Beth Griggs: It's it is not trying to say, "You must always use these exact tools to build your applications." But the way we are approaching that problem at Red Hat and the enterprise, is by looking at what experience we have within the org, what case studies we have, actual examples of applications that are running well and highly scalable. And we're saying, "What are they using, let's define those as good defaults," and going from it from that to try and solve a part of that problem. Paul: Have you heard of Socket.io? Beth Griggs: Briefly, yes. Briefly. Paul: It kind of what I was talking about with the cubes, which is I don't know, just the front end piece of that. But it does exactly what you're talking about. Which is, how is this package maintained? Who's been pushing to it? How much does it get downloaded? How many bugs are raised? And it gives you a quantitative you... That's really neat. I think it's a huge problem that's not tackled enough. Beth Griggs: Yeah. That's the slight difference. What we found is, a lot of modules on npm were maybe very popular five or 10 years ago, still getting millions and millions of downloads. But when you actually look into it, it may not be maintained. Its last release might have been three or four years ago. It might have security vulnerabilities. And the one of the key determinations, what we make at Red Hat of whether a module is good to build on top of, is how many contributors are there to it? Would you want to build an enterprise grade application, on a project that's controlled by one single individual? Would you rather build on top of a community owned framework that's got open governance? Beth Griggs: This is where the OpenJS Foundation, which is the foundation that Node sits in, is beneficial because you have a bunch of projects in there that are committed to having a neutral open governance foundation. When using these projects, you have some confidence that they're not just going to be controlled by like a single vendor, a single person, who could one day deprecate or they could make a change, and you may not have a say in that change. We tend to lean towards community own frameworks, where you've got lots of people from lots of different companies contributing much like Node itself. Paul: We're running up on time here, we're past the 30 minute mark. Before I ask you for links and shout outs and things you want to give, I have a specific request for a resource to mention. Where would a listener viewer go if they wanted to learn more about the system of governance that surrounds Node.js. There're a lot of foundations, and bodies, and groups of developers, and you can search up who is in charge of the release cycle. And you'll get a few answers, and will probably be pointed to the technical steering committee among other folks. Is there some place where you can kind of get a rundown about these are the parties involved, these are how things work. Beth Griggs: For Node. I think we have in our GitHub repository, I think we have a governance mark down file to try and describe some of that. But also you'd probably need to look at the Node.js technical steering committee repository, where we have our charter and our policies in there. And that describes some of the working groups that we have. We have this notion of working groups, where a working group has delegated responsibility for an area. The release working group has delegated responsibility, which means they own the release process. They own the release policies. They make the decisions in that space. But another place to look would be probably the Open JS Foundation's website, which is openjsf.org. That would describe more of what the foundation provides us as a home for the Node.js Project. Paul: So we will just say there's the governance markdown file. There's the open JS F- Beth Griggs: Yep. Paul: ... For foundation with the F at the end. Okay, great. And then the- Beth Griggs: Yep. Paul: ... technical steering committee... Beth Griggs: Mm-hmm (affirmative). Paul: ... Repo. Okay, awesome. Beth Griggs: Yep. Paul: And now your turn, is there any links you want to give, or any socials you'd want to post, or shout outs you would want to inform our viewers about? Beth Griggs: I think it'd be a great to advertise that the OpenJS Foundation is hosting its OpenJS World Conference in June, and it's going to be in Austin. And there's going to be lots of great talks there, and videos, and after the fact should be published on their channel. And there'll be a lot of people heavily involved in the OpenJS Foundation projects, talking there, talking about their projects. I think there's a keynote from Feross talking about Socket.io as well. Lots of interesting stuff to follow there. One of my key calls to action, whenever I'm talking about a release, is what is great is if while Node 18 is in its current phase. Beth Griggs: The six months from April to October to play with the release, and tell us if things have broken. Because if you're struggling to upgrade, it may have been a mistake, we may not have meant to make... That change might have been a side effect of something else that wasn't intentional. Give us feedback on the release, do it in the Node.js node repository, or the Node.js help repository even. Because that really helps us mature the run time, so it works for our end users. Paul: Okay, Beth. Well, thank you for your time. Thank you for coming on the podcast, educating me and everybody else about- Beth Griggs: You're welcome. Paul: ... Some of what's going on behind the curtain, and how you think and operate about this awesome ecosystem where we build awesome stuff. Thanks for coming on. We'll see you around. Beth Griggs: Thank you. Thanks for having me. Kate: Thanks for listening to PodRocket. You can find us at PodRocketpod on Twitter, and don't forget to subscribe, rate, and review on Apple Podcasts. Thanks.