Frameworks are supposed to save time.
That's an obvious statement.
But I think there's a deeper version of it.
A good framework doesn't just help you write today's application faster.
It prevents tomorrow's application from making you solve yesterday's problems again.
That's becoming one of the biggest reasons I'm building KiwiEngine.
I've Already Solved This Problem
Every new project starts with excitement.
Then comes the familiar work.
Configuration.
Routing.
HTTP.
Styling.
Data.
Deployment.
Infrastructure.
Project structure.
All necessary.
But after you've built enough applications, something starts feeling strange.
You've solved many of these problems before.
Why are you solving them again?
Of course, applications aren't identical.
But many of the mechanisms underneath them are remarkably similar.
That was part of the motivation behind KiwiEngine.
Not:
"How can I eliminate programming?"
But:
"How can I spend more of my programming time on problems that are actually new?"
Repetition Isn't Always Bad
There's an important distinction here.
Repeating code isn't automatically a problem.
Sometimes two things merely happen to look similar.
Abstracting too early can create something worse than duplication.
I've learned that lesson repeatedly while building KiwiEngine.
But when the same problem appears across real projects over and over again, that's different.
Eventually a pattern earns an abstraction.
That's where libraries become valuable.
Build It Once. Improve It Everywhere.
Imagine I discover a better way of handling something while building a Blackwater Sound application.
If that improvement belongs in the underlying library, I can improve the library.
Now another application benefits.
And another.
And another.
That's leverage.
Instead of maintaining ten unrelated implementations of the same idea, I can improve the shared foundation.
The applications still remain different.
Their domains remain different.
Their users remain different.
But the boring problems underneath them don't have to be reinvented.
Time Is The Resource I'm Actually Optimizing
This has become more important as my interests have expanded.
I don't only want to build web applications.
I want to make music.
I want to produce records.
I want to teach.
I want to build pedals.
I want to experiment with amplifiers.
I want to build guitars.
I want to create stores.
I want to work with artists.
I want to write.
There are only so many hours available.
So if every idea requires me to rebuild an entire technical foundation before I can explore it, most of those ideas will never happen.
That's the real problem KiwiEngine can solve for me.
Infrastructure Should Compound
A framework becomes interesting when yesterday's work makes tomorrow's experiment cheaper.
Build a configuration system once.
Improve it across several projects.
Build an HTTP layer once.
Harden it through real use.
Build deployment tooling once.
Use it repeatedly.
Build a design system once.
Let projects configure it differently.
Each piece becomes another tool sitting on the workbench.
Eventually starting something new doesn't mean starting from zero.
It means assembling proven pieces and concentrating on what's different.
This Is Why Boundaries Matter
There's a danger here.
If KiwiEngine tries to solve everything, it eventually creates a different kind of burden.
Instead of saving time, I'll spend all my time maintaining KiwiEngine.
That's why I've become increasingly interested in boundaries.
Juice doesn't need to replace CSS.
A store package doesn't need to understand every business on Earth.
An API abstraction doesn't need to hide every capability of the underlying service.
Each piece should solve its problem well and then get out of the way.
Otherwise the framework becomes the project.
That's exactly what I'm trying to avoid.
The Goal Isn't Less Code
I'm not particularly interested in bragging about how few lines of code something requires.
Sometimes explicit code is good.
Sometimes configuration is good.
Sometimes abstraction is good.
The metric I care about more is:
How quickly can I get from an idea to working on the part of that idea that actually matters?
If I'm building a music tool, I want to spend my time thinking about musicians.
If I'm building a store, I want to think about products and customers.
If I'm building electronics, I want to think about circuits and hardware.
The framework should help me reach those problems sooner.
Eventually The Framework Should Become Boring
I actually think this might be one of the greatest compliments I could eventually give KiwiEngine.
I stopped thinking about it.
Not because development stopped.
Not because there aren't improvements to make.
But because the common pieces simply work.
I know how to start a project.
I know how configuration behaves.
I know how the pieces connect.
I know how to deploy it.
Then my attention can move somewhere else.
That's what infrastructure is supposed to do.
Give Me My Time Back
Building a framework requires an enormous investment of time.
So eventually it needs to repay that investment.
Not necessarily through subscriptions.
Not necessarily by becoming a huge software company.
It can repay me through leverage.
Through reuse.
Through faster experimentation.
Through shared improvements.
Through letting me pursue more ideas without rebuilding the same foundation every time.
The best framework isn't necessarily the one with the most features.
It might be the one that quietly gives you your time back.
That's what I want KiwiEngine to become.
Top comments (0)