Node.js: Moving Too Fast for Corporations, but Too Slow for Developers

00:00:00: Welcome to Signals, the podcast where we step back from a hype and look at what's shaping technology.

00:00:05: In each episode We talk with industry experts to surface trends in question assumptions And unpack why things work their way they do.

00:00:11: today were focused not just on What's new but under decisions developments that got us here?

00:00:16: And want to expect down-the-road.

00:00:18: I'm your host Michael Daden and hear with me Today are Marco Ippolito and Rafael Gonzaga.

00:00:25: Thanks for being here today.

00:00:26: I know that you're both involved, heavily involved with NodeJS and really excited to hear what we have to say today.

00:00:41: Hi Michael it's pleasure to be here.

00:00:44: Thank You

00:00:45: It was great to see you.

00:00:46: Hello I don't feel... Hello i'm happy to be Here as well.

00:00:50: So tell me a little bit about What is like working on NodeJs?

00:00:56: Like what are some of the things That Are keeping your busy these days?

00:01:04: I would start with security releases, say that's a big part of Node.js and it is most behind the scenes.

00:01:21: Yeah we recently had security release in January.

00:01:25: That kept us busy for almost month.

00:01:29: So lots work there.

00:01:33: Yeah, I've been working on Node.js full-time for the last four years

00:01:41: and

00:01:41: my focus although i do performance features, performance improvements to Node.JS My role is focused on security.

00:01:53: So I have been handling security release and security patches for Node.js for quite a while And sometimes our security releases very smooth.

00:02:01: like we.

00:02:03: We set a target date and we release on that target date.

00:02:07: Sometimes it takes more time than expected because Node.js runs everywhere, and we need to make sure that we won't break the word.

00:02:16: And once we release a secret release, hackers will start targeting production servers with this new CVE.

00:02:24: so we need secret release on time for all companies to upgrade.

00:02:33: So we make sure not to release that Friday or big holidays like Christmas, new year.

00:02:41: so do our best.

00:02:44: but even though the world is very big and some circumstances

00:02:51: fall right?

00:02:54: I've been using NodeJS for years.

00:02:57: it's everywhere.

00:03:01: What is kind of that process look like on identifying what you're gonna work and just keeping track all the threats in everything for your security releases?

00:03:12: It's gotta be a big task.

00:03:15: Yeah, so... A big part of this security release process happens on HackerOne.

00:03:21: So we receive reports We do triaging to make sure those are valid And then we start when, let's say a sufficient number of reports.

00:03:37: We start preparing patches and once the patches are finally done... ...we can release them.

00:03:49: A lot of this process is manual.

00:03:52: Some parts have been automated but it still requires a lot of manual work from security users.

00:04:01: And one thing interesting is that sometimes I do live streams on Twitch helping people to contribute to Node.js for the first time and one of common questions.

00:04:15: they say in their chat, how does the backlog of Node.JS work?

00:04:21: There's someone that works on product to say or to give you what you need to work and all.

00:04:29: And I always say, no there's not a product... most of Node.js collaborators are volunteers, so they do what the company is sponsored and to-do-so or what they just want to do some.

00:04:44: So it's crazy that there's no roadmap And still we have a lot of poor requests coming in every single day.

00:04:52: if you pull node.js main today You need to put out again tomorrow when will see a lot new comments between yesterday.

00:05:02: So, it's crazy.

00:05:05: We don't have a backlog but still we have clear direction of what we want for the future and that is great!

00:05:16: How has AI been changing your approach to security either in threat profile or how you approached some these solutions?

00:05:29: I would say for us, it's been mostly negative.

00:05:38: Because AI made it accessible I've made more easy for security reporters to produce a generated reports and those tend to be very low quality but they are good enough so that takes time to triage them But at the end of day there not real.

00:06:04: So it's a lot of wasted effort from the team and as Rafael said, we are all volunteers.

00:06:10: so I would rather do something else than triage AI Slop.

00:06:18: It is not being great but thinking about making some changes in how we handle bounties try to decrease those AI slope reports.

00:06:37: So are most of your, is most of you roadmap for security based upon some these reports and this bug reports or a bug bounties?

00:06:46: Or Is that something the team is kind of identifying independently?

00:06:53: we do have We don't have secured working group which collaborators that are interested on Node.js security, so either to fix a specific part of Node.JS or create features like permission model creating automated tools like the Vaxfile.

00:07:15: So we basically define our priorities by yourself If you believe for instance currently We're working how to handle those AI generated reports better.

00:07:32: So in last week, we released a blog post that informs all the secret researchers that have increased the signal of HackerOne to one.

00:07:46: so if you don't have good reputation on Hacker One you won't be able to submit reports in OGS anymore.

00:07:53: And the reason is that we are considering, or I am considering it as a DOS attack against the project.

00:08:03: Because if you look to the history, Node.js normally receives seven or six Hacker One reports per month which is reasonable and most of them are real writing And we take some time to review but six or seven.

00:08:19: it's okay to review and Continue with that effort on security work.

00:08:24: However just between December fifteen and January fifteen We got thirty reports And most of them are long and very difficult to prove if they're valid or not.

00:08:40: Node.js is complex, so it's not simple... It isn't easy!

00:08:45: We have a long threat model even with the threat model which is hard to evaluate.

00:08:50: our report third year report, I basically spent a whole month just reviewing reports and i could have been working on security features fixes or some workflow improvements.

00:09:03: So this has been the problem.

00:09:05: yeah

00:09:06: Yeah it makes sense What?

00:09:09: so you're tightening up that process?

00:09:12: A little bit.

00:09:13: what do you see The path forward being then?

00:09:18: Do you think that's going to solve your problems with the reports?

00:09:23: So, this is not something that has only happened to Node.js.

00:09:30: last week I was at FOSDEM and the maintainer of Curl Daniel Stenberg like during his talk announced he would remove the bounties from Curl so it would de-incentivize reporters from sending AI, this is something that the whole open source ecosystem is suffering.

00:10:02: And there is not just one simple solution because it's very hard to like if you remove all incentives?

00:10:11: Like You don't get any report If you make too hard To send the rap or you won't get any even fine vulnerabilities.

00:10:21: So it needs to be.

00:10:22: there needs to Be a balance yeah, so Yeah we still trying to figure out what's that?

00:10:31: The best solution to this problem.

00:10:32: but I think my sense removing like low bounties is It's its beginning.

00:10:44: So that's what we're being considering.

00:10:48: I've seen a little bit of this, just my teeny tiny projects.

00:10:52: compared to NodeJS... ...I have been getting not an insignificant number bug bounty requests- I don't even have a bug bounty program!

00:11:03: Right?

00:11:04: You are starting.

00:11:05: see all kinds people saying well i found this problem.

00:11:08: here is the report.

00:11:10: It's like, we don't have this problem.

00:11:13: This isn't even a pipeline for you.

00:11:15: so this is something that I'm seeing

00:11:18: everywhere.

00:11:18: I am also seeing huge increase in spam coming through.

00:11:24: Is it starting to see other types of nonsense requests or things coming into some channels?

00:11:34: Yes One thing that I have not said and one thing That is also a problem.

00:11:41: Is that AI?

00:11:42: It's so good nowadays, but it's very hard to prove that this.

00:11:46: any AI generated per request or report.

00:11:49: So I've been having following Node.js for quite long time And every Nazi that most

00:11:56: Most

00:11:57: if not all ProQuest that people are submitting to Node.js, regardless of the topic file system performance security they have some ascents of AI which is okay totally acceptable but some ProQuests and Node.JS complex.

00:12:13: when you open a ProQuEST that touches in different files and different folders of Node.js, it gets more time to contribute and get some more time for review.

00:12:25: And there are people who open a lot of pull requests touching several files and consequently the pull request will take longer because it takes longer to review.

00:12:39: When you do this very often create a problem in the project because imagine when you land a request to Maine All other requests that touches on those folders or files might conflict and they need to rebase.

00:12:57: And when you do it very often, You increase the contribution barrier because It creates a problem.

00:13:03: So I've been not seeing this in OJS but we haven't discussed.

00:13:07: We don't have a policy for that.

00:13:09: What's worth mentioning is That OpenSSF Is Creating A Working Group To Discuss The AI Slop On open source projects, but you see I don't think anyone have an answer for sure yet.

00:13:24: Is there something that you would like to see from the users and?

00:13:30: non-maintainer contributors to new JS.

00:13:32: That'd be helpful.

00:13:33: so II can Like.

00:13:39: I've been working For the past year and a half on the TypeScript integration in Node.js.

00:13:53: I would like more people to help me maintain that.

00:13:56: especially we have created our dependency In Node.JS called Amaro, I'm the sole maintainer so I'd like More People To Help With That.

00:14:11: So you were also talking to me earlier about the OpenVex standard.

00:14:14: How does that play a role in what your working on?

00:14:18: Yeah,

00:14:19: so

00:14:21: The reason why I Decided to send PR for the open vex is that Right now we have our repository called vulnerability assessment where users open issues asking if a certain CVE present in one of the dependencies is actually affecting Node.js, for example... Let's say one of the many dependencies, this happens especially often with NPM because NPM has a large dependency tree.

00:15:00: So user scanner flags NPM as vulnerable and therefore also known as vulnerable.

00:15:07: so they come to us.

00:15:09: They open an issue when asked like is it not really vulnerable?

00:15:14: Most of time It isn't.

00:15:16: but Like before open vex, there was no way to tell your security scanner that like hey we assess this Vulnerability and we have decided that.

00:15:29: This is not Like a real vulnerability for NodeJS.

00:15:33: so everything was contained inside that Repository.

00:15:37: So people would have to Google it then find that repository and found the specific issue.

00:15:43: Fortunately the OpenVex standard was created.

00:15:48: There is this JSON file that allows security scanner to know whether a certain CVE found in the supply chain, it's actually vulnerability or not.

00:16:03: And so I decided to automate generation of these files and basically publish it.

00:16:15: That

00:16:16: sounds fantastic!

00:16:19: Most everybody watching this knows what Node.js is.

00:16:21: obviously it's one of the largest projects out there.

00:16:27: How

00:16:28: has The development over the last few versions been like?

00:16:32: There's been tons of new features types of performance improvements tens of security enhancements.

00:16:38: What does be the Been the impact Node.js overall especially the last few years as we've seen some really fantastic enhancements over time.

00:16:53: This is a very good question because I have been during that transition and That's my personal opinion, okay?

00:17:01: It's but now i'm not speaking on behalf of project But when I join as an OJS core collaborator NTSC The vision of the node.js thing will

00:17:14: were,

00:17:15: it's like different.

00:17:17: We need the core is small people that needs some package they need to install using npm.

00:17:23: nojs should be just the runtime.

00:17:26: so we reduce the vulnerability risk.

00:17:29: uh we reduced the maintenance because we have less code to maintain and that's okay.

00:17:34: that's working fine for the last ten years right but with recent runtimes struggling with which package to use and the bloat of node modules package, like people installing isEvent or other small packages for simple stuff.

00:17:55: We... The team started considering a different vision, which is let's include more built-in modules in Node.js.

00:18:04: Let's make their life off our users better.

00:18:08: so then Although this increase the happiness of our users, these also increased the maintenance.

00:18:17: So we need more volunteers to maintain all those packages.

00:18:21: and This was a problem because To write a good end-performance module on NodeJS Most of the time you need to write that in C++.

00:18:34: And this also creates a maintenance barrier, right?

00:18:37: Because we need more C++ experts to maintain that piece of code.

00:18:43: But fortunately The community was happy about that and We got more volunteers than we are getting volunteers every single day.

00:18:53: so We are able to maintain all those modules.

00:18:58: The way we see the future of NodeJS, can say that we're going include all the modules of NPM built in your NodeJs.

00:19:07: but certainly if you have a good... a good point to make we are happy to include to Node.js if that makes sense, right?

00:19:16: Because once you include the Node.JS and we also make sure that If there is a vulnerability We have someone working on that...if install package There's no guarantee That their vulnerability will be fixed or found.

00:19:29: So I guess it's a win-win.

00:19:33: for now.

00:19:34: Do feel like theres little bit of barrier entry for new contributors because most of the people using Node.js are writing a JavaScript and TypeScript, yet a lot of maintenance has to happen in C++?

00:19:49: Does that make things difficult?

00:19:53: This is something that people ask me very often during their live sessions like.

00:19:57: I don't know how we can contribute to NodeJS but actually you can.

00:20:00: there many modules.

00:20:02: for instance We have released a style text which colorize your your task on terminal.

00:20:10: All of this is writing JavaScript, we don't have C++ code in this.

00:20:14: so there are many ways it could contribute to NodeJS.

00:20:18: sometimes you need to touch on C++ but the code is not difficult.

00:20:23: like most of them.

00:20:25: if you see a function working for different module that will be much easier.

00:20:33: and when create something new to make your contribution, then maintaining something that already exists.

00:20:43: People come to me and say oh I would like to improve this specific part of Node.js.

00:20:47: And i said well these might take more time because you need context.

00:20:51: You need to take a look on all the requests Because The thing you are trying to do possibly someone tried two years or three years ago?

00:20:59: You need find out request Find in context understand why it has not changed.

00:21:05: Yeah thank you for that.

00:21:06: That's a good answer.

00:21:09: So as you look across, NodeJS right now is primarily

00:21:15: for

00:21:16: the web?

00:21:18: Are?

00:21:18: there are lot of other implementations that your seeing more either IOC or backend types of implementations like who is NodeJs?

00:21:28: four in your estimation?

00:21:30: Like personally before... using Node.js was Java developer, so I've always been a backend developer and I have basically appreciated the simplicity of The language.

00:21:50: are really like JavaScript as a language.

00:21:53: So Like they're no JS user is definitely Say it can be backend developer or front-end developer full stack developer a lot of you.

00:22:11: A lot of users are also C++ developers who do embeddings.

00:22:19: I know there is Also some users from academia.

00:22:26: So we We have made.

00:22:29: we have a working group called the next time Next-ten team and every year.

00:22:37: We make survey to understand better who like no JS users are And where they work in which feels Like well, no JS is strong and what we could do better?

00:22:51: From their assaults we can see that most users people working in IT companies, startups but also corporates.

00:23:06: They are back-end full stock like there is... So JavaScript is multi purpose nowadays.

00:23:14: it's used a lot for AI just like Python.

00:23:20: so we have... A big responsibility because we have a variety of use cases that we have to cover.

00:23:33: So it's not just say backend users, It is everyone like... We powered the web but also we power back-end and AI everything else.

00:23:45: so this what makes it kind of unique.

00:23:51: And one thing very interesting I don't know, three or four years ago.

00:23:58: Well

00:24:00: we have Windows in our list of platforms.

00:24:06: why no one uses that?

00:24:09: We open a pull request to remove it from the supported list and if you look at this issue people were complaining about.

00:24:18: people are using that.

00:24:20: So if you look to the list of platforms with test Node.js builds, we'll see a lot different environments.

00:24:28: and try remove just one of them will be big portion of Node.JS users very mad.

00:24:34: so Node.js is used everywhere.

00:24:37: One thing I personally noticed was this new AI bone.

00:24:42: before using AI write code from scratch Most of them, using my personal opinion here as well are using Node.js or JavaScript in the runtime for some reasons.

00:24:58: one of then is that since AI's writing most of the code developers just need to pay attention to review code and In my personal view it much easier to review a node.js code than along JavaScript, along Java code or a different language code.

00:25:16: It's easy to maintain considering AI will write most of the code.

00:25:21: so we have some downloads notes from NodeJS and I recently tweeted about that in end-of last year.

00:25:34: NodeJs download is all time high.

00:25:38: People are using that more than ever and I feel like this might be due to the AI boom.

00:25:44: Sure, it makes a lot of sense.

00:25:46: so is Are you seeing?

00:25:50: A serious uptick in adoption of NodeJS?

00:25:53: then Like more downloads more

00:25:58: Yeah Do

00:26:04: do have a way of tracking like diversion usage like our people mostly staying up-to-date on nodejs

00:26:09: or?

00:26:10: That's a very good question.

00:26:14: People I mean we have.

00:26:17: Matthew Collina also wrote website to compare Node.js Downloads per release line.

00:26:26: We also had more on at node source and no jazz Also exports all the metric public.

00:26:32: if you want to create your own dashboard nice.

00:26:36: The fact is people there are a bunch of people still using Node.js, right?

00:26:45: So this is one of the features or issues we're trying to come back actively in the last two years when you use an insecure version which You are unsafe.

00:27:05: We're not safe, right?

00:27:07: All the CVs are applicable to you.

00:27:10: so if there's a zero-day vulnerability on OJS, you will be affected.

00:27:15: and we wrote modules, we wrote different initiatives like one of the initiative that we did was... If you simply run in our terminal npx space is-my-node-vulnerable And when you run it then same danger if you are using an insecure version of Node.js or a good output and we also try to issue CVs to end-of-life lines, right Michael?

00:27:47: Yeah so this is a problem that goes beyond Node.JS.

00:27:57: This is the whole open source software suffers.

00:28:02: The reason is when you have a vulnerability, You issue a CVE.

00:28:08: So the security scanners will warn you like the environment was warning.

00:28:15: hey!

00:28:15: You have a CV but what are?

00:28:17: project goes end of life?

00:28:18: Like there's no way for the consumer to know that That project is unmaintained.

00:28:25: so It it's clear that there isn't need in ecosystem to have something similar to CVEs, but for end-of-life software.

00:28:38: And it's also kind of a problem for maintainers because we don't want to maintain like... We are volunteers and we do not want to open the end-off life software so that we will not issue CVE s for End Of Life Software.

00:28:57: But we know that software is not secure.

00:29:01: So last year we tried to do something about it and so, let's issue a CVE stating that those versions are insecure because they aren't maintained.

00:29:16: And we did that!

00:29:17: It caused huge chaos in the ecosystem.

00:29:24: We went on chat with the CVE board about this problem.

00:29:32: So at the end, our CVE was revoked.

00:29:35: but I think we raised these issue of end-of-life open source software.

00:29:47: Right yeah i could see that being a huge problem.

00:29:51: Trying

00:29:52: to try and think in next place you mentioned earlier with TypeScript right?

00:29:58: We've talked little bit about JavaScript and TypeScript.

00:30:03: I have you always used Node.js with TypeScript, but it's not the easiest to set up?

00:30:09: You've maybe made some improvements in that process recently.

00:30:12: Can you tell us about that a little bit?

00:30:15: So you can just run TypeScript directly without any library or installing anything.

00:30:22: Just run nodefile.ts and it works.

00:30:30: I've started to work on this in July, so it's been a year and half.

00:30:37: Now the TypeScript support is stable... ...and present at nodes number twenty-two, twenty four or twenty five.

00:30:48: The peculiarity of the native support is that NodeJS will not support all TypeScript syntax available.

00:30:56: we decided to restrict the syntax supported so that users don't need source maps.

00:31:05: You can run TypeScript and your errors will be thrown at the right place, everything would be in a better place because we simply remove the TypeScript syntax then replace it with blank space.

00:31:22: It has been very stable.

00:31:24: like where are few bugs?

00:31:25: It works fine.

00:31:29: So I'm pretty happy about it.

00:31:32: Well, that's awesome The huge improvement.

00:31:36: so what is

00:31:39: Next

00:31:39: like?

00:31:40: What are the next big things for the project do you think or for each of you personally?

00:31:45: we have a lot of things That happens in parallel.

00:31:51: We might not be the best person to talk about a single executable apps or different topics, right?

00:31:57: Yes But one thing that we have been discussing for the last two collaborators summit is The change of the Node.js release schedule.

00:32:08: Currently no JS issue will launch two separate major releases per year Right?

00:32:14: so this here will help node just twenty six and twenty seven And that's by definition.

00:32:23: We have a schedule, companies rely on the schedule but also based on these stats people don't use their current versions which for instance no just twenty-five, not just twenty three, twenty one... People don't do this because they were meant more to develop them.

00:32:43: for the maintainers imagine if we release just one release line per year.

00:32:49: It means that several majors are released on Node.js main today, they can only be launched next year.

00:32:59: so this makes the development difficult because we need to wait a year for another ProQuest Node.JS Main.

00:33:07: We were discussing and it's good timing In no in two thousand twenty six, and then we could stop here like twenty seven into ten.

00:33:21: twenty-seven make the life of everybody much easier.

00:33:25: And We are also evaluating different proposals including issuing LTS version every year.

00:33:36: So if you want to upgrade not just when it's haven't your good to go that will be out yes But we are comparing all their maintenance status because One big problem is when we want to issue a secret release and we have more than three active release lines.

00:33:52: For instance, in the last Secret Release We had four Active Release Lines.

00:33:59: Twenty, twenty two, twenty-four and twenty five for each one of these release lines... Actually!

00:34:08: ...we need one Releaser one partially, Marco did three and he won but this is time consuming.

00:34:16: So imagine that we have a one-releaser for each of the release lines plus their security release steward.

00:34:23: so we need five people For each one of these volunteers.

00:34:28: We need to create a proposal, run the CI Run the system compare the system see if there's no impact.

00:34:36: Sometimes The patch that we have for main doesn't work for Node.js-Twenty, so we need to create a new patch.

00:34:43: So this takes a lot of time.

00:34:45: That's why Secret Releases are hard.

00:34:47: When you reduce one release line which means We don't need five people or four This reduces the maintenance And when there is just one or two active release lines it will be a dream.

00:35:06: This is one problem that recent RealTimes doesn't have, right?

00:35:11: BUN has only one active release line.

00:35:14: Dino has two I guess or three so they don't fall in that rule yet.

00:35:20: but you know...

00:35:23: What do think some of the barriers are to upgrading?

00:35:26: Is it insisting upon being on an LTS release?

00:35:30: Just the effort involved and doing updates?

00:35:33: Are there commonly like compatibility issues with a lot, the vast number of packages out there.

00:35:41: Do you end up with like compatibility issue which makes upgrading hard?

00:35:45: Like what is that barrier there?

00:35:47: do think

00:35:50: so.

00:35:51: we as project tend to be very conservative with some major changes.

00:35:57: So between measure and another You will not see crazy, some major changes.

00:36:06: Historically it has been always easy to upgrade and that is because we put a lot of effort into preserving the compatibility.

00:36:24: but I think is within the ecosystem itself because packages tend to be very old, users tend to use packages that have been around for ten years more.

00:36:48: Packages that predate and PM things are very old.

00:36:54: so with time like the packages can break.

00:37:01: And it's not just something that happens over one release, It is something to happen in ten major releases.

00:37:11: and since JavaScript has historically always had a very large supply chain if one of those packages breaks somewhere inside your stock with dead node version you cannot upgrade.

00:37:27: So that, I think is the major issue.

00:37:36: and i would also say deprecations because at some point we try to deprecate stuff.

00:37:43: There are certain modules within Node.js that have been deprecated for more than ten years, and we cannot remove them because it will break a lot of people.

00:37:53: so as Rafael mentioned... We had the tool called Canary in Goldmine short for SIGIM where we test if an node build breaks some popular packages to make sure they don't break anyone And that's our way to, let's say preserve the compatibility.

00:38:18: But it is not a hundred percent guarantee.

00:38:22: Sure what?

00:38:24: Is well we talked about this little bit but What does he risk two folks who don't keep up and continue staying on the latest releases as A consumer, I think we've talked about that a little bit but what about if i am publishing npm packages like and im not keeping up with the node version.

00:38:50: That feels maybe an issue.

00:38:52: I have a talk that i delivered in some conference.

00:38:57: That's called five ways, I could have hacked NodeJS.

00:39:03: If you watch the talk You'll see that if you are using nodejs fourteen or sixteen Possibly I could open the calculator on your computer In our windows machine.

00:39:16: so uh...if I can open the Calculator I can also open anything i want, whatever it wants.

00:39:24: So staying out of date is a big problem because for instance NACJS issued CVE recently and it was critical... A lot people were talking about that.

00:39:41: you could get remote access to your server by doing some crazy stuff.

00:39:47: If you haven't upgraded your next app, you are vulnerable to that right?

00:39:53: So the same applies with Node.js.

00:39:56: if we're using Node.JS Sporting or Sixteen all of these high and critical CVs which have been issued in past year prone to affect your version.

00:40:08: Of course, not all of them applies because some vulnerabilities affects new features that were not released on Node.JS-IV.

00:40:17: but it's always important to keep up the date and as Marco mentioned we tend be very conservative in several majors.

00:40:30: sometimes they break people.

00:40:36: When you look to the people using NodeJS-IV or NodeJAS-VI, it's because they tried to upgrade to NodeJs-VIII which is the next LTS version but couldn't because of many breaking changes.

00:40:53: It was a mistake But its expected from some same major releases.

00:41:00: People just need invest more time on that.

00:41:05: But by the NodeJS team, even though it's a major upgrade we try to include as less as break and chain as possible To avoid people staying in an end-of-life version of NodeJs.

00:41:20: So I know basically all the major cloud providers do pretty good job forcing their customers reasonably current.

00:41:32: with Node.js You get security warnings well in advance, it's like you've got to upgrade.

00:41:37: I assume that is helpful.

00:41:39: So are you seeing most of the

00:41:43: lag and

00:41:44: version upgrades happening off major cloud providers then?

00:41:50: For my work i maintain old Node.JS release lines.

00:41:54: My company has this business And we have a lot customers that are huge corporations and they are just too slow to like in their process, to follow the Node.js release schedule.

00:42:12: They tend to lag behind because either they are in sectors like Sectors that are heavily regulated And for example to go through a lot of testing before using certain node version and they tend to stick with them.

00:42:39: Usually cloud providers are, more after the end of life.

00:42:50: For example, not twenty goes and have left.

00:42:54: in April it will be available on AWS Lambda for a few months after that.

00:43:00: then so people can migrate but from my experience is mostly huge corporations.

00:43:13: One thing, one interesting take here is that as you said cloud providers they do a good job of forcing people to upgrade their version.

00:43:22: However what most people don't know Is that?

00:43:25: Most of the attacks happens to developers not due to production machines.

00:43:31: So if

00:43:32: your installing an app and using an insecure version You might be affected like.

00:43:40: I shared that also on all my talk.

00:43:44: It was before the AI, right?

00:43:48: People were trying to solve a problem.

00:43:50: they go through Google.

00:43:51: They asked something.

00:43:52: possibly they go to Stack Overflow or any other forum where people say oh install this magic package and then although

00:44:00: The Magic

00:44:00: Package returns the expected result you were expecting, behind the scenes it might be leaking some files to through the network.

00:44:13: It might be looking into something because when you run a Node.js app any package you install will have the same permission as your user.

00:44:22: if we're in a process with our users usually has good amount of access to your machine that packages would have the.

00:44:33: If you install a package, if you import that package this package will have access to your machine.

00:44:39: That's why there are some initiatives like the permission model that attempts to block resources for your machines.

00:44:46: but people need to understand most of their target is not production machines it's you!

00:44:55: You were the vulnerable factor in our company.

00:45:00: Yes Yes, absolutely.

00:45:06: So what are some of the external forces that you're seeing?

00:45:11: That are influencing the growth or change of NodeJS over the next few years?

00:45:19: I think AI is the biggest one.

00:45:24: so right now we We haven't seen a direct effect But i think It has become easier to develop features.

00:45:43: And I have seen a lot of... A use case is that recently, Matteo Collina opened pull request To support the virtual file system and it was mostly Yeah generated with HumanReview.

00:46:02: AI enables contributors who are already experienced about Node.js and like they know, They could do it manually but It makes it faster and helps them to ship Many more features that otherwise would have been impossible because people have limited time.

00:46:24: So I think this could be a major growing factor Because people will send more patches.

00:46:33: There will also be a lot of AI slop in there, but if contributors are trusted

00:46:42: and

00:46:42: like people know what they're doing it's huge win for the project.

00:46:46: Very

00:46:46: good.

00:46:47: so from your perspective that the biggest challenge

00:46:52: for

00:46:54: The influence of AI right now is just making sure you Getting trusted contributions.

00:47:00: It's more it's more.

00:47:01: how do you validate the folks making your bug reports and making?

00:47:05: Your pull requests Because you want to make sure that there is a A human who was qualified this doing the review as that kind of where you're at in moment

00:47:19: I would say right now we are in sort over.

00:47:24: so for contribution it's easier to review a contribution even though its AI generator for someone who is trusted because you already know that person knows the project and has reviewed, code generated.

00:47:43: For new contributors they often don't know how Node.js works so they completely trust AI.

00:47:49: And AI makes lot of mistakes.

00:47:51: like it's a tool, so you need to know how use that tool.

00:47:54: You have certain knowledge.

00:47:57: So trust is definitely like key factor.

00:48:05: But I think its not enough because It sort of discriminates between new contributors and old contributors And a new contributor would send patch which totally legit people would not review it or would not, like let's say trust the new user.

00:48:30: So I think this might change and I think AI reviews helps to flag immediately bad PRs from... PRs worth reviewing.

00:48:50: I know that the NodeJS website team has enabled co-pilot reviews on the repository, we are still hesitant to do that on node because of the noise produced by AI agents.

00:49:06: but i think it's...it will be inevitable in the future.

00:49:12: yeah

00:49:15: Are there any significance Enhancements or features that you think are coming down the pipeline, and then you can talk about at this point?

00:49:26: Or You see me just saying very stable over.

00:49:29: The next couple of years

00:49:33: Features that already exists today will remain a stable.

00:49:36: we don't plan to To break the word.

00:49:41: I mean for instance People sometimes complain that they know JS it's ever might be slower.

00:49:50: Yeah, for instance There is Festify, which is an HTTP framework that's fast.

00:49:56: If you compare Festify with NodeJS we see that Festify is faster and people might be wondering why a framework or library built on top of NodeJs can be faster than the built-in HTTP module of Nodejs?

00:50:15: We already know how to fix the HTTP module Blazing fast.

00:50:22: the problem is that all the changes requires breaking people.

00:50:25: Yeah, we can't do that.

00:50:27: We know just should remain in stable.

00:50:30: we can do a small portions of simple major requests but Telling users that no just twenty six will have a blazing fast if it be module That's not fair because that won't happen.

00:50:43: otherwise People with be on not just twenty-four for years, because that we will break then.

00:50:51: So... We are doing a lot of performance improvements to different modules especially to buffer and to ADTP.

00:51:02: also most of the ADTP improvement they would be opt in.

00:51:06: if you can't enable it by default as I said It will break the board.

00:51:12: We are in contact with tools like Express, we have a good relationship.

00:51:17: I'm also part of the express team and FastFight.

00:51:20: We could use those new directives on Express and Fast Fight to make it faster but for is also being improved.

00:51:31: And one thing that i would like to bring attention Is People love sharing micro benchmarks on the web and The fact is micro benchmark most of the time for measuring Node.js or any JavaScript app.

00:51:49: You are doing it wrong.

00:51:50: I have a lot of content about that blog post.

00:51:53: Sharing that micro benchmarks is very difficult to do.

00:51:58: well I

00:51:59: wrote a module called bench node that basically disabled all in giant optimization.

00:52:04: So you can have, really comparison between Apple to Apple when you are doing algorithm comparison benchmark comparisons and when do like micro benchmarks?

00:52:19: You just measure as more portion of your code That might be optimized the way.

00:52:26: so we're measuring a no-code.

00:52:28: Okay, and the thing is V-Eight is quite smart.

00:52:31: The engine NodeJS use.

00:52:33: it's quite smart sometimes if you run your app for ten seconds or thirty seconds just For a benchmark comparison It won't be that fast as If you ran that four three days four days because between that period v eight could optimize our app even more then during those thirty seconds, so you are not making a fair comparison.

00:52:56: So what I can say is that we're working on performance and security And there's lots of other contributors in different fronts who couldn't even tell because they cannot follow all the updates.

00:53:10: Now as an engineer i really appreciate the relative stability of NodeJS project versus some projects that I utilize because it's a lot easier to make the upgrades.

00:53:25: You have fewer breaking changes, It is

00:53:27: more

00:53:28: steady release cadence and everything And so as much as i'm sure a lot of folks appreciate that.

00:53:34: Do you ever get pushback on?

00:53:36: why aren't you staying this fast in terms of releases?

00:53:42: do think there are any negativity seen around when Places the doing two three major releases a year.

00:53:53: Um, I don't think we.

00:53:56: We have the opposite issue if ever.

00:53:58: i think our users once won't has to go slow and The reason is that corporates?

00:54:06: That use no gs.

00:54:07: they want to do some for measure upgrades because They like.

00:54:11: they have to do security assessment.

00:54:13: They had to do all of the paperwork

00:54:15: And

00:54:16: they they prefer to have less major per year.

00:54:21: and that's one of the, also the drivers.

00:54:25: That pushes us to change the current release schedule which is two major per years, December Major Per Year with one being a non-LTS.

00:54:39: but there is a bit of contradiction between what corporate ones, between what user wants.

00:54:47: So users want a lot of new features they want A lot of New Like.

00:54:56: they see Dino They see bun and they won some the stuff that they see there.

00:55:02: I also on that in Node.js.

00:55:06: And at the same time like For some users we move too fast for some uses We moved to slow.

00:55:15: It's it depends on who you ask.

00:55:19: I think we do a good job.

00:55:21: We always ship new new features, we like we make thoughtful decisions Like Supporting TypeScript out of the box.

00:55:35: It's not hard.

00:55:35: You take type script compiler and you put it inside project And boom!

00:55:40: You have typescript but that... But That is NOT a good solution.

00:55:48: It took years of thinking, things moving before we found better solutions to that and lots people don't understand.

00:56:02: they only say why it took you ten years to support TypeScript?

00:56:06: Because these are the ones.

00:56:10: We kind of live in a contradiction where we do too fast or to slow depending on you.

00:56:17: Yeah,

00:56:18: for sure it makes sense.

00:56:20: Thank You for the answer.

00:56:23: All right so I'll do this one at a time.

00:56:25: Raphael What would you say is the number-one takeaway?

00:56:28: You want from the audience today?

00:56:33: Be careful with that back as you stole.

00:56:39: I mean yeah no i guess that the main takeaways is stay up to date with not Node.js release, but it's stayed up-to-date with Node.JS project.

00:56:53: I know that It might be hard But if you watch some issues of Node.js and some poor request that gets in You get some context of how Node or how the node.js version In the next version will be looks like Like How we can Get the context to prepare your app beforehand, because sometimes no jazz release and you're a senior major.

00:57:16: And You don't know that this has been discussed for three years?

00:57:19: Now Your App needs To change in Three days.

00:57:22: what could be happened Could have discussed with your team For the last three Years.

00:57:28: So I guess That's it.

00:57:33: What about you Marco?

00:57:33: What is your number one take away from today?

00:57:40: I would like people to understand that unlike other JavaScript runtimes, Node.js is backed by volunteers.

00:57:51: so we have a lot of expectation to deliver and sometimes things can get tricky.

00:58:04: So sometimes releases can get delayed Sometimes There might be regressions, there by the thing that are not desirable.

00:58:17: but we do our best with like the tools and the founding we have.

00:58:26: And if someone wants to make Nogia better they're very welcome to participate to our meetings, contribute.

00:58:42: We are open governments.

00:58:44: it's we're a community so everyone is welcome to participate.

00:58:48: nice

00:58:49: great thank you.

00:58:51: all right Marco.

00:58:52: uh where can people reach out and follow you online?

00:58:56: And Is there anything that you have coming up?

00:59:00: um do like tell us about.

00:59:04: I'm Active on all major social media.

00:59:08: You can find me by name and surname is here Marco Polito or on Github, which is my name dash so named Marko-Polito.

00:59:24: I Have been working on an experimental feature called Experimental config file And i'm working on that.

00:59:29: So if people are interested they can look at my github and follow that development.

00:59:37: Nice, awesome thank you!

00:59:39: And Raphael what about you?

00:59:40: Where could people follow you... Yeah

00:59:44: I'm available on all social medias also when I try to use how file gss everywhere, but sometimes someone take that.

00:59:55: so i put an underscore before they have lg ss.

00:59:59: So uh i'm also available on youtube and twitch because Sometimes.

01:00:04: I tried to do live streams helping people to contribute.

01:00:07: to know jasso you can follow me there.

01:00:10: awesome Very good.

01:00:12: hey thank you both so much for being with us today.

01:00:16: Really appreciate your time.

01:00:18: Thank You For Having Us

01:00:21: Yeah, thank you for the invite.

01:00:22: It was great

01:00:23: Great.

01:00:24: So thanks again to everyone watching For joining us on another episode of Signals And please be sure To follow DevMio at divm.io.