I built Vercube because benchmarks don’t lie

Source: Dev.to

Introduction

Let’s start with the obvious: yes, this is another Node.js framework.
I know. You know. Somewhere, a counter just overflowed and a backend developer quietly closed a tab.

Most of the time, that’s the right reaction. You already have NestJS, Fastify, maybe a couple of internal helpers. Adding one more framework usually sounds pointless.

Vercube didn’t start as:
We need a new framework.
It started as:
Why does every framework that feels good to work with get slow – and every fast one feel like you’re fighting it?

This article isn’t an external review. I’m the author of Vercube. It’s a story about why I built it, which assumptions I stopped accepting, and why the benchmark results were the moment I knew this wasn’t just a side project anymore.

---

The Problem

For a long time, backend development felt like a forced choice.

Vercube exists because I didn’t want to keep choosing between those two worlds.

Motivation

1. Readability over the long term – backend code should stay readable long after the first sprint.
2. OOP still does a great job – clear responsibilities, explicit dependencies, code that reads like a system instead of a script. Decorators help express intent without adding noise.

The problem isn’t OOP itself – it’s how most Node.js frameworks implement it.

• Most decorator‑based frameworks rely heavily on runtime reflection.
• reflect-metadata becomes a global dependency.
• Types are inspected at runtime, containers infer dependencies dynamically, and metadata is scanned/merged while the app is already running.

All of that has a cost, and that cost shows up exactly where you don’t want it: build time, cold starts, latency, and throughput.

---

Vercube’s Approach

In many ways, Vercube is what projects like routing-controllers were aiming to be – but rebuilt for modern TypeScript, modern runtimes, and performance as a first‑class concern.

Core Idea

What happens if you remove all of that?

• In Vercube, decorators are not a runtime trick. They describe structure without inspecting types, scanning metadata, or depending on global reflection APIs.
• They don’t make decisions at runtime, keeping the framework predictable and avoiding the usual reflection‑heavy model entirely.

Runtime‑Agnostic Design

• Built on top of srvx and native Request / Response interfaces.
• The same application model works on Node.js, Bun, and Deno without adapters or compatibility layers.

Simplicity Under the Hood

• If a dependency exists, it’s because you registered it.
• At the heart of Vercube is a very small IoC container – nothing more. It registers and resolves dependencies, and that’s it.
• No hidden scopes, no proxy chains, no request‑time dependency graphs. The container does its work during setup; after that, request handling is as direct as possible.

It might sound boring – and that’s intentional.
At some point, design ideas stop being interesting on their own. Numbers take over.

---

Benchmarks

These benchmarks are not about “winning” against every framework. They’re about showing the real cost of different architectural choices.

All tests use identical endpoints, identical load, and the same environment. Raw data and methodology are public – you can find them on GitHub:

https://github.com/vercube/benchmarks

Build Time

• Build time directly affects developer experience and CI pipelines – yet it’s rarely discussed.
• Vercube builds ~4.6× faster than NestJS in the same setup.
• The difference comes from removing reflection, metadata scanning, and complex bootstrap logic.
• Vercube uses Rolldown – a blazing‑fast bundler that complements this simplified architecture perfectly.

Cold Start

• Cold start matters in serverless environments, autoscaling setups, and frequent restarts.
• Vercube cold starts ~35 % faster than NestJS and over 3× faster than Ts.ED.

Throughput

• Throughput is the metric everyone expects.
• Vercube delivers ~16 % higher throughput than NestJS, while still using decorators and dependency injection.
• The goal isn’t to dominate throughput charts – it’s to stay competitive without giving up structure.

Latency

• Average latency hides problems. p95 shows real behavior under load.
• Vercube stays stable under load and avoids long‑tail latency spikes common in heavier frameworks.

Full‑Lifecycle Performance

• Most frameworks talk about runtime performance.
• Vercube cares just as much about everything that happens before the first request: build time, cold start, startup memory.
• In modern systems – CI‑heavy workflows, serverless deployments, short‑lived instances – these costs add up quickly. The benchmarks show that Vercube performs well across the entire lifecycle, not just during request handling.

---

Why It Works

There’s no single trick behind the results. Performance comes from removing entire classes of overhead:

• No runtime reflection
• No metadata scanning
• No request‑time dependency resolution
• No abstraction layers sitting on every call

Everything expensive happens once. What runs per request is plain JavaScript.

That also means fewer surprises. When something behaves a certain way, it’s usually obvious why.

Many developers associate decorators with slow, over‑engineered systems. That’s a tooling problem – not a paradigm problem.

Vercube shows that you can keep OOP, keep decorators, keep clean structure – and still hit numbers usually reserved for much more minimal frameworks.

---

Conclusion

I didn’t build Vercube to prove a point about performance alone; I built it to re‑claim the developer experience that gets lost when frameworks pile on hidden costs. By stripping away reflection, metadata scanning, and runtime‑heavy abstractions, Vercube delivers a familiar, structured OOP experience without sacrificing speed.

If you’re tired of choosing between “fast but bare‑bones” and “feature‑rich but sluggish,” give Vercube a try – the numbers, the code, and the philosophy are all open for inspection.

Point about frameworks

I built it because I wanted to enjoy writing backend code again—without paying for that comfort in build time, startup time, or runtime performance.

The benchmarks matter because they remove opinions from the discussion. You don’t have to like the design or agree with the philosophy. You can just look at the numbers.

And those numbers show that OOP—when done carefully—still has a place in modern backend development.