I’ve been in software development for about ten years now since the uni time. Even with a limited pool of tools, mostly Node.js and React.js, I’ve noticed how open-source projects and custom libraries rise and fall. Just last night, I watched “The Dark Knight” again, and there’s a line: “You either die a hero or live long enough to see yourself become the villain.” I don’t know why it made me think about how often I’ve seen software tools start out as heroes — saving the day with new solutions, only to become villains when they grow too complex and hard to manage.
I believe this one happened to anyone and not just me because whenever I shared what I think about this with my old “teammates” (I like it better than “colleague”), we all agreed that it’s everywhere. It’s a bit “same same but different” with the https://medium.com/@whoz_/the-untold-clean-code-clean-app-9cc2e1772644 posted in my profile from hung.dev, but here, I want to tell a similar story with a bit of change.
Let’s set the scene
You’re launching a new tech startup and want to move fast. Everyone’s excited, and you begin by using some popular open-source libraries. They seem like a good fit at first — everyone’s using them, right?
Take Material-UI, for example. It’s a favorite in the React community for building UIs fast. But as you dive deeper, you start to see its limitations. It’s pretty heavy, and when you’re trying to keep your app snappy, that’s a problem. Plus, it doesn’t cover every specific need your project has. You find yourself hacking around these limitations, which is hardly ideal.
Then comes the dreaded major update—suddenly, you’re facing breaking changes that force you into a tough migration. I did it once with a lot of Frankenstein component wrapper code to make sure the new one was living happily with the legacy one. Even though it’s painful, trust me, it’s really nice to see how paying major tech debt helps and allows the new wonderful thing to come.
The rise of a hero
So, you decide to build your own solution. At first, it’s awesome. It’s customized just for your needs, and your app’s performance improves noticeably. You’re feeling pretty good about ditching the bulky libraries and tell your UX/UI designer to go WILD!
Every devs feels good about themself doing this, we all feel in control of our fate. Now, you can do whatever you want, pour your efforts and passion into it and make it better every day. And you ask yourself: “What in tarnation I didn’t do this sooner?”
The Villain
However, as your app grows, so do the demands on your custom library. Initially small and efficient, it begins to bloat as you add features and patches to handle new requirements like keyboard control support for the list, accessibility support, caching… Before you know it, you’ve basically recreated many of the features that Material-UI offered but without the community support. Every new feature is a struggle, and there’s nowhere to turn for help when things go wrong.
Eventually, you face the hard truth: maintaining your own library drains resources faster than adding value. The thought starts to creep in — maybe those well-supported, community-driven libraries weren’t so bad after all. It might be time to switch back, not because they’re perfect, but because they distribute the load better across a whole community of developers.
It’s a cycle many of us know too well: we start out trying to ditch the bulky tools for something leaner, only to end up right back where we started, but with a lot more respect for those battle-tested tools we tried to avoid.
Looking back
Let’s get back the reason why you dump the Material-UI in the first place. Have you ever thought about contributing back to the communities? This will fix your issue, boost your morale, and make you happy.
Look at all the resources spent on maintaining and “optimizing”; you could have introduced many great features for the customer and won this customer-centric https://medium.com/@whoz_/beyond-code-dont-just-be-a-coder-a9bad8007dca.
The example above is only for the frontend component libs vs. in-house libs, but I can see the pattern everywhere, from programming languages to architecture, from the hype of new types of databases to the trending frameworks. A new hero is a prodigy to be “A-killer”, while A is an old and widely used software as a bad guy in rebellious eyes. It is extremely dangerous to be arrogant and scoff at the old giant and think you are making a much better community of millions of devs and countless problems they have solved. Then you are the true villain here.
DRY and have fun.