The Node (and more) Banter

Episodet

• 
  Imagine a world where npm... 16.09.2026 36min

  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.
• 
  The HTTP/2 Bugs Hiding in Plain Sight 09.09.2026 25min

  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.
• 
  Will AI Kill the Framework? 02.09.2026 31min

  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.
• 
  Every Week the Same Spike. Every Week Your Autoscaler Is Surprised. 26.08.2026 31min

  Every Friday evening, your traffic goes up. Each weekday morning, your app becomes active again. Overnight, things slow down. Your autoscaler has seen this pattern many times, but tomorrow it will act like it’s new. It waits for a metric to cross a threshold, then starts adding capacity, which means you get a period of slower performance while the pods catch up. The real issue isn’t the pattern; it’s that the system keeps forgetting.In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina talk with Ivan Tymoshenko, Staff Software Engineer at Platformatic, about the ICC Planner. This new layer sits on top of ICC's real-time scaler and looks ahead from seconds to weeks. Instead of treating every traffic spike like it’s new, the Planner learns repeating capacity patterns from ICC's ELU and heap signals, predicts pod demand by time of day, and turns those patterns into suggestions that operators can review, compare with past data, and approve. When a suggestion is accepted, capacity is ready before the expected load arrives, so you’re not always playing catch-up.In this episode, we cover:✅ Why real-time scalers always miss the first few seconds of recurring demand, and why short-horizon algorithms can’t solve calendar-based issues✅ How the Planner uses ELU and heap signals instead of just request counts, and why this matters for workloads that seem similar but are actually different✅ The difference between baseline suggestions and pattern suggestions, and how the rules allow Friday-specific and everyday settings to work together without conflict✅ Why accepted suggestions are snapshots that operators control, not live model outputs, and what this means for production safety when the model updates overnightThe takeaway?Reactive scaling and scheduled scaling are usually seen as separate options, but ICC combines them into one control loop. The Planner takes care of what history can predict, while the live scaler manages the unexpected. This way, your Friday peak gets the needed capacity before the first request comes in, and you don’t have to pay for extra capacity the rest of the week.
• 
  Who Gets to Decide When You Can Use AI? 19.08.2026 33min

  Matteo works on cybersecurity for Node.js every day. AI has become essential for managing the flood of new vulnerabilities. Still, Fable blocks anything that interacts with a pointer, Anthropic's frontier models are off-limits for security research, and the US government can change the rules at any time. This leaves open source maintainers and security researchers without good options. So Matteo decided to run AI models locally. Luckily, the creator of Redis had already built just what he needed.In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina talk about Dwarf Star IV, Salvatore Sanfilippo's custom setup for running open-weight models locally. They discuss what it really takes to run a 304 billion parameter model on regular hardware. The conversation covers everything from the aggressive quantization technique that fits DeepSeek V4 Flash into 128 gigabytes, to the real challenges of self-hosted AI, like power outages, hot European summers, and NAS units overheating while you're away. It's a straightforward look at what AI sovereignty means in real life.In this episode, we cover:✅ How Salvatore's quantization technique keeps the routing layer at high precision while pushing the experts down to two bits, and why that's what makes a 304B model fit on a MacBook Pro or a GB10✅ Why frontier models are effectively blocked for Node.js security work, and why that may be putting everyone at more risk, not less✅ The freshman who found a valid, convoluted vulnerability using Kimi, and what it says about AI democratizing security research on both sides of the fence✅ Why the spike in downloads for Keet, data retention laws, EU chat control, and companies running their own AI hardware are all the same story: infrastructure freedom is winningThe takeaway?The gap between what frontier models can do and what they'll let you do is becoming a real problem for legitimate security work. Local models close that gap, but the entry cost is still high, and the capability gap is real. What's changing is that the reasons to go local are no longer just technical. They're political.
• 
  Should You Block the Event Loop? 12.08.2026 27min

  Every Node.js developer learns the same rule on day one: never block the event loop. Async is good, sync is bad, and the libuv thread pool is your friend. Then a real customer brought Luca and Matteo a compression problem that turned all of that upside down. Turns out, the rule is only half the story, and the other half can bring your app down.In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina dig into one of the most counterintuitive findings they've encountered while working with a customer: that for CPU-bound operations like gzip compression, async code running on a single core doesn't just underperform; it creates an unbounded queue that can take your application down with an out-of-memory explosion. And sync, the approach everyone told you to avoid, can give you a 50 to 120 percent throughput improvement.In this episode, we cover:✅ Why the libuv thread pool becomes a bottleneck when Node.js is deployed on a single core, and why four async threads competing for one CPU is worse than doing it synchronously✅ The hidden DoS risk in async compression: why the main thread keeps accepting requests while the libuv queue grows out of bounds and runs you out of memory✅ Why event loop delay alone is not enough, and why Event Loop Utilization tells you what delay misses entirely when doing CPU-bound async work✅ The PR Matteo opened to fastify-compress based on these findings, and the numbers that came out of itThe takeaway?Async is not always better. For CPU-bound operations like compression and cryptography, the overhead of thread contention on a single core can cost you more than the event loop block you were trying to avoid. The right answer depends on whether you can control back pressure from your source, and most teams haven't asked that question yet.
• 
  Nitro Builds the Server. Who Runs the Fleet? 05.08.2026 26min

  Nitro gives you a clean, portable server. Whether you use it on its own or with Vite, you get consistent builds, familiar routing, and a smooth development workflow. But Nitro doesn’t explain what to do when you have several instances and a cron job, or when you need a gateway, metrics, and worker health checks. Nitro handles the server, but someone still has to manage the whole fleet.In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina talk with Paolo Insogna, Principal Software Engineer at Platformatic, about @platformatic/nitro. This new Watt feature connects Nitro to the Watt runtime without changing your server, build, or development workflow. No matter if you use a standalone Nitro API, a Vite-plus-Nitro frontend, or an app built with Lovable, Watt takes care of operations while Nitro keeps working as usual.In this episode, we cover:✅ How @platformatic/nitro works for both standalone Nitro apps and Vite applications that use Nitro as a plugin, and why the distinction matters for your development workflow✅ What Watt adds without changing your app: gateway integration, HTTP metrics, HTTPS, Event Loop Utilization monitoring, and multi-worker reusePort support✅ The duplicate scheduled task problem. Why Nitro starts a cron timer inside every instance, and what @platformatic/nitro/scheduler does to give Watt ownership of the clock✅ How ICC takes over cluster-wide scheduling: one cron per job across the entire fleet, with run history, pause controls, and healthy-instance targeting, while your task code stays inside NitroThe takeaway?Nitro is great at building servers. It was never designed to run a fleet. One line in nitro.config is all it takes to hand the operational layer to Watt and ICC, and your routes, handlers, build output, and scheduled tasks stay exactly where they are.
• 
  Your Bug Fix Will Never Reach the Runs That Need It 29.07.2026 30min

  You spot a critical bug in production, fix it, deploy, and feel relieved. But then you notice the workflows that need the fix most, like 30-day subscription cycles, compliance timers paused for months, or approvals waiting on a signature, are still stuck on the old version. They never get the fix. That’s not a safety net. It’s a risk that never disappears.In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina discuss Platformatic’s new research paper on the Workflow Upgrade Risk model, or WUR. This data-driven method replaces the usual “pin everything” approach with a measurable score. Using only the telemetry your workflow engine already saves, WUR rates each in-flight run and shows which ones can safely move to the new version, which need a human check, and which really must stay pinned. No dry runs, sandboxes, or shadow execution needed.In this episode, we cover:✅ Why pinning by default isn’t the best choice for enterprise workflows, and what “forgone-fix exposure” really costs your organization✅ How the WUR model uses your engine’s existing event log to create an upgrade risk score for each run, and why having zero false negatives across 64,920 verdicts is important✅ The three-part policy that replaces the simple pin-or-deploy choice: migrate what’s proven safe, review what’s uncertain, and only pin what’s truly incompatible✅ Why the model backs up what engineers have always thought: small, frequent deployments are safer. Plus, how WUR lets you break any release into a series of deployments, each with a clear risk limit.The takeaway?Durable workflow engines already pay the storage cost of complete execution histories. The WUR model converts that cost into an analytical asset. For any enterprise running long-lived workflows, payment processing, compliance, approvals, drip campaigns, the question is no longer "is it safe to deploy?" It is "which runs are safe to move, and which ones do we owe a fix to?" Now you can answer both before you ship.
• 
  Are Your AI Agents Really Production Ready? 22.07.2026 27min

  Eve is a well-designed open-source agent framework. It offers a clean programming model, filesystem-based instructions and tools, and durable sessions built on the Workflow SDK. However, running Eve in a real enterprise Kubernetes environment needs extra infrastructure that isn't included by default. We built that missing piece, and in this episode, we share the full story of how Watt made it possible.In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina are joined by Paolo Insogna, Principal Software Engineer at Platformatic. Together, they walk through every integration point between Eve and Watt, covering everything from standalone agents to Eve embedded inside Next.js applications, from self-hosted workflow state with @platformatic/world to distributed step execution across Kubernetes pods and workers.In this episode, we cover:✅ How @platformatic/eve connects Eve to Watt as a first-class capability, giving it lifecycle management, HTTP metrics, and a production runtime without any changes to your agent code✅ How @platformatic/world replaces Vercel's hosted workflow infrastructure with PostgreSQL-backed state, queues, and retries that run inside your own cluster✅ How Eve steps are distributed across Kubernetes pods and Watt workers, and how ICC manages retries when a process stops in the middle of a step✅ The role of skew protection in durable workflow execution, why a workflow that starts on version 1 must finish on version 1, and how ICC and the Workflow Service work together to enforce that guaranteeThe takeaway?Eve manages the agent model. Watt and ICC take care of everything that Kubernetes and the Enterprise require, including deployment lifecycle, distributed execution, scaling, and version-safe workflow replay. The integration is deep, and this episode covers all of it.
• 
  Is AI Saving Open Source Or Just Using It? 15.07.2026 28min

  People keep saying that AI helps developers get more done. But few are asking who pays for the computing power, tokens, and time needed to keep the open-source projects behind AI running. Node.js maintainers often use their own servers, patch together free subscriptions, and struggle to get access to the latest models they need to strengthen the core infrastructure that supports the AI industry. So who ends up paying for all this?In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina talk about their daily work with the latest models like Fable, Grok 4.5, and Codex, and what it really takes to run agents for a large open-source project. They discuss seeing 20-30% performance gains in Node.js micro-benchmarks with Fable, leaving tmux sessions running for months, and facing the tough fact that Node.js still can't access the advanced cybersecurity models it needs for protection.In this episode, we cover:✅ How Matteo uses Fable with Claude Code's slash goal operator to deliver real performance improvements to Node.js, and where it still falls short✅ The difference between short-context laptop agents and long-running server agents, and why your MacBook isn't the right place for the latter✅ The open source compute problem that often gets overlooked: who pays for the tokens and machines when most maintainers are volunteers?✅ Why Matteo can't use Fable to strengthen Node.js against security threats, and what it means that Node.js isn't included in Project GlasswingThe takeaway?AI is bringing new life to open source contributions in ways that would have seemed impossible just two years ago. But it's also creating a new kind of inequality, dividing projects that have access to the latest models from those that do not. Node.js is used in almost every AI product available today. At the very least, the industry should give its maintainers the tools they need to keep it secure.
• 
  Your Node.js Gateway It's Doing Twice the Work 08.07.2026 30min

  You launch a new product. Thousands of users click the same link at the same time. The cache is cold, and your Node.js app starts generating the exact same response hundreds of times simultaneously, burning CPU, hammering your database, and slowing down for everyone. This is the thundering herd problem, and most teams only discover it the hard way. So what if your gateway could just... not do that?In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina are joined by Paolo Insogna, Principal Software Engineer at Platformatic and Node.js TSC member, to break down how request deduplication works at the gateway level and why it changes the way you think about traffic spikes in Node.js. From the leader/waiter model to distributed coordination with Valkey, Paolo walks through exactly how Platformatic Gateway stops duplicate in-flight requests from reaching your upstream services, without touching a single line of your app code.In this episode, we cover:✅ What the thundering herd problem actually is, and why caching alone doesn't solve it✅ How gateway request deduplication works: the leader/waiter model explained in plain terms✅ Memory vs. Valkey: when single-instance deduplication is enough and when you need distributed coordination✅ The metrics that prove it's working, and what to watch for when rolling it out in productionThe takeaway?Caching protects you from future requests. Deduplication protects you while the first response is still being generated. They solve different problems, and running without both means your app is one viral moment away from a very bad day. Paolo built this into Platformatic Gateway so you get the protection without changing your backend, and this episode shows you exactly how it works.
• 
  How Do You Build Skew Protection? Let's unpack it 01.07.2026 38min

  "Zero downtime" doesn’t mean there’s no risk. When you release new code, some users still have the old version open in their browser, using outdated JS bundles and React state, without realizing anything has changed. Teams usually find out when a checkout fails or a form resets in the middle of a session.In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina break down the version skew problem from scratch. They explain what really happens during a deployment, why forcing a reload isn’t an option, and how to keep several app versions running at once without causing issues for users. They walk through the solution live, covering cookies, ingress routing, Kubernetes replica sets, and show the control plane they built to manage it all.We will cover:✅ Why version skew happens with every deployment and isn’t just a bug you can fix✅ How old JS bundles and mismatched React state can quietly break live user sessions✅ Why making users reload the page doesn’t solve the problem, and how it can hurt your e-commerce business✅ How cookies and ingress controllers help send users to the right app version without causing problems✅ How the control plane architecture manages replica set registration, routing, and smooth shutdowns in KubernetesThe takeaway?Version skew isn’t a sign your deployment failed. It’s just part of how deployments work. The best teams don’t try to avoid it; they build systems that let different versions run together. A control plane won’t make things simple, but it does put the complexity in a place you can manage.
• 
  Why Shipping Fast Breaks Your Users (and How to Stop It) 24.06.2026 27min

  You deploy several times a day. Your team moves quickly, and your lead time is short. But each deployment can quietly disrupt users already on your site. There are no big warnings, just someone clicking around, suddenly running into errors because the app in their browser and your updated server are out of sync.In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina talk about version skew: what it is, why it naturally happens when you ship isomorphic JavaScript apps, and why most teams don’t set up skew protection until it causes problems in production.Here’s what we discuss in this episode:✅ What isomorphic JavaScript actually means, and how running the same code on both the server and client leads to the skew problem✅ Why version skew is different from API versioning, and how treating it like an API issue leaves you vulnerable when a user loads an old bundle, but the server has already changed✅ Why shipping faster increases the chance for things to break, and how skew protection helps reduce that risk✅ Why slowing down isn’t the solution: what Accelerate’s data shows about deploy frequency, lead time, and how small batches actually lower riskThe takeaway?Shipping fast isn’t a problem; it’s the goal, and the data supports this. But fast deploys and isomorphic apps always lead to version skew, which stays hidden until a real user with an old bundle gets a 404 on something you removed earlier. Skew protection lets you keep deploying all day without quietly breaking users who arrived before lunch.
• 
  Node.js Left 26% Performance on the Table for 10 Years 17.06.2026 31min

  A default set in May 2015 just got its first change. One constant. One number. And it was silently costing Node.js up to 26% throughput on some of the most common workloads in the ecosystem: file reads, HTTP parsing, stream chunking. Nobody broke it. Nobody was ignoring it. It was just stuck in a world that no longer existed.In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina explain how they investigated a small but important change that was just released in Node.js 26.3.0. They discuss how modern applications moved past an old assumption, why multi-threaded apps suffered the most, and what it takes to show that a simple fix is safe for millions of users.In this episode, we cover:✅ How a default set in 2015 quietly stopped making sense as applications and hardware evolved✅ Why the fix helped some workloads by 26%, and had zero impact on others✅ How Matteo traced the slowdown all the way down to the operating system level to understand what was really happening✅ The cost of the change, and how to think about whether it matters for your own applicationThe takeaway?The biggest performance gains often don’t come from major rewrites. Sometimes, it’s just a setting that made sense years ago and was never revisited. The real lesson is about the assumptions built into the tools you use daily, and what can change when someone finally checks them.
• 
  Performance/Memory tradeoff. Can we have both instead? 10.06.2026 35min

  Memory and performance often compete with each other. Most developers only notice this tradeoff when something goes wrong, not during the initial design. At that point, the key decisions are already set.In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina talk about the memory-performance tradeoff from two sides: how to plan for it during design, and how to handle it at runtime if it becomes an issue. They use flame graphs on Kafka workloads to reveal hidden bottlenecks and explain a clear approach that makes memory debugging more reliable.This episode covers:✅ Why the memory-performance tradeoff begins at design time, not after your app crashes✅ How to find this tradeoff in your architecture before you start coding✅ How flame graphs work in real situations and what they show about Kafka pipelines that other tools miss✅ A step-by-step way to debug memory issues without guessing.The takeaway?The chicken-and-egg problem is not something you solve once and for all, but something you learn to manage. Developers who think about it during design build systems that don't cause late-night surprises. Flame graphs simply help you spot what you should have planned for.
• 
  How Do We Scale Rate Limiting in Node.js? 03.06.2026 30min

  Your Node.js service has rate limiting. You tested it, it worked, you shipped it. But your limit lives in the memory of a single process, and the moment you run more than one instance behind a load balancer, every replica enforces its own private budget. Ten instances means ten times the traffic you thought you were allowing. That is not a smaller problem at scale, it is a different problem entirely. So what does rate limiting that actually holds across a cluster look like?In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina dig into rate limiting for Node.js applications, why the obvious approach quietly fails in production, and how to build limits that survive horizontal scaling.In this episode, we cover:✅ The mechanics of in-process rate limiting and the trap of the in-memory store.✅ Why per-instance counters cannot enforce a global limit once you scale out.✅ How to back rate limiting with a shared store like Redis or Valkey, and the patterns that actually work.✅ The operational realities: clock skew across nodes, what happens when your shared store goes down, and the consistency-versus-performance balance you have to choose.The takeaway?A rate limit is a promise about your whole system, not one process. If it only holds on a single instance, it is lying to you. Get distributed rate limiting right, and Node.js handles abuse and traffic spikes gracefully. Get it wrong, and you will find out the hard way, in production, under load.
• 
  Requests, Limits, and the Throttling Trap: K8s Resources for Node.js 27.05.2026 28min

  You set a CPU limit on your pod, the node has plenty of capacity to spare, and yet your Node.js service is throttled to a crawl. How does that happen? The answer lives deep in the Linux kernel, in the CFS bandwidth controller and cgroups, and most teams never look there. Requests and limits are not two knobs for the same thing. One drives scheduling, the other enforces a hard quota, and confusing them is how you end up paying for CPU you can never actually use. So how do you size them right for an event-loop runtime?In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina break down how Kubernetes CPU and memory allocation actually works, what requests and limits really do at the kernel level, and why the defaults quietly sabotage Node.js workloads.In this episode, we cover:✅ What CPU requests and limits actually mean, and why they are not interchangeable.✅ How CFS quota and cgroups cause throttling even when the node is mostly idle.✅ The three QoS classes (Guaranteed, Burstable, BestEffort) and which one fits a Node.js service.✅ Why a single-threaded runtime makes limit sizing trickier than it looks, and the patterns that avoid silent throttling.The takeaway?Kubernetes will give you exactly what you asked for, including the throttling you did not mean to ask for. Get requests and limits right and your Node.js services run predictably. Get them wrong and you will burn money on capacity the scheduler will never let you touch.
• 
  Should We Rewrite Node.js in Rust? 20.05.2026 29min

  Bun made the switch. Zig is out, Rust is in, and AI handled most of the work, with 98% of the test suite passing. The question is no longer hypothetical; it's real now. If an AI can port an entire runtime, why are so many enterprise teams still stuck on a Node 12 codebase they're afraid to update?In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina talk about the Bun Zig-to-Rust port, including the memory leaks that led to the change, the rumors around it, and what it means that AI made it happen. They also look at the bigger picture: meta-cloud platforms losing their advantage, Node.js downloads passing 680 million a month thanks to AI tools, and why major AI companies still don't have a seat on the Node.js TSC, even though they build billions of dollars of products on it.In this episode, we cover:✅ Why Bun is moving from Zig to Rust, and why memory safety matters more than the drama✅ How AI managed to port a full runtime with 98% of tests passing, and what made this possible✅ The key to AI-powered migrations: integration tests that focus on results, not how things are built✅ Can enterprise teams do the same, and what does upgrading from Node 12 to Node 24 with AI really look like?The takeaway?The real breakthrough wasn't the model, but the test suite. Without integration tests, there is no migration, whether you use AI or not. That's the lesson hidden in the Bun story, and it's one most teams will miss while debating Rust versus Zig.
• 
  We Ran DOOM in a Node.js Terminal. Now There's No Excuse for Your Legacy Native Code (with Paolo Insogna) 13.05.2026 36min

  What started as a joke at the Node Collaborator Summit turned into the most compelling argument yet for why enterprises have no excuse left to avoid modernizing their native code.In this episode of The Node (and more) Banter, Luca and Matteo are joined by Paolo, Principal Software Engineer at Platformatic, who built "Project Destino" — because in Italian, destino means doom, and yes, that's exactly how we name things. That comment in London turned into a fully working DOOM port running at 35fps inside your terminal, with sound, powered entirely by Node.js FFI, OpenTUI, and a C library called DOOM Generic.In this episode, we cover:✅ How Node.js's native FFI module lets you load and run any C library. No native addons, no compilation headaches✅ Why the game loop lives in JavaScript (via setInterval) while the engine ticks happen across the FFI boundary✅ The FFI performance story: from 150 nanoseconds per call down to 15, close to the theoretical minimum✅ Node.js Single Executable Applications (SEA): ship everything — game, sound, native libraries — as one binary✅ The enterprise reality: if FFI can run DOOM, it can run your legacy DLLs — and there's no migration excuse left✅ What's next: llama.cpp via FFI, NVIDIA GPU experiments — and possibly Prince of PersiaThe takeaway?We didn't port DOOM because it made sense. We did it because the technology made it possible — and that's exactly the point. Node.js FFI changes the migration conversation for every enterprise sitting on legacy native code. If it runs DOOM, it runs your C library. No excuses.
• 
  Predictive Autoscaling for Node.js: Why Reactive Systems Are Costing You More Than You Think 06.05.2026 36min

  Many teams believe autoscaling is simple: set a CPU threshold and let Kubernetes handle it. But if you get a three-minute traffic spike and your pods need two minutes to start, users feel the lag, the spike ends, and your new pods show up too late. What if your infrastructure could predict traffic instead of just reacting?In this episode, Luca Maraschi and Matteo Collina challenge the usual autoscaling approach—HPA, KEDA, ECS, and more. They explain the predictive scaling algorithm Platformatic created for their Intelligent Command Center (ICC). Matteo explains why scaling is a nonlinear problem that the industry keeps trying to solve with linear solutions, and how thinking of a distributed system like a neural network can change how scaling decisions are made.In this episode, we cover:✅ Why reactive autoscalers always use outdated data by design, and why this is a core flaw, not just a configuration issue✅ The real cost of pod boot time that often gets ignored: spawn time, warmup, and traffic rebalancing✅ Why CPU and memory are not the right metrics for Node.js, and what you should measure instead✅ How Platformatic's algorithm checks event loop utilization from outside the thread, with no interference and no extra overhead✅ The benchmark results: 99.47% success rate compared to 95% with KEDA and 90% with HPA, with P99 latency ten times better✅ The 46-page white paper they published, and why they believe it's time to stop scaling out of fearThe takeaways?Over-provisioning is not a safety net; it shows the model is broken. If your system cannot predict load, you will always have to choose between wasting money and getting worse performance. This episode, along with the white paper, argues that smarter scaling is now essential, not just a bonus.