I didn’t set out to build a web engine.
I set out to solve a frustration I kept running into over and over again:
Every project felt like starting from zero.
Different stack.
Different patterns.
Different rules.
Same problems.
The Illusion of Progress
We’ve made huge progress in web development:
- Better frameworks
- Better tooling
- Better DX
But under the surface, we’re still doing the same things:
- Rebuilding API layers
- Rewiring state management
- Reconfiguring infrastructure
- Re-learning patterns per stack
We didn’t remove complexity.
We just moved it around.
The Real Problem: No Shared Contract
The biggest issue isn’t tooling.
It’s the lack of a shared contract between layers.
- UI doesn’t know your API structure
- APIs don’t strongly enforce shape beyond runtime
- Infrastructure is configured separately from application logic
Everything is loosely connected, but not intentionally designed to work together.
What Is a Web Engine?
A web engine is not a framework.
It’s not just a library.
It’s a system that defines how applications are built end-to-end.
Game engines figured this out a long time ago.
They don’t just render graphics.
They define how everything fits together:
- Assets
- Systems
- Logic
- Scaling
You don’t rebuild those pieces every time.
You build within a system.
That’s what the web is missing.
Frameworks vs Engines
Frameworks give you tools.
Engines give you rules, structure, and guarantees.
A framework says:
“Here’s how you can do it.”
An engine says:
“Here’s how it will be done.”
That difference matters.
Consistency is what allows systems to scale.
The Philosophy: Contract-First Everything
The core idea is simple:
Every layer should be defined by a contract before it is implemented.
Not after. Not loosely. Not guessed.
UI Contract
Instead of scattered styles and component sprawl:
- UI follows predictable structure
- Styling is expressive but controlled
- Components are declarative
API Contract
Instead of writing endpoints ad hoc:
- APIs are defined in configuration
- Inputs and outputs are explicit
- Validation is built-in
Example:
get:
user:
GetUserById:
where:
id: $param.id
Data Contract
Instead of implicit assumptions:
- Data models are defined centrally
- Queries are structured
- Transformations are controlled
Infrastructure Contract
Instead of dashboards and manual setup:
- Infrastructure is declared
- Environments are reproducible
- Deployments are predictable
Example:
provider: digitalocean
droplet:
name: app-server
size: s-2vcpu-4gb
Why Contract-First Matters
Without contracts:
- Logic becomes implicit
- Bugs are harder to trace
- Systems drift over time
- Refactoring becomes risky
With contracts:
- Systems are self-documenting
- Validation happens early
- Teams move faster
- Code reflects intent instead of guesswork
Pipelines Over Hooks
One of the biggest shifts I made:
I stopped relying on hooks.
Hooks are flexible, but they introduce:
- Hidden execution order
- Implicit dependencies
- Debugging complexity
Instead, I use pipelines:
Request → Validate → Transform → Execute → Respond
Each step is:
- Explicit
- Ordered
- Observable
You don’t inject behavior into the system.
You move through it.
Configuration as a First-Class Citizen
Most systems treat configuration as secondary.
A web engine treats configuration as the source of truth.
- YAML or TOML define behavior
- Code executes the contract
- Systems are assembled, not improvised
This doesn’t remove code.
It disciplines it.
The Goal: Reduce Reinvention
Right now, building apps looks like this:
- Pick a framework
- Pick a backend
- Pick a database
- Pick deployment
- Glue everything together
Every project is a new puzzle.
A web engine changes that:
- The system already exists
- The rules are already defined
- You build within constraints
And constraints are what enable speed.
This Isn’t About Control
This isn’t about locking developers in.
It’s about giving them:
- Predictability
- Stability
- Confidence
Freedom without structure leads to chaos.
Structure without flexibility leads to stagnation.
A web engine aims for the balance.
Where This Is Going
What started as a UI experiment grew into something bigger:
- UI layer
- Rendering layer
- API and data system
- HTTP pipeline
- Infrastructure layer
Not separate tools.
Parts of the same system.
Final Thought
The web doesn’t need more ways to build things.
It needs a better foundation for building them.
Not just faster.
Better.
More predictable.
More stable.
More intentional.
That’s what I mean when I say:
The web needs an engine.
Top comments (0)