 Hello everyone. We'll be talking with Michael here about Node.js, what's next, and mainly how can we catalyze the changes in a Node.js ecosystem, which is a big topic for everyone. I'm Jean-Biorlie, I'm working for Sanofi as a platform tech lead. I'm also a professor at Super Info. You can find me in multiple Node.js community, like mainly the next 10, but also performance group, for example, and also in some other open source project. You can find me on Twitter, Gita, Blinding, like basic stuff for everyone. And Michael. Hi, thanks. I'm Michael Dawson. I'm the Node.js lead for Red Hat and IBM. What that means is I get to spend a lot of time in the Node.js community. I'm a collaborator of one of the technical steering committee members and active in a lot of the different working groups. And the next 10 is one of the ones that we'll talk to about a lot of the activities today. I'm also working with the Open.js Foundation. If you were here for the talk to kick us off today, a lot of that work. And as well as getting to work with a lot of great teams within Red Hat and IBM who have large Node deployments and working with our customers and consultants who do that kind of work. So just before we get started, I'm going to tell you a little bit about our agenda. So first we're going to start out about how do you follow what's next? It's great for us to give you a bit of an update of what's new and next now. But maybe you want to follow that along yourself. So we're going to give you some hints on how to do that. We'll jump into some recent features. People are always interested in what's new and next on that front. John will take us through the next 10 and some of its initiatives for figuring out how we make sure that Node is successful for the next 10 years. I'll jump back and sort of give you some insight into some of the new teams that have been formed recently and some of the interesting work that they're doing. And finally, John will take it back on how to get involved and participate in the project. So first one, what's next? It's a big question because when you are working with every open source project, not just, but even in a company project, if you have a lot of repository, it's quite hard to follow everything. So first one for us, we want to go through some main topics that are really interesting for everyone to follow. First one would be our release. So if you are not aware, we just released a few weeks ago, Node 20 in April. So that will become a new LTS in a few months. We also have some ongoing and interesting news, Node.js 14 LTS support ended in April. So this month, so please update to Node 16 if you want, but Node 18 will be way better as Node 16 support will end in September for multiple like reasons. One of the main one would be OpenSSL, but Michael will be talking about that a bit more in a few minutes. So yeah, let's all upgrade, keep our system safe and fast. One topic also is when we release a new version, could be every version, we do provide also a changelog. That's a good way to know what's new, what's a big change, if it's a major change, breaking change, or minor change. So and you will find that on Node.js repository, it's also like always linked to the article, people publish it also, the link on Twitter and everywhere. So like it's quite important to have a big overview on what's new inside a new version. One key topic is we are all working with GitHub. That's great. You can have full notification and you can know everything, but it's quite easy to like wake up a morning with 300, 400 notification, and maybe you don't want to go through everything, but yet you don't want to miss specific topic, subject or information. And for that, there is multiple way, I think, and we worked on that with an extension to also provide to everyone into the community as a broad a way to follow what's new initiative or new evolution. The first one would be just joining us in every meeting that can be held by the teams. So we meet every, like every day you can find a meeting about a specific team doing work on some specific career from the release group, from the next 10 security or pretty much everything. So you can join us in this meeting, but you can also follow us or watch the meeting on YouTube and or just also check the news, I guess. One also key topic is our current main initiative. We do have multiple one. I won't go through everyone, but what is really interesting is some of them are linked to what we were able to discover when talking to the community, like improving in performance, like having a single executable application, so a way to build Node.js as a single app. And you also have always useful HTTP 3 core from my API and some other stuff. And finally, Michael, what's new? Okay. So yeah, so I'm going to start to talk and tell you a little bit about the recent features because people are always interested in that. Before I do that, though, I got to sort of step back and say, unlike proprietary software where of new release, a new major release, people batch up features and you have to sort of upgrade to get advantage of that. The project's approach is really to flow new features back into old LTS version. So most of the time, by the time we have a new major release, all those features are already in earlier LTS releases. And in fact, this year, we had like an LTS release of 19 basically the week before 21 out. So if I just said what's new in the latest release, there wouldn't really be very much to talk about. In our major releases, you know, we do, we just, you know, things that are Sember major are restricted to those releases, but we work hard to make sure that we do things which are the least breaking. So really, I say major releases are boring. And Sember minor is where it's at because of the way the features flow into those previous releases. Majors are still a good time to party though. It's a great time to talk about all the great progress we're making. It also means that maybe, you know, the release that went out, which is like 20 will be promoted to LTS in September. So maybe that's the time where you're going to get a supported version with the features that you're going to talk about. So I've really categorized the features into old news, baking, and latest greatest news, not necessarily tied to any particular release. So in terms of old news, I think two things were important, open SSL and default DNS resolution that I'm going to tell you a bit more about. As Jean mentioned, you know, open SSL, in one of the reasons not to upgrade to 16 now and go straight to 18 is because we had to shorten the lifespan of 16 because open SSL 1.1, which is what's in 16 goes out of service in September. And so one of the big changes in 18 is that it has open SSL 3. And that's something which, you know, it's kind of old news at this point, but I think it's important because if a lot of people are going to be moving up to 18, it's good to be aware that there's a big change in the open SSL side should be mostly compatible. But like any time when you're moving up on, you know, security related components, they're starting to no longer support smaller key sizes, they're removing legacy algorithms. So depending on what your application relies on, it's good to do some additional testing, maybe plan for some extra time to be able to tweak those kinds of things. If you're using native modules, there's also a bunch of functions which are now deprecated. They're still there, they'll still work, but you might see a bunch more warnings. So if you're learning where that's coming from, that's due to that change as well. The other one is default DNS resolution. You know, we've all been using IPv4 for a long time, and IPv6 has been working to sort of take more and more space. For a long time, no defaulted to using IPv4 addresses, even if the DNS servers that we talked to said like, hey, here's both IPv4 and IPv6. And if they gave us the IPv6 first, we would still give you the IPv4 ones, but we've switched that because it's basically it's time to start respecting what the DNS server is taking us. Unfortunately, it's really easy to configure a machine that thinks it has IPv6, but it can't actually communicate. And so I've got a system that happens to me all the time at work, where it just doesn't connect. So it's important to know this change happened. And like there's an easy fix you can you can flip back to this command line option I have here dash dash DNS result order. And you can say, you know, use IPv4. But you may run into this as you move up to 18. And we are doing work like in the project, there's a standard called happy eyeballs, which is supposed to give you a better fallback. And you know, we're working on trying to bring things like that in in as well. So that's kind of the old news. The next thing, let's look at features, new features, and we'll talk about not all the new features, but some of the ones you know, we think are the most interesting, which include fetch, wazzy and dash dash watch. And these are ones which are basically, you know, baking, they might be actually stable by the time we get to 20 becoming LTS in September. That's one of the interesting things of our approach and that features flow and get backported. So they're not stable now, but we may make them stable. And so they may be part of your LTS release. Fetch if everybody isn't aware is basically a fairly high level API for getting content from a URL. A while back in our next 10 effort, one of the things John will mention is we did a number of deep dives, one of them was on HTTP. We agreed we should have a high level HTTP API or lower level HTTP API, which actually isn't the one we currently have in in node itself. But we agreed the higher level API should be fetched and it's now in. And although it's still experimental, you know, it's something that you can use. We get lots of feedback. It's either two spec compliant or it's not spec compliant enough, depending on who you are. We're trying to write the sort of walk that fine line between what makes sense in a back end server runtime versus a web browser. And it's not exactly the same as what's, you know, what you'd see in the browser. The other thing you'll note on some of these, I won't mention them in each time. But like in this one, you can see here, you know, our technical priority. That's one of the things John will tell you about in terms of us, you know, the next 10 put together a set of technical priorities. And it's really nice to see that a lot of the new features that we have that we're talking about are supporting those technical priorities. And I've sort of tagged those on the lower level. Web assembly system interface. This is actually one where you can say, well, wait a sec, that was added quite a while back in 13 and 12. It's related to Web assembly. Web assembly is a new technology that you've probably heard a lot about. There's a lot of press about that today. Node is actually a decent runtime. It gets its implementation through V8. And Wazzy is an interface that lets you interact with the outside world as opposed to just doing computation and stuff like that. There are a few new changes in 20. We actually added in the requirement for a version when you create your Wazzy instance. That's because, you know, there's work on newer versions. So we implement preview one, but there's a preview two, and there'll be, you know, future versions. And we didn't think that having a default, like all the code default to a version which may become deprecated made sense. So we want people to actually opt into a specific one. The other thing that's new in 20 is that you don't need a command line flag. And that's sort of like one step towards us making this stable. You'll see that, you know, we usually start experimental with flag, then we remove the flag and so forth. Watch, watch, dash, dash, watch is a is a is another feature. It basically lets you watch your application components. That's good for like, if you're doing the inner loop as a developer, and you want to make a change, it will automatically restart node for you. And so that you can avoid that step of like, stop, change, start, and you can watch file or directory and so forth. It can be only on Mac and Windows, but I think that's actually where a lot of people do their development anyway. So now we'll flip over to features which are hot off the press. We have the argument parser, which is in 20. And you'll actually see there's a number of these was sort of support the technical value of developer experience. We started to pull a little bit more into node core itself, not necessarily replacements for a full featured argument parser, but enough that like a lot of the time, maybe the 80% case, it's enough for what you need. And you don't have to pull in extra packages, which always add extra extra sort of complications, security concerns and stuff like that. So it provides a higher level API versus just, you know, in node, you could always get the arguments that were passed. But this provides you a parser, which will take those arguments and give you an object that actually has the data that were part of those parameters. Nice thing is we had collaboration from the yards and commander maintainers. Those are two leading packages for parsing arguments. And so we got the benefit of a lot of their experience pulled into what actually landed in core. This shows you just a simple piece of code where you can go in, you can say like, okay, my arguments can be dash F, which is a Boolean, I can have dash dash bar, which takes a value. And I can sort of define what the parameters are. And then the code to say, just parser converts that definition, as well as your arguments into an object that we see here on the right, where it just says, like, Hey, I got food, the value was true. And, you know, the value for bar with B. So something where you can easily pull in those, those arguments. There's also been a bunch of work on a test runner. So it's stable in 20, not all of the components of the test runner are stable, but the core test runner itself became stable in 20. You can see that things like mocks reporters and coverage. So things have been added and a good stream of work going into that. And again, it's not meant to be your full featured test runner replacing just and mocha and all those other things. But a nice core set of functionality that if you've got fairly simple needs, you can use a test runner again without having to have another package. This shows how simple it is to just basically, you know, require a test and require a cert and write a very simple test. And what I like on on the shown on the front on the other side is that it uses tap output. Tap is sort of a format long used for test output. We use it in the node project, fairly human readable, but there's also lots of packages and stuff that you can use to parse that output, convert it to other things. So, you know, a nice, a nice solid addition in terms of being able to do testing with overhead. Single executable applications. The next one, it's was added as experimental in 19. That's a good example of like just before our major release, it made it back into one of the earlier things. The wins on that front is it lets you distribute your application more easily instead of having to have node installed separately. You can actually bundle your application into the node binary itself. And the other thing that was pointed out to me that I didn't initially realize is, but that's also good for surface area in that you can distribute something that uses node without exposing all of the node APIs on your system. So, if you have a container with your single application and you bundle it into node, it'll run JavaScript for your application, but not necessarily give that larger attack surface. It works by bundling your application into a segment into the application into the node binary. So, the binaries you download from the Node.js.org website. When we start up, we now say, hey, is there a segment like this? If so, we're going to find the code and load it. We've taken care of performance through something called a fuse, which basically is just a single check. You have to sort of flip the binary into single binary single executable application mode. Otherwise, we don't do any of those checks. And it starts up just like it did before. There's a separate project called post-check, which actually does the injection. And you can read more about that in the link that I have there. The next one is process based permissions. So, you know, in other competing runtimes, it may be a lot of sort of fast side say about having restrictions on starting on being able on having your application be able to do things like read files and stuff like that. That's actually a really hard problem to do right and to do in a way that's actually very useful. But as a project, we agreed that, like, we want to help people experiment and figure out how to use that effectively. And the best way is to actually have a feature that people can use. So that's included. It lets you limit read and write file access. And it'll disable some things which would commonly allow you to circumvent the protections like spawning a new process, using worker threads and so forth like that. Tracing channels, another feature. So diagnostics is a very important thing for anybody running things in production. APMs in particular want to be able to pull data out and provide that to their customers. And so the project's been working on something called diagnostic channel for quite a long time. But we really want packages. So if you're writing your own package, we want those package owners and maintainers to provide a feed of information that can be used by the whoever's interested in diagnostic information. The tracing channel does that. It simplifies the, you could do it with the base diagnostic channel, but the tracing channel simplifies use of that by providing an API that lets you easily generate events for asynchronous calls, synchronous calls, and to catch errors and stuff like that. And there's also some APIs to be able to consume that information as well. So this is, as an example, shows you how I've kind of combined the consumer and the generator in one piece of code. You wouldn't necessarily do that in real life, but you have your imports. Then the consumer subscribes, so it can subscribe to events. I haven't subscribed to all the events, but in this case, I've got a synchronous method. So I subscribe to start, end, and error. And then on the info source side, I can generate information around a particular method. And so I just do that, trace, think, and you can see down below I get my start, the output from the function, and then the end. And I'm not much to say about this, but ARM has become more and more popular. We already had ARM for Linux. People want to run Windows on ARM, and so it's nice to see that in our recent releases, we have support for Windows on ARM. And at this point, I'm going to hand it back to Jean to tell us more about Next 10, sort of forward-looking things. So yeah, so the Next 10 is an initiative that we created in more real, like three years ago, four years ago, almost now. And basically it was celebrating the 10 years of Node.js, and what we can do and what we should do to have the same success for the Next 10 years. And then the Next 10 years, I guess. So we drive and we were thinking about at least to build this Next 10 initiative, about around three different kinds of main property or foundation for us. First one would be the technical value and priorities, constituency and constituency needs. So this is the core part of the Next 10. I won't go through everything. Everything is in a Node.js repository, or some part of them are also inside a Next 10 repository. If you want to read about everything, please feel free to also comment if you have other ideas, and we'll come back on that. But our main technical value and priorities, like you saw on the previous slide, like Michael on the bottom, like right or left side of the slide, each time he was talking or presenting a new feature, we tried to link that to one of our technical priorities. One of the first one is developer experience. That's why we try to move a lot faster, let's say in this kind of area, like providing a partial hug or anything else to allow you to just be, for everyone to have an easy way to not use maybe external library when you don't really need it or to be faster on implementing stuff. Stability is also quite important for us, for example. The second part would be everything about constituency, because you have a lot of people that use Node.js, could be from a lot of areas, and it did not necessarily mean that everyone want the same thing for the ecosystem or for using Node.js. We have a full list of constituency from developer, from people like contributor, Node.js contributor, to security expert. But also one that is quite nice is, and we did forget about this one at first, during almost more than a year, I guess. I'm a professor for a long time now, and we completely forget about the education part. Basically, we were like, great. Everyone is using Node.js, but how do we want to teach Node.js to people or to have people using Node.js and just coming to the ecosystem or learning about the technology? We added that one not that far ago, which would be for teacher, for student, for everyone that wants to learn Node.js. Education is also one of the key parts of our constituency. The last one would be the need of those people. We have a big matrix with a lot of things inside. Same, I won't go through, I think it's more than 20 or 30 lines in total. I won't go through everything, but I think some of them are nice at least to pinpoint right now. One of the two main areas where people are really involved and want to know more would be to have a good understanding of the direction of the project. Basically, what's coming in the next six months, year or more. It's always useful for everyone to know about it. Another one, for example, would be to provide a good way, but it's also for example, to education. To have API and documentation being up to date, easy to read, easy to find. That's something that is core to the system. I will talk about this one a bit later also. Yes, quite a lot of stuff. One of the last ones is about how to build Node.js into some kind of executable stuff. We discover that with the next 10 before the initiative. It's what led the initiative, the SEA initiative to be created and to have people being involved. We also have a full list of technical priorities, which if you are using, and I guess you are all using Node.js here, it's something we try to derive and to discuss with the community every time we meet and everything. How can we improve HTTP? How can we have type, better documentation, web assembly, ESM, observability? Quite a lot of stuff. One way for you and for everyone to collaborate is we try to have what we call mini-submit but also call our better submit, so it could be online for most of them. And from time to time, when we are able to gather all two events like that, to be able to discuss about one or two specific subjects that we really want to have a deep dive. In the past two years, we did multiple submit about types. It's quite important for everyone now. Also, single executable application, HTTP documentation, like a lot of stuff. And we were also able to discuss about new technology or ideas that people want to drive or new need for the community. We also prepared new mini-submit that will happen at least one around this summer, would be mostly the one about serverless. Serverless is one of the core technology today and really used with JavaScript. So we want to dive on this one and to have people being involved in both all the community to just give us insight what's needed, how we can improve Node.js and everything. We also discuss about HTTP. It's still something that needs to improve and evolve. And also to focus on typescript or hooks or how can we bring some easy way to link typescript when you are doing Node.js. And another initiative is just being able to gather feedback from the community. So we sent a survey three weeks ago. It lasted until like five days ago, I think something like that, to have a feedback from the community about, I think it was 15 questions, something like that, maybe a bit more, to have a feedback. So we got a lot of feedback, like $17,000 would be great for $17,000. So great feedback from the community with new ID or new topic that we want to work on and what the community needs. Which gave us, I won't go through every result, but everything will be posted inside the next 10 repository with feedback and we will also discuss in the next meeting for the next 10 about every data we were able to collect and to just gather the feedback from the community. But like you can see modern HTTP is really like HTTP, ECMAScript feature, documentation are key parts that everyone wants and we need to work on that. Same for also a lot of result link to API documentation, like you can see it's almost the same between different parts of the community. And finally, one key initiative that we're currently leading and Claudio, I think is not in the room anymore, is a documentation proposal to try to improve the current documentation with to other people, both maintainer but also person and user of Node.js to be able to search way easier to find information, to provide more content also. And I think if you want to learn a lot more about that, could be great to talk to Claudio is really leading this initiative for everyone. So that's pretty good. And also one of the key point for you to be able to follow everything, we had the first like first two slides of the presentation, I was talking about it could be hard to follow everything. We with the next 10, we are also able to push a discussion and to have multiple group teams to work on a solution to share big news for the project. So you will be able soon to just go see your main or some specific teams and just to have a quick summary of what the big initiative that are ongoing, the big success, something like that. So we'll be waiting for everyone to have good news. And I think it's your turn to talk about teams. Now that we know a little bit more about the next 10, I'm going to talk a little bit about sort of what's new on the teams and initiatives. That's a great way to follow what's going on to get involved in the teams or just listen into what they're doing. All the meetings are streamed and live. The project's very transparent. So that's a great way to get involved. So I mentioned single executable applications earlier. That was something that came out of one of the next 10 deep guys, but now there's an active team who's actually working on that. They're tweaking how you actually generate the the blobs that you inject in. I find it really interesting as well that we're starting to see additional use cases versus just packaging and shipping applications that are being proposed for SEA. For example, if you want a node binary that incorporates some default parameters, that's one way that we may be able to do that and support that. And really a big thanks to Darshan and Joyi who are leading the work of that team. And so if you're interested, that's a great team for you to get involved in. The next one I want you to mention is security. We received funding from the OSSF last year and it was renewed for this year. What's been really, really great about that is that it's provided critical mass. We have somebody who's basically, it's their job to look at security. Help us with the day-to-day stuff like vulnerability fixes, triage and all that. But just as important, helping us look at our security stance, our processes in sort of the bigger picture and how do we improve those and make things better at the sort of process and organizational level. Some great initiatives that are taking place right now as we're working on implementing the OSSF score cards, there's been work on automating dependencies. So instead of having somebody have to go through a bunch of manual steps and for example, we already talked about OpenSSL, but there's a good number of steps to pre-generate files, commit them. They make PRs which are really like unreviewable because there's like 500 files or something like that. So it's much better to have that automated. We know that the automation does what we tell it to do, maybe right or wrong, but like after a while we know that it's good. So it improves security I think from that perspective. We're also hoping to apply automation to things like the security releases. We have a very well-defined security release process, 26 steps. It'd be nice if somebody didn't have to do all 26 steps and sort of speed that along. We mentioned the permission model. There's also continued work on the permission model as well. So that's a good team. If you have an interest in security and you like Node, that's a good place to get involved. Lots of stuff going on. I do have a talk tomorrow at 6.05. I know it's a little bit late, but in the secure supply chain contract that we'll go into more detail on the work of the security group and all the things that have been going on there along with Paula Paul who's sitting in for Raphael who couldn't make the conference and he's the one who's been driving a lot of the work there. So a big thanks to Raphael on that front. The next team is performance over the last six months. There's been a real sort of I'd say increase in the focus on performance. A big thank to I guess who's really been driving that. He's organized the performance team and we've seen improvements in things like URL fetch event target. Ada's a new dependency that's been added to speed up URL parsing. So if you have a passion for performance, that's a great team to get involved in and is really new and ramping up and has got lots of energy. And then the last one I'm going to mention is UV Wazi. UV Wazi is the Wazi implementation within Node, but it's also used in other runtimes like Rain. And so if you're interested in Wazi, Wazm, I found it a really good opportunity being involved there to learn about Wazm. We have some people who are working in the sort of Wazm Wazi community and bringing their knowledge. And it's a great learning opportunity to learn about what's coming in Preview 2 and also what's needed to help make and continue to make Node a really good platform for running your Wazm. Some of the current focuses are rounding out the socket function. So Preview 1 includes socket functions, but a lot of the runtimes don't implement it. That's something we want to include. Thinking and learning about Preview 2 may require some API changes and stuff. So there's a bunch of work and discussion there. And then also there's there's a desire to make UV Wazi more easily buildable as a shared library. So it can be used other places as well. So those are the sort of new and interesting teams I wanted to highlight. So I'll give it back to Jean on how you can get involved in general. Yes. So like you can see, we did a lot of work, but there is still plenty to do. So how can you participate? So first of all, you are all more than welcome to join us in any kind of way, time that you want to spend with us. Like Michael said, different topics could be performance, could be security, could be next 10, could be specific, maybe HTTP or any other key part of the technology. You can for that you can just join us during meetings. So like I said at the start, you can join us online just to discuss with us about specific carrier topic. You can also open issue on GitHub. You can help us on the documentation. We'll have like more and more like work to have on the documentation part on a lot of carrier. So feel free to come and join us. You can also just talk to us through being here or online, Twitter or any kind of shape of way that you think it could be great for the ecosystem or just to discuss about new, new topic that you want to bring further in time and how we can improve or help everyone to succeed using Node.js for the next 10 years. And I think we're good. Yeah, it's okay. So at this point, I think we still have a few minutes for questions. If anybody hasn't, okay. Well, I think the one I said was Windows and Mac was the It was a dash, dash watch was the watch feature. Yeah. So no, it supports Linux as well. Yes. So, you know, Linux, Windows, macOS are all supported for the for the single execute applications. I think testing is a little bit thinner on some of the different variants, like in the Node project, we have a lot of different architectures and a lot of different operating systems like AI acts and stuff. So I don't think we we haven't necessarily got testing working across all of those, but the core, you know, Linux and Windows and Mac for sure. Yeah. Any other questions? All good. Okay, well, thanks. Thank you very much. Yeah, thanks for coming. And see you around.