The framework isn’t for you. You’re just along for the voyage.
I was trying to build a survey form. Just a text box or two, a dropdown maybe, and a button. Nothing crazy – no fancy gradients, no animations that make buttons behave like they are auditioning for a Pixar film. Just a boring, run-of-the-mill form with a button that says “Submit”.
Five minutes of work, I thought. Maybe ten if I forgot how HTML works again.
Many hours later I had installed a CLI, a bundler, selected a starter template, and more packages than Santa delivers to the nice kids at Christmas. It started as a tiny task, and now I’m in dependency purgatory wondering if the form even needs to exist.
At some point, while watching my editor freeze under the weight of its own node_modules folder, I started suspecting the form was no longer in my control. It had outgrown me.
It had ambitions. This wasn’t a form anymore. This was a journey. A voyage.
And the framework, whatever it was, had quietly promoted itself to captain.
The realisation that the framework has its own agenda
This is the part no one tells you when you reach for a JavaScript framework: it wasn’t built for you.
Oh, it wants you to think it was. It wants you to feel special. It whispers sweet promises like:
- “Look how fast we hot-reload!”
- “Look how elegant our file structure is!”
- “Look how little code you have to write!”
But that’s bait. Pure developer catnip.
Because frameworks are built for a lot of reasons, and almost none of those reasons are “so your product will be delightful, stable, and low maintenance for you or for your users.”
The reasons frameworks are built are one or more of the following:
- the maintainers’ careers
- corporate influence
- ecosystem dominance
- conference applause
- and the irresistible urge to reinvent a perfectly functional wheel using 80% configuration and a touch of YAML - also known as the “I can do that better” argument.
What about your users, your deadlines, and your actual business needs?
They weren’t even in the room.
Frameworks are entire worlds bent around the desires of the people who build them. And that’s fine, mostly. As long as you understand the deal.
Why frameworks are free, and why that should concern you slightly
They are free because if they weren’t, nobody would use them.
They are free because adoption equals power.
They are free because “free” lets creators test ideas on thousands of unsuspecting developers who just wanted a dropdown.
And when something is free, you are not the customer.
You are the product.
You wouldn’t download a free dog and then complain that it barks. You wouldn’t be gifted a free house only to demand they repaint it mauve.
But with frameworks, we not only look the proverbial gift horse in the mouth - we complain about its breath.
We act shocked that we don’t have any say in how they evolve.
Why would you? It’s free.
This is how you end up the reluctant owner of a cargo ship
At some point in my little form adventure I had a realisation:
I didn’t pick a framework. I boarded a cargo ship. A cargo ship that I own but I am not in charge of.
I wanted a small rowboat - something small and calm, something simple. Yes, it may be a bit leaky, but it would be fine for my purposes.
But instead, I ended up on a vessel that can only turn if the moon is in the correct phase.
The framework is enormous. It has opinions. It has mechanisms. It has interfaces that interface with other interfaces that you never asked to interface with anything.
It wasn’t built for my tiny cross-the-river errand. It was built for transoceanic routes, shipping lanes, ballast calculations, and complex global logistics I will never understand.
And just like a real cargo ship, it’s going to require a crew, a maintenance schedule, a surprisingly large amount of fuel, and a commitment to learning what all those buttons do.
One does not simply “add a form” on a cargo ship. One schedules a deployment window, checks the tide, files the documentation, rebalances the containers, and hopes the weather holds.
The twist? It’s okay, as long as you know the deal
Here’s the thing. Frameworks aren’t bad. They aren’t villains. They aren’t plotting against you, even if the documentation occasionally feels like a trap.
They’re just… not for you.
They’re built for the ecosystem, for the maintainers, for the job market, for the people who love building frameworks.
You’re allowed on board. You’re even encouraged to wander around and touch the machinery. But you are not steering the ship.
The moment you accept that, everything becomes less frustrating.
Yes, the framework will change in ways that inconvenience you. Yes, the next major version will break something, if not everything important. Yes, the migration guide will be vague in all the places you needed it to be specific.
But that’s the price of being a passenger on someone else’s vessel.
Your job is to get your form built and shipped without falling overboard.
Doing software wrong, nautical edition
We all want to believe we are in control of our tools. That the choices we make are rational and centred around our users. That a framework is a partner who has our backs, rather than a large industrial machine humming under our feet with little care if we succeed or fail.
But the truth is simpler, and slightly funnier:
Sometimes you’re not doing software so much as hitching a ride on someone else’s engineering adventure.
And that’s fine.
It’s wrong, of course. But it’s the kind of wrong that everyone is doing, loudly, proudly, and with a nauseating number of dependencies.
Now if you’ll excuse me, I need to update my form. Which, judging by the size of this vessel, is probably going to require a couple of tugboats, and a local pilot, and maybe a bribe.