This is probably the question I get asked most often when I talk about StreetJS.
And honestly?
It's a fair question.
Node.js already has Express, Fastify, NestJS, Hono, Koa, AdonisJS and many other frameworks.
So why build another one?
I'm not trying to replace them.
I'm trying to explore a different question:
What should a TypeScript backend framework look like if we designed it today?
The Node.js ecosystem is powerful—but fragmented
Node.js gives developers enormous freedom.
That's one of its biggest strengths.
But that freedom can also mean assembling a backend from many different pieces.
You might choose:
One HTTP framework
One validation library
One authentication library
One ORM
One logging solution
One WebSocket library
One job queue
One caching solution
One metrics solution
There's nothing inherently wrong with this approach.
In fact, it can be excellent.
But when building multiple applications, I kept noticing how much infrastructure was being recreated from project to project.
That's the problem StreetJS is trying to explore.
What if the framework provided more of the foundation?
Instead of starting with an empty Node.js application and assembling everything yourself, StreetJS aims to provide a more complete backend foundation.
Things like:
Routing
Dependency injection
Middleware
Validation
Authentication
Database access
WebSockets
Background jobs
Caching
Health checks
Metrics
Telemetry
The goal isn't to force developers to use every feature.
It's to make the common backend infrastructure available when you need it.
But there's a danger
A framework can easily become too large.
Add enough features and eventually you have a giant system where everything depends on everything else.
That's something I want to avoid.
The challenge is finding the line between:
"Batteries included"
and
"Everything is coupled together."
That's why architecture and boundaries are such a big part of StreetJS.
I don't want developers trapped by the framework
Strong defaults are useful.
Permanent decisions aren't.
If you prefer a different database, authentication provider, storage system or external service, the framework should make integration possible rather than telling you:
"This is the only way."
That's one reason I'm interested in a strong plugin ecosystem.
The core should stay focused.
The ecosystem can grow around it.
So... do we need another framework?
Maybe not.
And that's okay.
StreetJS doesn't need to convince every Node.js developer to switch frameworks.
I'd be happy if it simply becomes useful to developers who share the same problems I was trying to solve.
And if developers look at the architecture and say:
"I would design this differently."
That's useful too.
Because the goal isn't just to build software.
It's to explore better ways of building software.
I'd like to hear from you
If you have built production Node.js applications, I'm genuinely curious:
What is one thing existing backend frameworks get wrong?
Not what feature they're missing.
What design decision would you change?
That discussion is probably more valuable to me than another feature request.
StreetJS is open source:
GitHub: https://github.com/hassanmubiru/StreetJS
Documentation: https://hassanmubiru.github.io/StreetJS/
If you disagree with the idea, tell me why.
I'd rather have a good technical argument than a hundred likes.