What Deno Gave Node.js

Building an MCP server? Here’s what it takes to run one in production on data that actually matters.Luca and Matteo are joined by Roberto Bianchi, Staff Software Engineer at Spendesk, who shipped an MCP server that gives AI assistants access to company spend data: payables, suppliers, budgets, purchase orders.Roberto walks the path from OpenAPI spec to AI tool call: generating type-safe clients so schema changes fail in CI rather than in a broken agent call, reusing existing OAuth, scopes, roles, and tenant boundaries instead of building a second auth stack, shipping retrieval-only first and gating write actions behind a security review, and running internal workflows through the exact same validation and authorization pipeline as external AI calls.The takeaway: an MCP server is just another API surface. With the right tools, treating it like one is what makes it easy.

Deno joined Cloudflare, and with the runtime winding down over the next year, Luca and Matteo look back at what it leaves behind.Deno pioneered web standards on the server and did the hard work of adapting fetch for Node.js, collaborated on Node’s own design decisions, and pushed the whole ecosystem forward.They also give it an honest postmortem: the two wild bets that didn’t survive contact with reality (URL-based package resolution and the “secure by default” permission model), and why trying them was still the right call.

Jarred Sumner’s argument is that for JavaScript and TypeScript to stay relevant in an AI world, where moving a codebase between languages is suddenly cheap, they have to get as fast as Rust or Go.Luca and Matteo work through what that costs. AssemblyScript already solved it by not being TypeScript. Porffor solved it by compiling JavaScript and keeping every check. Bun is trying to sit in the middle, and the middle is where the problems live: TypeScript is not one language but a multiverse of them depending on your tsconfig, and publishing raw source turns one definition per dependency into roughly ten times the work for every checker downstream.There is also the one requirement the TypeScript team gave Node.js when type stripping landed: never run TypeScript from node_modules, because it breaks the ecosystem. Push the idea far enough, and you get types enforced at runtime, which is not JavaScript and not TypeScript. Different language, different runtime.

NodeConf EU came back after a year off, new team, new country, and one deliberate decision: nothing about AI on the schedule.What filled it instead ranged from Node.js core internals, such as the new Foreign Function Interface or Garbage Collector internals, to an “instruction manual” for the EU CRA, and a Tokio PR.Luca and Matteo debrief the whole thing. The talks that landed, the ones they are still chewing on, and what changes for 2027.

Here is the claim.For an experienced programmer, reading AI-generated code is not diligence, it is a bottleneck. Complex code takes longer to read properly than to write from scratch, so the review you think you are doing is not happening.Luca and Matteo pick that up and pull on it until something gives. Where does it hold? Where does it fall apart? If it is true, what happens to review, to ownership, to the junior who is still learning the craft? No conclusions promised.Just two engineers working through a question the whole industry is currently avoiding.

On September 15, Accomplish AI revealed Heapjack, a method that lets someone run any command from OpenAI Codex Desktop, even in its strictest read-only mode, without asking for approval. If you clone a repo and ask a question, the repo’s author could take control of your machine. The issue was reported on August 12 and fixed in eight days.The headline claims the sandbox was escaped, but Matteo and Luca, looking at it from a Node.js perspective, see a different story. The macOS sandbox actually worked. The real problem was with the JavaScript inside: OpenAI ran both its trusted code and the agent’s untrusted code in the same Node process, separated only by a vm context and a secret token. The untrusted code took a heap snapshot, found the token, and sent fake commands through the same channel as the trusted code. A context is not a sandbox. The Node documentation has made this clear, in bold, since 2017.This discussion is about why teams keep making this mistake and what a better design would look like. Matteo and Luca talk about:✅ What the vm module is really meant for, and why new teams often confuse "context" with "sandbox" every few years✅ The appealing but incorrect idea that V8’s sandbox could have stopped this, and what Node’s actual position is on the matter✅ Why a token that lives next to the code it is meant to keep out is not a secret✅ What OpenAI seems to have changed, and why people outside the company cannot confirm it✅ Platformatic’s new secure-eval-worker shows what it looks like to run untrusted JavaScript inside Node when you take the warnings seriously. The most honest part is the README, which clearly explains where the security boundary stops.There is a lesson from nine years ago: the system that decides what is allowed should not run inside the thing it is supposed to control. Homework: Before you release an agent, read the second sentence of the vm documentation.

Workflows function as an append-only log, and so does HyperCore. Luca explored that line of inquiry and, as a result, produced a 50-page paper in which agent state is replicated peer-to-peer, without the need for a central repository or a cloud provider in the middle, and all of it runs entirely within your own network.This episode explains the origin of the idea, how the various components fit together, and tells the enterprise why it should question the fact that its agentic workloads are leaving the building.

What if you could execute a package without ever unzipping it? What if npm had no central server, just a peer-to-peer mesh with cryptographic integrity baked in?No slides, no answers, no agenda.Just Luca Maraschi and Matteo Collina following the current wave of NPM, and GitHub outages to their logical conclusion: maybe it's time to imagine a completely different world.

Most develpors skip release notes. You update a library, the tests pass, you deploy, and everything seems fine. Later, someone spots that 0.025% of requests are failing; not enough to set off alarms, but too steady to ignore. This is what happens with the HTTP/2 upgrade you might not have noticed. Undici 8 and Node 26 now automatically use HTTP/2 if the server prefers it, so if your internal load balancer advertises HTTP/2, you’ve switched over without changing any code.In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina talk about the HTTP/2 bugs that showed up when real users started running into this new default. There were two bugs in Undici and one in HAProxy's Edge Ingress Controller. All of them were quiet, hard to reproduce, and shared a common cause: a GOAWAY packet that should have triggered a transparent retry was treated as an error, and a race condition in Undici's pool was closing active connections it thought were idle.In this episode, we cover:✅ How ALPN protocol negotiation works, and why updating Undici quietly shifted internal traffic to HTTP/2 without anyone noticing✅ The GOAWAY bug: why Undici sent a server's graceful reconnect signal back to the user as an error instead of handling it smoothly as the RFC requires✅ The race condition in Undici's pool and client counters, and how in-flight requests were dropped when the pool closed a connection it thought was idle✅ The HAProxy bug that made things worse, and why a protocol that has existed for years still causes problems in production infrastructureThe takeaway?HTTP/2 is a powerful protocol with features like multiplexed streams, no head-of-line blocking at the application layer, and better resource use at the kernel level. But in a private Kubernetes network with low latency and no packet loss, the benefits are not as clear. If your infrastructure upgrades in the background, you need to find out what breaks before your error rate goes up.

There's a growing belief that AI-generated code is so fast and cheap that foundational, general-purpose tools are obsolete. The argument goes: why optimize for everyone when you can generate code tailored to each workload? Some claim frameworks are outdated and the future is ad-hoc and disposable. Luca and Matteo challenge this view with benchmarks, white papers, and production experience.In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina argue that AI increases the need for foundational infrastructure. AI can generate code, but it doesn't account for Event-Loop Utilization. It misses why async gzip on a single-core container can create an unbounded queue and OOM-kill a process in 300 milliseconds. It does not manage version skew, worker lifecycle, or cluster-wide scheduling. The runtime handles these. As AI accelerates workload delivery, the foundational layer becomes more critical.In this episode, we cover:✅ Why the "ad hoc is cheaper" argument fails when you examine what frameworks actually provide and what AI-generated code assumes is already managed✅ Watt as a foundational layer: lifecycle management, ELU-based scaling, worker health, and scheduled task coordination are not features that can be generated on demand and discarded✅ The white papers for proactive and ahead-of-time scheduling show that the hardest infrastructure problems require accumulated domain knowledge, not a new solution for each workload✅ How the growth of AI workloads is driving the need for a new foundational layer, and why teams that invest in building it now will shape the next decade of the stackThe takeaway?AI makes the case for investing in foundational infrastructure stronger than ever. As AI generates more code, it relies on a runtime that understands Node.js internals, manages the operational layer, and is resilient to production failure modes. Frameworks are not legacy thinking. They are what make AI-generated code safe to deploy.