Fulmine.js delivers 2‑10× routing speedup as an Express 5 drop‑in

Fulmine.js ships as an npm package that can replace require("express") with require("fulmine.js") and runs on uWebSockets.js instead of node:http [DevTo].

What shipped

The library registers routes directly on uWebSockets.js's C++ router, moving the path match into native code and pre‑computing the handler chain at startup. No per‑request JavaScript routing loop runs. A CLI (npx fulmine.js profile, explain, verify) reports which routes compile to the fast path. The code lives on GitHub, the current release is published to npm, and the full Express 5 test suite (1 130 passing, 0 failing) runs unchanged [DevTo].

Performance benchmarks on Node 26 across nine CI runs show the following speedup versus Express 5 [DevTo]:

• 1 000 routes: 9.7× – 17.4× faster
• 1 000 routes with a parameter each: 10× – 21.2× faster
• Parameterised route in a mounted router: 6.8× – 8.8× faster
• API endpoint with params and a query: 3.1× – 4.9× faster
• URL‑encoded body: 3.3× – 4.6× faster
• Five route shapes in one process: 2.4× – 4.0× faster
• Nested routers: 2.0× – 3.4× faster
• 1 000 concurrent connections: 2.6× – 3.7× faster
• Hello‑world request: 1.8× – 2.9× faster
• Static assets (Angular SSR): 3.29× faster

Why it matters

• Routing cost dominates large APIs. In multi‑tenant backends with thousands of endpoints, Express’s JavaScript router scans a linked list on every request, adding measurable latency before any application code runs. Fulmine.js eliminates that scan, moving the match to C++ where it executes in a few nanoseconds.
• Kubernetes health probes become cheap. Probes such as /health or static /robots.txt are served without entering JavaScript, reducing CPU consumption in large clusters where probes can account for a sizable fraction of traffic.
• Compatibility is verified against the upstream suite. Fulmine.js runs the entire Express 5 test suite and the same suite for downstream frameworks—NestJS, Next.js, Astro, SvelteKit, React Router v7, Apollo Server, tRPC, and Angular SSR—ensuring byte‑for‑byte parity. The dual‑run testing uncovered two real bugs in the first CI runs.

Editor's take

The shift of routing work from JavaScript to native code is the real story, not just raw speed numbers. Teams that rely on the Express API can gain measurable latency reductions without rewriting their code, but they also inherit a native binary dependency (uWebSockets.js) that may affect deployment footprints and debugging workflows. The trade‑off between pure‑JavaScript simplicity and native performance will become a key decision point for high‑scale Node services.

Reader poll

Which routing stack would you adopt for a production API with thousands of endpoints?

• Stick with vanilla Express 5
• Switch to Fulmine.js on uWebSockets.js
• Use another Node framework (e.g., Fastify)
• Keep a custom C++ router