 Hi everyone. Great. Everything working fine. That's cool. Thanks for being here first, and to listen to our talk about Node.js, what's next, and how we can like working and catalyzing change in a Node.js ecosystem. And we will be, as you can see, two to present that to you. So I'm Jean Biorlie. I'm working at Sanofi, leading the platform team there. I'm also working for 3.4, which is a French university as a professor there. And you can find me on multiple parts of the Node.js ecosystem, mainly the next 10 community, the example one also. And I'm also part of some other open source project mostly around JavaScript. You can follow me on Twitter or X, I don't know, GitHub, also pretty much everything. And with me, Michael. Hello, yeah. 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 community, which is great, working with the collaborators, a bunch of the working groups and teams, and just generally active across the project. I also get to be involved in the Open.js Foundation, as well as working with a bunch of great teams within Red Hat and IBM who either deploy Node.js at scale, help our customers do that, or build tools to make it easier for you to be able to deploy Node.js in your production deployments. So just before we get started, I'm going to tell you a little bit about what we're going to try and cover today, so you have an idea of what we're going to go through. First of all, we're going to talk about how do you follow what's next. It's great that we're going to give you a little bit of an insight into what's new and next today, but we want to give you some tools to be able to follow that and figure that out yourself if you want to during, across the year. We'll then jump into some recent features. Everybody likes to know about what's new in Node itself, so we'll talk about some features. We'll then talk about the next 10 team where we try and look more proactively in terms of what we should be doing to ensure success in Node for the next 10 years. We're going to go over a few of the new teams and initiatives that we think are particularly interested in, and then finally we'll end up with a little bit of like how could you get involved if you want to to help out and move things forward. So back over to Jean. So first part, it's really hard to follow everything that could be happening inside the full Node.js ecosystem just by itself. I think there is something around 200 repository just own and link to Node.js. So that's a lot of work. And there's a lot of things also that you need to follow from. But the main point I think that is really important to all of us, especially I guess this week would be how to follow releases and what's new in the Node.js ecosystem, new feature or release. So first big announcement. So the version 27 I think was released just yesterday by Ulysses. So congrats to him and because it was an amazing work. And then 20 branch will go LTS in less than a month, like three weeks if I'm right. And also one of the good news and really important news at least is Node 16 like move to end of life and Node 18 should be the one that you should be using at least like in production or anything and or 20 like in a few weeks. And next month we will also release a new branch for the 21 version to try, test and experiment new stuff on that which is quite important. So quick remember like quick information please update. Don't use Node 16 anymore move to 18 or 20. That would be great. Also also some specific point. So one way to follow what's happening and what's new in a new version would be our change log. It can be quite hard for some people to read. So but at least everything is like easily to it let's say more or less easy to display you will have see and be able to see like notable change what's new what's coming what's breaking change or not. So this is a good way to follow what's everything being updated on everything. Another way would be to follow GitHub notification and your inbox in GitHub. This can depend where if you follow a lot of different repository or not. I was just checking like five minutes ago in less than a week I have more than 1000 inbox messages. So could be quite hard to follow on everything. But this could be a good way if you want to play also with filter and everything. One good point for everyone and I know a lot of people are not aware of that but you can all join us for meetings so we are like weekly or even daily on multiple topics. Working group sessions that are live you can just check everything on YouTube is being recorded and available on YouTube or you can just join us. You will find a full calendar at this address not just dot org slash calendar and as you can see you will have like meeting about multiple topic from next end to TSC meeting that you can follow to not API to pretty much everything. So please if you are interested to work or to provide some feedback about Node.js how you use it join us and just share what you know and your love for Node.js. Also some specific key initiative part of the project so there is more but this is a small list of that from working on performances to single executable to compromise a lot of people and a lot of people that are championing this initiative so that's pretty cool. And now that we spoke quickly about the key initiative Michael we'll talk to you about what's new in the ecosystem and the recent feature that we delivered. Okay so yeah everybody's interested in what's new but I always like to say major releases are boring unlike a proprietary product where they basically like control all the release the new features and bundle them into something that makes a really good press release. Node.js in particular works to flow those back into earlier releases so features by the time we do a major release a lot of the features are already in the previous LTS's and so you know that coupled with the fact that we really try and minimize things that are going to be breaking and so what you end up with in major releases are just things that we were very cautious usually about you know they may break some edge cases or something like that but they can be boring. Simverminer is where it's at so all those features which are Simverminer they get landed of course in the mainstream but then flow backwards that's where the real interest is but I think majors are still a really good time to sort of celebrate and talk about the new features that we've gotten over for the last little while especially you know in the context of promotion to LTS the next LTS is being promoted in October and maybe that's the first time that you can try out some of these new features in an LTS because you know even if they've flown back to an earlier release it may have just been one of the currents so I'm going to talk about the features in sort of three ways as opposed to like hey what's new in the latest LTS it's sort of old news but things that I think are particularly important for you to know about as you move up say when you plan your migration to 18.x from version things that are baking you know they've been they've been worked on for a while and they're making progress and but maybe they're not stable yet and then finally it's sort of the latest greatest news which are things which have been released in in sort of very more recent times. The first one is OpenSSL so we upgraded from OpenSSL 1.1.1 to version 3 and that did come in 17 so that was a little while ago but 18 is the first LTS that some where some people may be sort of running into that so it's I think important to measure to mention it's meant to be backwards compatible but like any sort of future or new versions of things related to crypto they're always tightening down what they consider secure algorithms or secure key lengths so that's something to think about when you move up and maybe plan a little bit more time because you may find that like an algorithm your application was using is no longer supported or you have to move to larger keys so that's certainly one one aspect to think about the other thing is native modules so there's a bunch of methods that were deprecated so they're not you know your your native add-ons may still compile but you might get more deprecation warnings and maybe it's a good time to start thinking about moving up to the newer API so that when it they finally are removed you don't run into a problem. There's a great guide on migration so if you're as part of planning your your move up to 18 it's probably a good idea to read through that and figure out if anything's going to be affecting you. The next thing is the default DNS resolution so we probably all know that IPv6 is something that's been worked on for quite a long time in the overall ecosystem pretty slow transition I think overall and up until this point Node basically said well regardless of the way that the DNS server gives me the addresses I'll give you the IPv4 ones first which typically meant that would be what you use to connect we decided it was time to start respecting what the DNS servers tell us so if they give us a list and the IPv6 ones are first we're going to leave it that way the challenge that we see people running into and this happens to me actually all the time we have a machine that's configured to so it it thinks it's got IPv6 but it's really not configured well enough to actually connect out so it sees that it gets an IPv6 address it tries to make the connection it can't basically you know I try and do an npm install and it just hangs not any real problem in Node but there's enough machines out there that you might run into it the good news is is that there's a command line that's kind of why I wanted to you know tell you all about this if you run into something like that you can just add the the dash dash DNS result order equals IPv4 to flip back to the way it was and you can do that through Node options to fairly easily get back to where you were the next set of features are the ones that are kind of baking and these include fetch, wazzy and and dash dash watts I don't know that any of those will become stable in the next LTS promotion or in 21 but there is some discussion around some of them so that's a possibility so fetch was sort of a long discussed and at one point we had a next 10 deep dive which and John will tell you a little bit more about those deep dives well we had a deep dive where we agreed we kind of wanted to move to the point where we had a very high level API for doing HTTP and then a more lower level one that would give you more things where you could tune performance and and and do more things as part of that we agreed fetch which was a web API was the right way to provide the higher level API and node node itself and this just shows the code that you know it allows you to very easily without much fuss pull in the content of a URL you'll also see down here Jean will talk about some of the different technical priorities that the next 10 has worked on and on some of the slides I've got like okay this is actually in line with our technical priority that modern HTTP is something that's important that the project should be working on and you can see this is one of the things where we're making progress on that front the next one is wazzy you may have heard a lot about what web assembly there's quite a lot of sort of buzz and interest about that node can run web assembly through our because we use v8 and we have an experimental implementation of wazzy wasm is great as long as you don't need to actually do anything outside with the outside world wazzy lets you connect to the outside world through the file system through sockets and so there's a a experimental implementation that lets you launch your wasm with a wazzy environment and lets you get access to some of those things still really a work in progress but I think one where you know if you need a runtime and you're already using node and you want to use wasm you know it's a great thing to consider working working with we did make some changes in 20 where the version used to be just default you now need to actually specify preview one if you don't you're going to get an error we decided that that made sense because we didn't you know there's a the ecosystem wasm ecosystem is working on a preview two and there'll be a preview three and we didn't want to always default to something which would be out of sort of out of life and so we want to actually make people force forcefully or we want to force them to actually opt into a particular one the other thing that changed is that you no longer need a command line flag to turn on and use wazzy so sort of one step along the progress still I think a ways to go but it's a step along the the process from you know a new feature to becoming stable watch is one again again in line with the developer experience where if you're in that inner loop where you're you know basically making changes you may want to make a change restart your restart node and this allows you to do it more efficiently there's a number of command line options that basically let you watch a file the file that you're starting like you know it's like node index.ts or something or a directory and anytime there's changes in those it will automatically restart for you so just helping you do things more quickly that is sort of interesting one in that you'll see a number of the features that that I'm talking about today are kind of in the we're going to give you a little bit of something you could do through a package so there are already packages which would let you watch and do restarts but there has been a trend to pull in some basic functionality in different areas so that you don't have to find and install as many packages when you're working with node not necessarily replace those packages but give you the basic functionality so like you know maybe 80% of the people that's going to be good enough in terms of features now sort of hot off the press we had a number of them ranging from like argument parser or a test runner those are ones that are in that sort of model again of having a little bit more functionality support for single executable applications a permission model diagnostic channel and support for arm64 so the argument parser again it's like you know not meant to replace yargs or commander and the good thing is we really had a lot of collaboration from the existing maintainers of those packages and they were in support of pulling this in so we got the benefit of their experience and their expertise and it gives you a high-level API for actually doing some basic basic argument parsing here's the code where basically you know you can set up through that const options is like what are the options which I expect to come in I can easily parse those args and I get back you know basically the an object which has the parsed arguments letting you do you know get your arguments in with a lot less code than you might otherwise have to do or pulling in other packages a test runner was moved to 20 stable in 20s that was kind of the big headline you can see through you know the addition of mocks reporters and coverage there's been ongoing progress this is a really good example of there's not really any big bang other than it going stable because the functionality has been slowly being added and being flowed back into the LTS releases as well but it gives you a test runner where you can easily write a test just through a few requires in the node namespace I like it because it uses tap output which is well known something that I've been familiar with on a number of projects there's tools for parsing it and you know you can very easily say I just want to create a test and I want to assert that something is true or not true single executable applications so there's often a case where you want to write an application that's just like a single binary as opposed to hey install node first then run these scripts you'd rather just package it up as like one executable people can run the single executable feature lets you do that it actually bundles your javascript code into the executable itself the ones that are available on the the main download site it uses a fuse so that like without having done the bundling it takes zero overhead because we check this fuse which is just a you know some a location that's in memory that you've loaded in from the application if it's not set we know as okay no no bundle application just do the regular thing otherwise it looks for a segment within the executable finds the code and runs the code it also has some interesting aspects in terms of security in that you end up with an exe which wallet can run node applications when you run it it only runs the script that you've given it and sort of can so that can be you know it's something people have mentioned to be as interesting and that it reduces the surface area you're not saying install node that can now run any kind of script you're saying install this binary that just runs my one application so in addition to helping with the easier distribution it also helps with that reduced surface area and that's kind of an interesting one again still experimental but being worked through and quite interesting is only supported on a couple of platforms I think I said there or actually I don't have that there but it is on on a subset of platforms for now so good to be aware of that process based permissions this is something that Rafael has done and put a lot of work into and it's actually quite difficult to totally control and provide a sandbox and node security models specifically that we don't provide a sandbox but even given that it's sort of like in my mind seatbelts and airbags giving as many different tools as we can to help people be as secure as they can be make sense and so in this sense you can turn on the permission model it will limit some features by default particularly those like native modules that where basically you can do anything and then you can allow some things like accessing certain files on the file system there is also a runtime check that lets you check like am I allowed to do this or not so your application doesn't just fall over you can check beforehand and decide what to do with that the tracing channel so long time effort the diagnostic working group has been working on diagnostics observability is really important I forget which talk it was that I saw yesterday but like in production you want to know what's going on I think it was the one on transition to front to back end and that that was one of the comments on the back end it's much harder to see what's going on so diagnostics are really important so diagnostic channel is has been an approach to let people instead of having the monkey patch in changes to get diagnostic information to actually provide a standard model for providing that information and tracing channel was a recent addition to actually say let's make that even easier to consume and generate and tracing channel basically lets you say I want to trace a certain set of things and you can say well I'm going to trace a synchronous call a promise or a callback and it'll automatically generate the events to the diagnostic channel for you and similarly on the consuming side you can just subscribe to a channel and it'll give you the events related to that particular channel this shows the code you wouldn't obviously do this all in the same program you know you'd have either the consumer or the info source but I have them both together for the example a couple of requires and then you know in terms of the subscriber you can just subscribe and say well I want to see the start and an error messages which will give you the events before after like if somebody's traced a a promise you'll get a before the promise and after the emma promise and so forth in terms of the info source there's an example of like trace sync so it says I'm going to trace a synchronous call and you'll get generate the before and end it and so forth so and then I've got the bottom I've just run this program and you can see the data that that's printed out the last one is arm 64 so arm overall we've seen take you know gaining and prominence more people are running on arm wanting to put into data centers in addition to smaller devices we've long supported it for Linux but the 19.9 we added support for windows on arm and 20 will become the first LTS where you know we've got full support for that so at this point I'm going to hand it back over to Jean to talk about the next 10 project so what about the next 10 just a quick story about the this working group was created in 2019 2020 just to celebrate the 10 years of the GS ecosystem and the main idea was to try to find how we can be as successful in the previous like in the next 10 years as we were in the first 10 years of the ecosystem itself and for that we want to prioritize and we wanted to prioritize when we created this working group we wanted to really discuss about the technical value and priorities that a node project should follow but also what would be the main target of people and constituency of people that use Node.js on a daily basis and we thought it was easy to find like okay everyone is a developer front and back and great that's all but finally we found a lot of different categories on that so just for the technical value everything is available in the Node.js repository so if you want to check it and have a full like read through and everything like it's always a good a good time to do but for the main idea and the main technical priority I don't I won't go through each of them but the main is really to focus on developer experience and sustainability as a two main one but you can also see that we want to have a good experience for everyone that work across the ecosystem from people maintaining Node.js to people creating API using it on a daily basis or a bit less so the main idea is to really focus on everyone that work across the ecosystem the second part is a constituency and for that we do have a quite a good list on that from direct end user application operator to people that produce and create library to Node.js contributor to also organization and specific organization so we do have quite a list and one specific area I want to like wait for a few seconds here is like I said when I presented myself at the start I'm a professor in university and I was there when we created the first leaf the first list of constituency here yet we forgot completely about everything linked to education from student teacher organization that want people to use and train people to use Node.js so this is something that we fixed this year I think like a few months ago yeah well I think that we added that after we went actually did a bit of a survey and got community feedback and that's a place where they helped us say oh yeah there's some other constituencies that we should actually think of which is a great example of like in the next 10 work the more we can get feedback from the community the better it's going to end up being yeah exactly and we come back to a lot more feedback in a few slides I think and the last part is what these kind of people and everyone need from Node.js for the ecosystem to be successful for people that want to use Node.js and company incorporation so yet again we have another list I won't go through everything but we can see that the main one is that affects almost everyone like even everyone is a good understanding of the direction of the project so what's new what's being created or thought of by the community and people that want to add new features but also on the other hand you could have also assets or finding ways to display why Node.js is a good choice to be used in your company when you create some specific project and you can go also through easy installation innovation and following what's new in the more global JavaScript ecosystem not just focus on a back-end runtime and Michael in the previous part discussed a lot on new features that were added and linked also to specific technical priorities so we do have a list of technical priorities that we want to continue to work on and this is what's created and built from multiple surveys now that were around the community with a few thousand people each time answering it and so it's not just priorities that we try to found on rolling your dice and oh we want to do that on that it was basically feedback from the community on what was the specific needs or main expectation for the next feature or runtime as you can see and I guess it will it's linked to a lot of what you are doing every day from Node.js having a modern HTTP and working with new for example HTTP one two and three the type discussion is always an odd topic here so type type script and everything around that also improving the documentation you Michael discussed a bit about the observability just before and we had a talk yesterday with Wes and Jen that spoke about that about observability something that you need to have in your application permission and policy security model everything around that single executable application so quite a lot of topic that's basically where discussed and maybe seen part of the next ten first and then people from the community were like keen to spend time and being involved on creating or fixing or improving the ecosystem around that also one other part that we do and we try to do them between every three to four months is what we call collaborative submit and or mini-summit the main idea is to really have a big deep dive into one or two specific topics that are keen to be a change for the community for everyone so we already did in 2021 we spoke a lot about title and single executable application and we'll see that a team was created link to that we also work about wasm and security model observability quite a lot of topic and we also had this year and maybe we'll have another one end of the year about serverless but also another topic that come back frequently is HTTP and again types types so everything into type script how to bring type script into the Node.js ecosystem add something that would be a bit more let's say a first class citizen if I can call it that way so this is a current initiative last survey also because we I want to go fast on this one but the main idea is to show to you what we do also part of the next 10 so the survey the last one was run six months ago main idea so 1700 feedback from the community new idea new initiative that were created around that following the community need and for us it was also a good opportunity to see how Node.js is being used across the ecosystem because you could guess that all the initiative were basically created link to the previous survey so it was almost the same result so and it's what we were really useful to us because it was a way to confirm that we were working on the good direction and everything for the project we also had something a bit more like complex here with some more specific part on what people want so consumable API documentation maybe more or at least more relevant API in core and that was mostly linked to for example fetch before or other part like that you also see that there is some part like good CI infrastructure and experience in the project for every contributor that want to contribute to provide the better the best experience working on Node.js okay that's good and also some specific run initiative that are carried by the next 10 so a proposal about documentation to improve how the documentation is being used allow new feature being easier to search for everyone using giz and stuff like that so this is being championed by Claudio that is in the first second row with us so thanks for that give us to you and also another initiative that we work on the next 10 and Ulysses deliver a lot of part for the community is like we saw it's really hard to find every information from the Node.js project because it's quite vast so Ulysses was able to create a full ecosystem and a full solution to to be able to share the project news as a whole and it's also continuing to be expanded and you will see a lot more on social media about that and be able to get a lot of news around that yeah I guess that's one we should add to that first list that we had of ways to follow what's new in the project but this is the latest one where there's actually a news reader a news feed you can listen there and we're trying to get a lot of the project news of great things that our collaborators are doing to be published there yep and finally following that and everything from the survey Michael we present a bit the new team that were created and also new initiative that are linked to that right so we just wanted to highlight a few of the new initiatives and teams in terms of like you know us talking about what's new and next and then in the Node.js project so over the last I'd say six months to a year there's been a real focus on performance thanks to Yagiz and you know the the goal has really been to improve performance across the board but they've done some really great improvements in URL fetch and event target and this is a team that's getting together and talking and thinking about performance we mentioned teams because I think you know one of the best ways that the Node.js project itself is actually quite large and if you try and jump into the core repo it can be a little bit maybe intimidating or hard to find your footing joining one of the teams or getting involved in one of the teams they're usually a smaller group they're people who might share an interest that you have and that's a good way to meet people who might be like mentors or at least point you in the right direction so that's why it's it's interesting to point to a few teams so if you're interested in performance this would be a great team to sort of meet some like-minded people. The security is another team that's been very active over the last year we had some funding from the OSSF which was great because it enabled not just the work that the person that they funded could do but they basically reinvigorated the security working group or currently the security team where a lot of other people have come and started to contribute and we've had initiatives like automating our dependencies we're now doing an audit of how those dependencies are built there's been work on meeting the OSSF scorecards and so it's really enabled a lot more work on the security front and a lot of progress in terms of you know the different things that are going on so again if you're interested in security that's a great working group to get involved with. I mentioned single executable applications already but if that's something that's interested you package your applications like that that's a team that you might want to get involved with and sort of many thanks to Darshan and Joey for moving that forward. Yuvi Wazi this is a new team that we've spun up recently Colin actually wrote most of the current implementation but we're really looking for new people to get involved and help maintain that so if you haven't interested in WebAssembly or Wazi it's a great actual learning experience we have some people who come from the other companies who are building implementations and so it's a great way to learn about for example what's coming in preview 2 or what's going on in in wasm or was in general so nice concrete place to contribute if you're already sort of no familiar and a great way to learn about what's going on in the in the bigger ecosystem. The next one is the examples repository which John is sort of picking up the championship for and this is where you know the idea is to get out examples of how to use Node.js. We have some examples that are you know for example we have no doubt on examples which we found quite useful as a place like somebody says well how do I do this you can point them to there and I think this is you know the goal of this is to expand it to a whole bunch of different areas and so you know John has a number of the different areas where it's like hey if there were examples to answer some of those common questions that's easy you know most rather than trying to answer them one off like oh well here's an example that shows you how to do that so that's kind of what that initiative is and so if you have an interest in doing that you can join John in that effort. The next one is the new website team so Claudio has done a lot of work to get us moved over to a new more modern implementation it's been live since 2023 and I think that's really reinvigorated the the the work on that that front in terms of Node.js.org I kind of have them say it looks the same which is exactly the intention in that the infrastructure behind the scenes was changed and the good news is everything else still looks the same so it was successful in that sense. The next step though is to actually redesign the you know the website itself now that we have the infrastructure to do something more modern more sophisticated there's work in progress on a new design that is tailored for more environments like mobile and so forth and of course goal as always with something like this is to improve the the overall user experience so again that's a team if you're interested in helping on the website side you know I know Claudio is looking for people and he's kind of got a PR that says like hey we should look at it in four different areas so you know there's quite a broad broad set of areas and something that you might want to think about getting involved with. At this point I'm going to hand it back over to John. And for the last part because we presented a lot of initiative working groups so how can you you be involved in one of them or multiple of them if you want. First part is a project is really open to all so you are all more than welcome to to come we showed you the calendar the first part of the slide so feel free to just jump in a discussion and let's just basically let's talk about Node.js and what you can do and what we all can do. There is a lot of different initiatives so we are speaking about participating to meeting from a working group or just being here during a collaborative summit or this kind of event you can also open an issue you can help on the documentation translation you can be helping on reviewing pull requests working on a new website example repository joining us in the next 10 to to see what the big initiative that you are keen and want to think would be useful for the next years or so. And one big part in the tech community it's always for a lot of people we all have imposter syndrome so please try to I know it's hard to to say that but don't let that stop you just try to come and join us no one understand everything on Node.js some people are really focused on one area no one knows everything and your Node.js also are not really 100% relevant every part of knowledge from infrastructure CICD GitHub action UI UX experience for the website everything is and can be used and will be more than welcome to join us so feel free to just discuss with us with Michael myself with everyone from the Node.js team here I see a few collaborators so just let's come talk to us and just discuss about if you want to join us or bring some idea on that so yeah and I think we are almost done it's the last one I think and some idea if you don't know where to start CICD with FlakyTest we have that for the past few years or this is one good part to to work on also helping stabilize the CI like I said improving the documentation if you want to join on the example initiative feel free there is a lot of work to do on a big area on that you can participate to every next in meeting I get a community feedback and work with us on that so yeah and that's it we probably have some time for questions anybody has any I think you touched on this a bit that it only runs the application that you give to it it and you mentioned that things are smaller did you mean it's not like the the executable itself won't be smaller because we just bundle extra code into the the Node.js like exe or whatever you know that depending on the platform but it's the surface area that's smaller right like when you install Node you now have something that can do all sorts of things that whole API is available to say a malicious script that somebody might install on the system and if you've authorized you know if you set it up so nodes allowed to run and it can run any you know and you can run the script you can run anything whereas when you bundle it in it would create the single executable application it's no longer trying to act as a generic node runtime when when you run it it runs just the thing which is bundled into it as opposed to providing the whole set of APIs okay have we considered um tree shaking so like removing the bits that it doesn't use there's been discussion like that's the kind of thing people would love to have smaller node binaries but it's not an easy task in terms of things like specifically like tree shaking so for your own application you can apply all those tools before you give the javascript to the node binary itself so what you're bundling in you can apply all those tools but actually pulling things out of node at most not so I shouldn't say most but many of the components are in cc++ so it's not a matter of just um for what for one they're not in you can't pull them out of the executable easily and even at this that's less of a thing at the c++ level where like how do you figure out what you're using or not and we don't want to ship more than one binary for sure um the the one other thing I was going to say is there is one thing I've had in mind that we might do is internationalization we added that in a few years back because we felt it was time where by default you should be able to support multi-language that is a fairly good chunk of memory in our space in the binary that's something that if we might apply the single executable approach and stick it into a segment you could potentially strip that out afterwards and yeah I was going to ask to to adjust that was this idea of tree shaking the fool let's say final bundle and stuff was one of the main discussion we had when we creating when the this working group was basically created it was how can you can we reduce this global size of something and yes the part from uh yeah to keep maybe English as the first one or default one and be able to pass a flag if you want other language being added to the translation when it's bundled do you have some other question yes if not thanks thanks for coming and I think I'll just just before we say goodbye the last thing is just to reinforce John's comment which was about feel free to join their meetings they're all open the project really tries to be as transparent as possible and we find everybody who comes brings some specific expertise which they may not realize is really useful for the project but it is so I just emphasize this because lots of people are like is it okay if I join the meetings it's like yeah they're all open the the the meeting links were in the calendar so please show up and everybody will be nice and very welcoming so yep thank you