TL;DR:
The Goal: Wanted to cut down the baseline memory footprint (80MB idle) of our Node.js microservices.
The Plan: Migrated an OAuth2 service to Dart using Claude Code, drawn in by promises of AOT compilation and "cloud-ready" performance.
The Reality: Dart VM keeps memory allocated after peak loads by design (optimized for Flutter's 60fps, not K8s). Under heavy CPU throttling, RPS dropped by 2x compared to Node.js.
The Lesson: AI tools make mechanical code migration free, but the cost of an unverified runtime hypothesis remains brutally high. Moved to Go.
If you are looking at Dart as a backend alternative to Node.js, it’s better to learn from someone else's mistakes. Complete benchmark results—featuring Go, Node.js, Dart, Bun, Deno, and .NET—along with methodology, configurations, and raw numbers, are available on . I’m a regular JS/TS developer, not a Go or .NET guru, so if you spot a flaw, PRs are welcome.
Act I: The Marketing Honeymoon
I work on a SaaS product powered by Node.js. Generally, it satisfies all our needs: solid performance, fast development cycles, and a unified language across the stack. Sure, under heavy loads, certain services get greedy. Our OAuth2 service, for instance, would peak at 500MB of RAM. But tokens were issued smoothly, memory was eventually reclaimed, and performance degradation was strictly bound to CPU-heavy cryptography.
However, when running a SaaS with hundreds of identical microservices, an idle footprint of 80MB per instance scales into a noticeable infrastructure bill.
We began exploring alternatives. Go is the obvious candidate, but our team is JavaScript to the bone. Go triggered zero enthusiasm: err != nil tracking every line, and passing context.Context as the first argument felt like a relic from the past—vividly reminding the team of Node’s old callback hell where err was always the first argument.
Then we stumbled upon Dart. On paper, it ticked every box: AOT compilation, static typing, and a familiar syntax. The official of the original TypeScript. The syntax is clean enough that even an AI writes it elegantly. But the moment you venture beyond writing basic business logic, you hit a wall. Because of this friction, nobody builds tooling, leaving the ecosystem stagnant.
Over two weeks, we engineered a NestJS-like framework with hierarchical DI (similar to Angular), transport layer isolation, request-scoping via Zone, and a code-gen CLI. Claude flawlessly ported our Redis ORM. On the surface, everything looked spectacular. Yet, an unsettling feeling remained. On day 14, I finally decided to run a clean, isolated load test.
Act III: The Production Reality Check
Problem 3: Performance Under Throttling
I set up a straightforward benchmark: three endpoints, Postgres, Redis, and identical infrastructure bounds for all runtimes. No frameworks, no ORMs—just raw HTTP servers to evaluate the execution engines themselves.
I anticipated , but easily outperforming .
The Dart VM is meticulously tailored for Flutter. Its priority is minimizing GC pause spikes to guarantee a seamless 60fps UI rendering on mobile screens. Releasing RSS back to the OS host is an afterthought. While brilliant for client-side mobile apps, this design is catastrophic for Kubernetes containers.
Kubernetes has no awareness that your process is just "caching memory for later use". It reads the active RSS usage. If an HPA (Horizontal Pod Autoscaler) scales your service to 10 pods during a traffic surge, those Dart pods will permanently retain that peak memory long after traffic subsides. The cluster cannot bin-pack or downscale nodes effectively. Node.js pods would shrink back down, freeing cluster resources, while Dart forces you to pay for your peak usage indefinitely.
And this is an engine marketed as "ready for cloud" on Google Cloud Run—a serverless platform billed exactly on a than the most popular, community-vetted Redis client on pub.dev. That’s not a praise of AI capability; it’s an indictment of the ecosystem. No one is building or optimizing heavy server infrastructure in Dart.
The flawless marketing facade had completely crumbled.
Act IV: A Sober Retrospective
After two weeks of heavy lifting—authoring a DI engine, porting Redis clients, and running load profiles—the verdict is absolute: for backend cloud workloads, Dart is a paper tiger. Its true home is strictly Flutter. The engineering team sacrificed reflection for small mobile binaries, stalled on macro language specifications for years, and tuned the VM exclusively for client side interactions.
It’s a shame, because Dart was a few architectural adjustments away from becoming a true competitor in cloud-native microservices. A 3MB boot footprint paired with structural typing is fantastic. If the GC promptly returned unneeded memory to the host OS, it would fit the serverless lifecycle perfectly: rapid scaling on surges, instant contraction post-load. Sadly, prioritizing mobile UI frame rates over container resource elasticity killed its entire server capability.
Ultimately, my search for a silver bullet led me right back to Go. Yes, it can feel repetitive, verbose, and demanding of explicit err != nil handling. But in a real-world production environment—throttled by CPU ceilings, managing database network hops, and requiring nimble memory management—Go simply scales. It delivers 1.5x to 3x the RPS of Node or Dart under strict constraints and reclaims memory flawlessly.
(As a side note, Bun performed exceptionally well in our tests, creeping close to Go's throughput, but under severe 100m CPU throttling, it consistently choked, failing liveness probes. For hardened K8s setups, it’s not production-ready yet).
So, I am opening up the Go tour and starting from scratch.
The Real Lesson
Commenters will rightfully point out: "A two-hour k6 script on day one would have saved you two weeks." They are completely correct.
But there is a subtle trap here that I only understood at the end of this journey. Tools like Claude Code make mechanical migration incredibly cheap—essentially free. And that's the paradox. When the cost of writing code drops to zero, it becomes dangerously easy to forget that the cost of an unverified runtime hypothesis remains identical. An AI agent won't challenge you and ask: "Are you certain this execution engine fits your infrastructure model?" It will simply build what you asked for, beautifully, swiftly, and without hesitation.
Validate the runtime hypothesis first. Only then let the AI raise the walls.
P.S. This writeup was supposed to be a quick post based on preliminary findings. Instead, validating the numbers dragged me down a benchmark rabbit hole for another two weeks: warming up containers, adjusting throttling quotas, and evaluating .NET, Bun, and Deno.
Validate your hypothesis. Validate your benchmarks. Only then write the article. One month of work instead of a two-hour test.
SOCIAL SHARE CARD GENERATOR