Next-10 Technical Priorities ![rw-book-cover](https://i.ytimg.com/vi/aDqSXNE1piI/maxresdefault.jpg) ## Metadata - Author: [[OpenJS Foundation]] - Full Title: Next-10 Technical Priorities - Category: #articles - Document Note: Summary: During a Collaborator Summit, the Node.js community reviewed the results of a recent survey which included questions about the use of package managers, technical priorities, and pain points related to Node.js usage. The survey found that npm is the most popular package manager, with many users wanting Node.js to be faster and easier to use. Technical priorities were also reviewed, with the most important priorities being better HTTP support and documentation as well as solving issues related to the use of ESM and CommonJS. The community also discussed trends and future improvements for Node.js, including better observability, support for Rust programming language, and improved security. Bullet Points: - npm is the most popular package manager for Node.js - Technical priorities include better HTTP support and documentation, as well as dealing with issues related to ESM and CommonJS - The community discussed future improvements for Node.js, including better observability, support for Rust programming language, and improved security Paraphrase: During a recent Collaborator Summit, participants reviewed the results of a survey aimed at understanding how Node.js is used and identifying areas for improvement. The survey found that npm is the most widely used package manager for Node.js and users would like it to be faster and more user-friendly. Technical priorities discussed at the summit included providing better HTTP support, improving documentation, and solving issues related to ESM and CommonJS. In addition, attendees discussed trends and future developments for Node.js such as improving observability, offering support for Rust programming language, and enhancing security measures. Press Release: Node.js community works towards improving package manager, HTTP support, and observability, among others During the recent Collaborator Summit, the Node.js community reviewed the findings of a recent survey aimed at identifying the most significant technical priorities related to Node.js. The survey revealed that npm is the most popular package manager for Node.js, users would like Node.js to be faster and easier to use. The community also discussed future improvements for Node.js, such as better observability, support for Rust programming language, and improved security measures. Attendees focused on technical priorities such as providing better HTTP support and documentation as well as addressing issues related to ESM and CommonJS. The community also discussed the implementation of trends including improved observability, serverless computing, and improved support for multi-threading. These improvements show the Node.js community's commitment to continuing to innovate and improve one of the largest and most used programming languages in the world. Conclusion: During the recent Collaborator Summit, the Node.js community reviewed the findings of a recent survey aimed at improving the programming language. The community focused on technical priorities including HTTP support, documentation, and addressing issues related to ESM and CommonJS. Attendees also discussed future improvements such as better observability, support for Rust programming language, and improved security measures. Questions: 1. How did the Node.js community identify technical priorities through the recent Collaborator Summit? 2. What were the key findings of the recent Node.js survey? 3. What are some future improvements discussed by the Node.js community, and why are they important? 4. How can Node.js improve its observability, according to the Collaborator Summit attendees? 5. What were some challenges - Summary: During a summit for Node.js collaborators, attendees participated in a survey focused on technical priorities and package manager usage. Results showed that most people use npm as a package manager and the majority use NVM to switch between multiple versions. Technical priorities included improving Node.js speed, executable generation, and improved documentation. Attendees also discussed pain points such as issues with ESM, documentation, and performance. The group also brainstormed on community feedback to improve Node.js. - URL: https://www.youtube.com/watch?v=aDqSXNE1piI&list=PLyspMSh4XhLO15jJD9Sj069fN18j12AbQ&index=4&ab_channel=OpenJSFoundation okay so I think we'll be starting uh forthe one of the next 10 initiative wouldbe to talk about project technicalpriority and review thatum if you don't know me and uh this isMichaelI'm Jeanhello everyone yay and and just imagineyou're in a square because we're goingto try and make it fairly interactiveand uh so yeahyeah so one quick quick agenda for todayat least for this session will be to review the survey so we run a survey forthe past three ish weeks uh 10 of Aprilto I think 3013th of April something like that end ofAprilum we will also have two boards withsome question for you or part that weyou think we should improve on what weshould be workinguh just discuss about thatand other topic and also start maybesome deep dive discussionyeah so on the project technical boards if you've been to any of the pastcollaborator summitsum and or looked at any of the next 10work we've got a list of technicalpriorities identified for the projectand so we want to use this opportunityto brainstorm make sure we're notmissing any make sure that you know westill think that these are the toptechnical priorities for the project sowe did that the last one six about sixmonths ago and we found that that'squite good so probably something we'lldo every collaborator Summit and thenthe community priorities are a littlebit like okay Moore's a set ofcollaborators what do we think is important yepum just quick a quick quote about thelast survey uh we got a bit more thanalmost 1700 people entering the surveyand everyone who took the surveyfinished it so thank youthank you for for your time I think theamount of time was less than fiveminutes something like that to entereverything so it was a quick survey butthank you for participating andanswering that's greatum we will go maybe uh so the next 10 will publish the full survey with theresults and everything just some keyarea that are quite nice to to havefirst a question was that was asked bymany color better was how people areusing or which package manager peopleare using uh seems like uh npm is amajor one with more than 60 percent yarnuh Europe so we didn't like moved a yarnin different version no npm or otherstuff but for npm the mostly used version R7 8 and 9.uh so great uh if you want I will havelaw like more defined statistic for thatyarn it's mostly yarn one that is usednot a lot of yantu NO3um like pnpm I don't remember whichversion it was and we also saw a fewstuff like Duo and gspm uh I did notknew that it was still running and existing but uh basically only twopeople two people over like yeah two andthree I think it was a number I had tolook for gspm like seven years withoutrelease stuff like that so if you arehere using gspm please changecould be great for your safetyumohokay greatso we found one user using it where's the second one do you have anotheraccountumsorry okay another uh another part wasabout the majority of people use NVM ifyou want if they want to change betweenmultiple versionthe other part was so I put it asnon-riven because some people like butmostly it was useless for next year Ithink we will remove the other part like it wasn't another like version solutionto chain version of node.js it was justpeople entering with a specific npm NGMversion or other stuffum also what's about some technicalpriorities so we have a list that we putthrough last year uh even a bit beforelike the main stuff that everyone agreeswould be more than HTTP solution fornode.js still have a lot of feature latestfeature for it from xmascript alsoworking on documentation militarytrading esm is still a big issueum but I think we'll provide the fullresult on everything through the nextstem I think some of these areinteresting though as we brainstorm forwhat we think is important this is justa little bit of the broader Communityfeedback on those same prioritiesbecause that was one of our questionslike of our documented technicalpriorities what's important to you andso this is like a broader swath and just our collaborators so it's nice to havethat either agreement or non-agreementwith what we thought was importantyes and just for the other part I did aquick overview mostly it's about speedhow to have a node.js that is faster foreveryone also something about executableso being able to generate some kind ofexecutable and I don't know if we havepeople from the single executable teamhere butthat's a great initiative also type type and type script and last one wasinterrupt using rest or CC plus plus andlike not API binding stuff like thatthough that's the main point about thetechnical prioritiesa good point pain Point using esm slashcommon GS main so there is it was like20 page of people answering withinformation like that the main one wouldhave are really link system file path everything like underscore underscorefile name Dr name stuff like that uh thebasic interrupt how do you build anapplication using both esm CGS and howdo you do that uh through pop-up alsolinked to support for library but alsofor tool that you cannot really changelike using Lambda or using JS for peopledoing front-endum you have a bad developer developerexperience when you try to mix both ofthem some people were likeum because common GS is only used by node.js and not an official standardwhen is the end of life for command yesum and also there is a key topic aboutpeople using typescript so naturally Iwould get I would say uh needing reallyesm as a default pure JavaScriptstandard because I rely on typescriptyeah I just want to add in this caseit's we asked if you had problems in esmso we had a general questions or whatyour pain points were and there werelots of different things covered but we had a specific question about esm painpoints so it's because we asked we got alot of feedback and it's quiteinteresting but I didn't want people tothink that that's the only like peopledidn't spontaneously come up with allthis on their own yes on the questionabout do we have people do you thinkthat you will be migrating anapplication or create a new applicationusing esm by default I think the answerwas like 60 of the people are going touse esm almost as a default or the maintarget for the next project I will be doingat least from the surveyand also we ask if some people or peopleare like recurring issue when usingnode.js or working with node.js the mainI did a top five extended to six uh andI don't have a specific order just theway I was seeing everythingdocumentation like improves thedocumentation to find or to help peopleand to provide examples stuff like thatnot just the pure implementation in node.jsis typescript becoming native fornode.js also leading to providing bettertyping and type for node.js arounddiagnostic perf analysis which can bealways hard to dosome key topic about worker and how doyou work with if you use workers someother solution how do you pass messagesthat are not only string and how can youwork with better performances by sharingor sending information one side toanother side a bit link to diagnostic could be a lotof people were like having memory Lakeissue and some people asked also thesupport uh HTTP HTTP 3 support for NGSyeah certainly the one that surprised mea little bit was like lots of peopletalking about threading andmulti-threading and using no that thatwas a theme that the show it certainlystood out in that list of recurringissues that I I wouldn't have guessednecessarily up front yes like it wasn'tfive ten people like we had I want maybe not hundreds of people but quite a lotof people were talking about worker andtrading and performance link to thatum so okay so we finished a quick reviewum I don't know if we can show so we canchoose a link uh do we have the linkmaybe do you have the link of the easierretro board okay or should I yesyes or if you can just repeat it onslack Razer Channel called corabataSummitor I can find it like I'll let you talkyes it would be the first yeah but ifyou want I can copy and paste if youwant to talk about that yeah okay yeahso yeah I just went to the basically tothe typical issue then in the issue for this particularsession there's the easy breakfastoh greatwhat do you think is the mostfriendsyou know things that we thinkyepso just uh so there is a board uh thanksElise to to to post the link on on the slack this one we do have threecategories one about a big technotechnology Trend that I really linked tolike the full ecosystem not necessarilyjust node.js but that work node.js canbe usednext one will be key feature for nodejathat you think made sense to to have andany other and the last one would be anyother topic or ID that we could work onto improve node.js so we'll give youlike five ish minutes uh to add multiple topics on everythingum so at least you have a globaloverview I think we won't be able to gothrough every one of them and we willorganize some kind of next 10 events tolike go through everything groupeverything and Define new technicalpriorities I guessforeignyes great great question this is so we will we'll have two boards this one istechnical priorities uh there is also asecond one if you already like put someinput inside this one you can also addyour feedback on the community one uhfeel free I think your link is also onslack already sosorryokay yes that's true foreign let's take I think two more minutes for this one at leastsounds good thank youwhat yepyeah I will be grouping like we won't doit now but it will be done for an extentand we'll like display the result andstuff like thatI think we can maybe do it we canquickly go through and group them andthen we have a section where you canactually like add some votes so that wecan get them to see which ones of thosepop up as a as an overall that's whatwe've usually done anyway yep yeahshould we officiallydisplay the resultis it good for everyonein more timenodone witheverybody who's done put your hand upit's greatanybody else so I thought okay wellwe'll wait for everybody noI think I can click that's true okay time to see the resultweI think you might have to do that yeah Iwas doing it so that's goodso some of the topic great technologytrends serverless observability of restand nrpi better birth breach winter CGseveral render web app observabilitygsdoc for generating typescript typearrest Diagnostic and observability webassembly HTTP API larger corestandard lib package policy and supplychain security with respect todependencyduplicate I think we have a few oneabout observability we have twoobservability and one that should beDiagnostic and observabilityoh okay I can do it oh maybe I canoh I can do it if you wantyeah okay why don't you see if you canokay I can do itso I think the two observability aregoing togetherwe do have Diagnostic and observabilitygoing with observabilityseveral yeah we do have two reversedthingalthough are those actually the same inthat one issupporting rust through node API which is one thing the other one sounded likesomebody was was more like rust in coreitselflike I don't know the first one rest isyour own API was me I don't know whatokayso I wrote the rust as first classCitizen and I didn't meant the an API orsimilar but actually to be able to writecore modules in Rust rather than it'splus plus so completely I guess is adifferent uh different thing it could be differentbut we you know with node API we didtalk about like would you ever end upwriting nodecore modules inin using node add-on API so today youcould already buildand probably use node API to build andintegrate rust with node itself right so that's the flip side of the thechallenge so yeahright okay so yeah those probably arenot the same I don't know if you cansplit them yeah I can't screw them okayum and mergeokay should do itis it working yeah should we because on my one therest if you're an API everything betterperfect improved Bridge part I thinkit's linked also to webassembly weatheryou wrote this one Michael are you okayif we merge it or did you have somethingelse in mind sorry which two uh thesecond one rest with easier and APIbetter birth improved Bridge part so forme it was really to provide a better wayto add like external moduleum would it be the same as webassembly was them or are you just webassemblywasn't my I admined like our support forwebassembly and node as a runtime okaygreatuh to in that case I think we don't haveduplicate anymore thison this part we have Security packagepolicy size http gsdoc okay greatum just a quick question for Serverrendered web appI don't know if someone here but that but what would belike the topic behind that are weokayEthan who works at a company who does uhmight be able to speak more but I wasjust thinking this is probably a trendthat that we might want to have at leastsome okay something to address at somepoint I don't knowokay okay great time to go for the secondcolumn about node.js featureso we haveand did she in nerd whenuh great question where is Mateoyeah I think that one actually fits withthe httpI think yeah on a not just feature wehave multiple part on HTTP uh like hiswebsocket HTTP 3 new HTTP one server similar to the NDG initiative unifiedunified HTTP architectureI guess yeah soperformance Improvement I saw this oneso for the at least the ndg1 I threwthat one out there I think like yearsago when we first when did she first gotcreated there was all that oh like thisis the new way to do like networking for node.js I don't know why it never kindof landed in node or just outrightreplaced the the node API or at leastlive next to it the one in coreum I understand that it's easier toiterate undichi having it lived outsideof core but I think there is still likefetches in there nowum and I deal with this at my job wherewe're like we want to use nvg fetch wewant to use the one inside of node core but it's only in node 18non-experimentalyet we can run it on node 14 if we justpull it in from Nietzsche itself sothere's this weird like there's justsome there's some discrepancies therethat makes it difficult to do thingsum and like sort of like what's the nextstep for indichi it is a node projectwhy isn't it core how can we get it intocore etc etcyeah I think near the end we're talking well we have a slide where we plan totalk a little bit more about deep Divesso that maybe is something where we needanother Deep dive uh to sort of get intomore details like okay what would theroadmap be we got fetching after thelast the last one in the discussions butyou're right that now maybe that deepdive would help us get going again thatsort of overlaps I think the somethingthat didn't make it on here maybe weshould add is uh vendoring so I thinklast collab Summit we talked about it alot around like the set I heard that uh the sember package I I so I don't knowif we want to add maybe that and groupthat with undichi in node right asyeah he's a big enough topicbut I'd leave it under that one but Iguess the main tip but but I get themain the main topic just behind thatwould be to discuss aboutlike widely used packages should be not maybe not added but mostly linked tosome samba versionso I think the havingum somewhere in in core is probablyum something that we should do and evenif it's not I I to the point that maybenot even wandering to some extent butyou know it's it's just public it's justpart of the like it's I have thatpackage installed on every single uh uh project a project that I use so at thispoint it's supervasive that it's it'sjust it's a what I'm saying is it thereis a difference between vendoring andand exposing the API or and having thedevelopment of that API developedstraight in core and to the point ofsamber on the latest conversation thatwe had was yeah maybe we should justum move inside the tree and and that's it it's not even on depth okay it's forfor that specificallyum because there are a few optimizationI was chatting with the agith on on thisand there are a few optimizations thatcould be done and because apparently fora lot of use casessamver is actually the bottleneckand it's I was surprised by this butit's a it's a comparing the two versionnumbers is actually hard so yeah anywaythis is the um and the difference from that fromundichi isumit's that certain thingsare very harder like it's a much largercode base compared to somewhere andcertain scene managing that kind oflarge code base inside node it will bewould be problematic in term of the internal tooling that we have that wehave you know like if things are haveimproved a little bit in node on thatside but on especially on because we nowhave no test we we have a few things soTT that we can use but the fact like thethe testing framework and the way thingsare run were actually very hard tosupport like for certain things that weneed inundichi for example so for thatwe'll probably need to be staying aslike I would I would take it as aWandering approach for for that specific one like we do right now so it's uh it'saumyeahI think that's that seems umI don't know but it seems uh I I at thispoint it's you can't make everybodyhappyand I think the the benefit of having eating core would outweigh the uh if thenpm team is a modulation agreement on itit'syeahyeahso I was just thinking if we cannot uhclose enough I mean sorry not forgetundigin core or stuff like thatfor similar initiative can we just startsupporting uh unofficial list of directly supportedpackages from not like on dishessomething like that even for othertopics eventually out of HTTP initiativeso people know that let's see if this isdirectly supported by notorious teamsomehow and is not a part of uh corefollow somewhere on their track and soforthI think you're maybe talking about likea standard library of some sort which isI mean it's like a flavor of that that'san interesting topic we started the pkg.js org on GitHub partially for thisexact reason I think it's hosting thethe some the par sargs already[Music]umand I think the the structure aroundthat was specifically to give them a bitmore freedom like that's why it's aseparate organ not in the I thinkthere's like a lot of attentionbut even like is in node core so like I think it's already under the umbrellabut the question is I think you'resaying can there be something slightlymore official thanpart of this part of Korean is been madeby people other core memberpeople outside the core team don't knowabout it I don't think you can actuallyunless you notice that the rapper isinside the node.js repo I mean it's notadvertised anywhere specifically in thenode.js documentation for instance I'mtalking you go in the HTTP documentation in order to say oh you know you have analternative you can use for this topicif you want and something like thatthank you only fat is accessible from inD2 thoughright well what I meant is though it'sthe the repo itself it's like node.jsslash indichi right which is a littlebit where I think uh you were going interms of like you can have it under arepository which in it's already underthe node organization so it's got like from the organization perspective it'sgot that credibilityand I thought you think I think you'resayingshould we be going further and likesaying like here's a list of packagesthat although are not in corehave some special status righteffectivelywhy you stay uhsorry I was saying that um partially because if you have thiskind of supported packages you can startexperimenting on some areas and soreduce the stagnation within nodewithout actually affecting the nodeIntegrity security and Source you canstart testing a little bit moreeventuallyI think I think another simple change uhat least for like indici could be topublish it on npm using an at node.jslike um like organization or scopebecause at least um at versel we've been we used to havea lot of packages just publishedindividually but then we started puttingeverything under the adversell and thatmakes it really easy for people to justimplicitly trust oh we know where thisis coming from that's the org name anddoesn't matter who the maintainer mightbe it doesn't even matter where the codelives if it's in a the node.js org ornot on GitHub if it's published underthe node.js tag that gives a lot oftrust and it's super automatable now wecan build we can build like pipelines on GitHub actions and making sure thatwe're not giving like npm publishingum permissions to the wrong folks it canbe done even at small level packagesit's super automatableyeah so that that I think is maybe likeagain just thinking of ideas forfollow-on deep Dives that sounds likeanother like revisiting the standardLibrary like and it could be as simpleas like hey anything that we publishunder throughout the node.js org is something that is comes like I don'tknow it may have to become it comes frompkgs or the node org or something likethatum I think we should probably justlooking at the time I think probably goon to the to move to the next one forthe community part or am I thinking toget people to vote quickly on this oneuh do we can keep it open like one morehour and we can close itall the people don't tend to voteafterwards yeah true that's true okayyeah that's true let's spend like twominutes if everybody could just tag like I'd say take your top sex and add a voteon to them and and that'll just give ussort of a general feel for the howpeople and then we'll move on to thecommunity one I just activated thevoting part so I think youI put six yeahand I think you can also like uh you canonly vote one one time per cardbut yeah yeah okayyeah so are you doing it okaynooh trueI will just emerge those twoyep foreign first class typescript greatyesyeahit was the same one years agoit says I was just saying I was justpointing out like the survey is quiteinteresting in that a number of thethings that tend to come up high in ourdiscussions here are reflected in thatbroader like set almost 1700 people I could still see you know good supportfor typescript good HTTP apis we'requite near you know nearer at the top soit's nice to see at least you know whatwe've been thinking is important alsoaligns with the broader Community theretooyep okay so I'll move on to the otherboard the communityand okay so no time to go through thesecond one which will be mostly linkedto community brainstorm it's the sameprocess so we just have three different columns one would be where we want tofocus and work on new let's sayinitiative or what we can improve or atleast where people think we should workuh second part would be like issueobstacle buyer that we are facing andthe last one everything that's goodstarter time now goforeign don't hold back on those obstacles and I think anybody and everybody not done yet and um people are speaking so I think it's good okay go good that's a good testso for the result okaydo you want to go through the listMichael go ahead okay I'll merge if they lookthe same okay great so key Focus area weseems to have a bit of the same soobservability increase the EarthOutreach to a new more collaboratorymaintenance new contributor onboardingbalancing Evolution and stabilitydocumentation security standardintroducing and improving standard-basedinterface to encourage your use of ourexisting non-standard equivalentJavaScriptokay uh okay so for the yeah just a key FocusareaI don't really have a lot of things tosay with this list I I guess for the keyFocus yeahfor the key Focus yeah in terms ofStandards is that implementing existingstandards or beinglikethis is a great example we had thisconversation like six seven eight years ago I put standards there because sixseven eight years ago I would have beenlike coffeescript right and are wejust going to implement something likebutton and Deno have and Randall hasactually said like maintaining thetypescriptuh interpreter is like really painfulum so likewhy are we trying to do something likeright now there was a bullet point in this in this section aboutwhat uh end of life CJs so now we havelike are we gonna make the same mistakeagain and be like let's do somethingwith typescript like in the pastdiscussions on typescript and our Deepdive the strategy that we came up withwas we're not going to implement it incorebut we want to make it easy to usetypescript with node that was thecurrentresponsibleyeah well not necessarily so there are quite a fewum like if this was we hashed it out andI think we have a good solution for thisand essentially if you can bring it downto uh more or less a three-step approachto set it up you are removing all thefriction from people so it's uh create apacket Json install typescript and andput in your TS config and then you're done okay and that's uh that solves theproblem and then know the dart file thenodes space file.ds would run and ifit's kind of a blast approach or orsomething it's uh it's it solves theproblem for people okay and it'swell not necessarily because then it'stheir choice to install typescript okayit's it's ayeah but that's the problem like again that's the solution we cannot evenwithhold we want vendor typescriptbecause they did with no sample isuseless okay it's it's uh at this pointin time like we won't be able toguarantee any long-term support on it soforeignyeah yeah but that right now is not greatso because right now thissure we don't have good apis for themthat's where that's what we're doinggreat hooks into the file system apisgreat hooks into like yeah that's wellbut it's not no because if you just putthe the if you don't specify like it forthis Initiative for the next 10you need to put broad theme and we want to add apis for a specific purpose welltypescript is going to outlive the next10 years then hopefully it's going tobecome spec right so that's why I putstandards and I put jobs okay becauseour folks our focus should be onJavaScript he also yes I agree butadding the API is that chunk of thecommunity which is like 80 of the peopleusing notes these daysit's we should probably listen to what they need so if we need to get to givethem a few hooks other dogs to supportthemI get that it's tough to move slow to dowhat the standards like to get thingsstandardized but I think that we'lleventually be in the CJs esm situationagain in 5-10 years if we're making yeahwe're not rendering it so yeah no Iagree on that on that topic so anywaybut I mean I think the the source of theproblem here is that there's notypescript maintainers in this roomhaving this conversation with the nodeproject and I think that needs to happen for this to ever land in a way that'sactually that's not we talk to them theytold us that do not integrate it I I noI mean I know I I get that what I'm whatI'm saying is that I don't think thenode project is the the the the thegroup in charge of making this betterthe typescript project yes but right andthey need to be involved in this for toever be a healthypartnership and I think currently theyhave said no they said they do they sent do not vendor itso they what they say is do not vendortypescript ever sure and I'm not arguingwith that and I'm not saying that thatI'm what I'm saying is the for it to befor the node project to have healthytypescript support I think that needs tocome from the typescript teamright and and if they want to be a partof a blessed part of the node.jsexperience the typescript team is do not care about thatand what I'm saying is the I don't thinkwe collectively as a project no no JSare going to be able to make a greatexperience if that is where they're atyeah but it's not their goal okay sothey they shouldn't be ours because it'sit should it should because people doknow something that wants to do and wantto use do note something.ts old Alpha the developers newbie developers orstuff wants to do that and the peoplethat are more on board on these are forexample the folks from TS node or allthose kind of projects that allows youto run a typescript file directly oreven the test runners or all thosepeople all thoseconstituents of our community that areasking for better hooks a better supportfor doing the things that they'realready doing today with monkey patching and all sort of hacks and and we breakthem all the time between multiple nodeversions yeahso I'm readyoh justyeah to be completely honest I don'tknow why I know it doesn't have hooksyet this goes all the way back to Coffeecoffee script they were they wererequesting hooks for the same thing it'sabsurd node doesn't have hooks yet if we can get that in that's basically a puntand a way of saying okay we now make iteasy and available for you to integrateit if the typescript team doesn't wantto do it themselves I'm sure we'll havea community that will step up andmaintain that but node in my opinionshould only be responsible for the hooksinto the loader and we should have hadthat 10 years ago that is our plan it's just we haven'thad anybody who's actually done it yetyep okay so let's typescript is kind oflike standards I think we're trying tounderstand what it meant in in thecontext of this list typescriptobviously will have to come back maybesome more Deep dive but yeahumso different obstaclesI don't yeah whoever put bun and Dino onour obstaclesdo you want to expand on or just for the fun toosorry why is it openI don't knowum so I think in regards to seeing likeother uh run times on hereum I I mean I didn't add these butthere's also some cards at the bottomthat's likeum other JavaScript runtime this will create confusion for junior JavaScriptdevsum I think all of us here have been haveseen some of the the stuff that's beencome out from either of these or otherum other run times and there's been theefforts with the winter CG as well totry toum standardize some of that we've heardthe word standard come up a lot and wealso have the standards working groupwhich I'm excited to learn more abouttoday becauseum one of the things I think is to noteis that the winter CG has been working pretty effectively and I would love tosee how we could beum how node.js could be more involvedthere I think there's a couple ofmaintainers of node who participatethere but not necessarily inrepresentation of nodeum and so there might be something moreto investigate there and I think seeingbun and Deno as obstacles and barriersmaybe more so like uh I think it mightbe better to think of them as the focusareas like why you know why do these other runtimes exist what are they doingdifferently and also what are we doingthe same I think we've all seen denno'strajectory change quite a bit over thepast year to look a lot more likenode.js's and it's interesting becausethere's an opportunity to maybestandardize some of that across theseruntimes and there is a place to do sothe winter CG so can we is there isthere uh is there a pathway there okay to be honest I don't really havethatI guess that's a big topic that shouldbe discussed across people from node.jsbut also band you know winter CG andotherlike communities and peoplebut yeah would be great I think for theuser to have something that is morestandardized across everything to workwith multiple technology withoutlearning new stuff again each time um one of the key issues seems also tobe CI CD slash flaky testI think there is no nothing is reallynew hereum a full topic about sustainability andalso a new contributor like mentorshipand ramp help of new contributorI guess so npm great yeahbut I think it would be the same topicwith every package managerlike not being standardized or is itnotyeah okayokayumtopic about the rigidity to either toweb API when we are not in a browserand a specific topic about CGS but Ithink we'll talk about it a lot and like okay I think okay too much channelingslikeum and what's working well seems likeeverything meeting being recorded onbeing online post recording then but onYouTube boy is greatpeople when team autonomy the communityitself the collaborative Summit aminimal breakage working groupokay so slack is great but it's like it's too big great and Running part ofthe project outside of the mainrepository so we discuss a bit about itlikein a few minutes few minutes before soyeah okay so maybe if we can now justtake a few minutes I think same thingbefore you had six voteschecking that but it should be yeah it'ssix words Circlethat's done someone did itthere we go great is it good for everyone what six also yeah okay so the main topic seems to be I think even if you can still voteglobally uh so key Focus area would beto increase your Outreach newcontributor onboarding growing long-termcollaboratorand standard with JavaScript baseinterface stuff like thatobstacle would be node.js is reallycomplex npm and lack of standardizationplus flaky CI slash test and walking well community and team anautonomy working group so that's greatyeah I think this all gives us some goodfeedback in terms of things that areimportant I think the next session whichis on keeping the community healthy isgoing to dig in a little bit more tothat one we saw in terms of obstaclesabout complexitybringing in new collaborators and stuffso we can talk a little bit more aboutthat I think we wanted to on here if Ilook at the slides um we want we were talking a little bitabout server about deep Dives serverlessis one that we've already thought wouldbe a good Deep dive but I think we cameup with a few others while we weretalking through here it sounded likelike HTTP actually if I can go backso yeah uh HTTP was one of the key topicit seems also we already had one like ayear ago something like that but itcould be great to have a new one aboutwhat change what's new and what's neededin the ecosystem kind of like we needed a follow-up because we made progress onfetch but then you know where do we gofrom herethere were some others that I'm tryingto remember that were other good topicslike I think typescript again is onewherelike we have a I think we had a planfrom one of our last discussions butlike we have enacted on it so mayberevisiting that againI think the discussion would be moreabout ooks than just typescript but howto Sure Link something to node.js yeah and if you have other idea of future ofDeep dive that seems to be importantyou got any other area that you think itwould be good for the next 10 group toorganize a virtual Deep dive where wecan bring people together there was onecomment you know like on typescript wedon't have the typescript maintainersthe good thing about those virtual deepDives is we have been relativelysuccessful in getting people who youknowwho came from the typescript onesimilarly when we've dive into thesingle executable applications we'vepulled in some people from outside the project andsoyeah that's effectively what they endedup being is we had node collaboratorsand we had people who were from a bunchof different places that were entrustedokay so package JC standard is that theway you would put it yeah yeah any othersyepuh newcomer docs uh newcomer newcomerdarks docs okay like just to go a littlebit on thisum there are many differentdocumentations for different parts ofhow to contribute in different parts ofnode but there is no one centralized getstarted page where centralizes andreally dice dips you know andinformation so people get very confused any other suggestionsconversation I think I missed thenewcomer new talkthat look like to be a good start offuture deep diveoh sorryon that newcomerum uh the I think we should have a broaderdiscussion that the just newcomer talkson the Deep dive I think it's uh weshould treat it of more of what kind ofout so the problem that we need to getbetter at is uh so we used to get a lotofnew collaborators in the fold andwithout we had a few new collaboratorsin the fold in the last couple of yearsbut it seems that then our the our numbers are getting smallerand and the code base is getting biggerand the the two things do not play welltogether I think our whole next sessionis on that topic yeah I I okay perfectokay yeah I know I just just wanted tomention that there's this newcomer maybeit'sum it's I think it's more of a featureof that kind of discussion and ratherthan uh at the uha specific Deep dive okay I think Iagree it could be like we're going tohave a little bit of a start because wehave an hour session onkeeping the project healthy but yeahit's uh because uh and maybe bring in inthat deep dive uh bring in a few otheruh folks that are you knowum not that are friends but are not partof the project itself because it might be that we aremissing some point of viewfrom uh from people on on that partakeagain leveraging the fact that it'sremote and so on might be helpful onthat one okay uh and then before we moveon any other Deep dive suggestions handsupwhat was that weoh okay we'll fix that okaythank youokayI'm like we're done okay that's a goodanswer we're doneum so the next session is keeping theProject Healthy do we need like a 10minute break thoughum or is everybody just ready to gono it's another hour okay so why don't we say like fiveminutesyeah let's take five minutes sobasically let's be back for 12 27., Next-10 Technical Priorities, OpenJS Foundation, 01h3j5sqcngkwbfkpsrcmwhhze.