Walking Away From JavaScript

JavaScript-heavy Next.js apps can quietly accumulate massive memory footprints over time, and that creeping usage is pushing one developer toward a “do more with less” philosophy—fewer dependencies, less code, and sometimes a different language entirely. The trigger was practical: multiple Next.js deployments showed memory climbing into the hundreds of megabytes (around 400MB in one case), even when traffic was modest. That pattern raised a broader question about whether modern web stacks are paying too high a cost in runtime overhead for what the apps actually do.

The argument tightens around a simple observation: “less” often buys performance. Netflix once used a similar rule of thumb—stop doing so much to get faster—after repeated memory problems that required removing libraries like core-js. The same theme shows up in the developer’s own experiments with utility libraries: using only a couple functions from a big ecosystem (for example, common debounce/throttle usage) still doesn’t justify pulling in the whole world. The takeaway isn’t anti-JavaScript; it’s anti-unexamined complexity.

To test whether the memory issue is structural, the developer compares runtimes and frameworks. Switching from Next.js to alternatives like Hono and Bun changes the memory profile, but not in a way that fully satisfies the “less” goal. Hono/Bun still climbs over time (starting around tens of megabytes and drifting upward), and the developer suspects garbage collection behavior, leaks, or production overhead. In contrast, a Go implementation of a similar mailing-list endpoint lands dramatically lower—single-digit to low-teens megabytes in early deploys (roughly 6MB rising to about 11MB). That gap becomes the centerpiece: if one service costs ~400MB in JavaScript land, then running dozens of services makes cloud bills rise along a steep curve.

The explanation offered for why Go can be so lean is rooted in runtime mechanics. JavaScript relies on heap allocation and JIT compilation, which requires storing optimization metadata and runtime bookkeeping for functions and objects. Go, by contrast, compiles ahead of time and can use stack allocation for many structs, reducing the need for garbage-collection tracking and extra per-field overhead. The developer also argues that Go’s standard library and built-in concurrency primitives (channels and goroutines) reduce the need for bundlers and middleware ecosystems that Node deployments often pull in.

From there, the pitch expands beyond memory into engineering philosophy. The developer praises Go’s “boring” simplicity—formatting, straightforward tooling, and a single compiled binary—while acknowledging Go has tradeoffs. The broader message is that web development often becomes a tangle of incidental complexity: bundlers, caching rules, unstable framework behaviors, and constant dependency upgrades. That pain fuels interest in Go + HTMX as a way to preserve server-side power while delivering interactive UI with minimal JavaScript. Finally, the transcript argues for long-term maintainability: web components and HTMX-style HTML transformations can reduce upgrade churn compared with frameworks that force frequent rewrites.

Overall, the core finding is a practical one: memory overhead and dependency sprawl aren’t just theoretical—they show up in real deployments, and switching to “less” (including Go in some cases) can produce large, measurable wins in both resource usage and operational simplicity, especially when scaling to many services.