I get tired of frameworks. Doesn’t particularly matter what the platform the framework is used for. Web, native, set top box.
I should take that back. I don’t get tired of frameworks. I get tired of people telling me I’m doing things wrong by not using their framework and proceeding to show me a poor implementation they’ve completed with their framework axe.
Soap boxes, or the current Internet equivalent Hacker News or Reddit, are the last place I particularly want to listen to preaching about the evils that is development without wiz-bang framework X. I came for the cats people, let’s keep it on point. At least with those places I can simply walk on by or not visit.
Lately in meetings though I’ve found myself as the only person without an framework axe to grind. “We should be using that nuclear reactor framework because it’s what Facebook uses.” Sure, there is a good laugh there which I should have kept to myself, but I digress. The larger problem is that management shouldn’t be making framework decisions. That can be hard however when the developers chime in at the same meeting: “Of course we should be using React because Facebook uses it, good choice boss!”
My developer religion is designed to look at all uses of code and frameworks with a skeptical chicken eye muttering “what’s this application supposed to do?” Because why over engineer what doesn’t have to be. Costs and budgets and timelines are important things too; forget those and you’ll never ship. Your app is not Facebook. It’s not Gmail. It’s not.
“But my app could be and I need developer scale!”
You’re right. Your app could be huge. So could my todo app. Aren’t we due for another round of highly scalable todo apps? Framework time for sure.
The framework soapbox preacher would further chime in and say “Framework X saves time by simplifying Y” and “It’s easy to grok the project and get work done faster, anyone can come who knows the framework and get work done today!”
I have no doubt that in a lot of cases that is true; sprawling projects can benefit from order and paradigm. Maybe a framework is a good choice. You should probably do an evaluation of skills your team has and what they know.
The funny thing, as the fella brought in to pull projects out of fires for folks that did not do an evaluation of their actual needs, frameworks can have this interesting side effect: horrible code. Not from the framework, but by folks who didn’t understand the framework. “We implemented it in Angular” doesn’t mean much to me when I’m told as a follow up “we’d never used it before.”
You see, the great hubris of the framework preacher is that they’re trapped in a world where they think only their framework will solve the world’s problems. Maybe it was the first thing they learned or had success in. Maybe they’re trying to impress buzzword manager. Maybe it fills gaps in a developer work belt they haven’t fully stocked.
Why this amuses chicken eye Justin is that the very smart developers who work on building frameworks with whom I’ve spoken all roughly get to the same answer when it comes to using their or anyone else’s framework: it depends. “You should always evaluate your need” one said to me last month. “It’s sort of the reason someone hired you as a dev right?”
Why?
“Because framework or not, you’re the developer of record for a piece of software. You can blame whatever you want but it comes down to the person writing code, framework or not.”
If there was a lesson to be learned, I say stop preaching and start learning. Sharpen your axe with skills. You’ll be better off and the Internet will be left to more cat related images.
I’m tired of standing on this soapbox. I think I’ll go write a new JavaScript framework.