Hacker News Reader

Comment by throwaway284962 | Hacker News Reader

I started using a framework for a task at work, was immediately tripped up by an obvious stupid bug in the config files, reported it and it was closed because "too many people already depend on this behaviour". So now I've in-sourced other companies legacy and taken on a huge liability in depending on the evolution of undefined number of other organisations and their code bases.

And even worse when these frameworks are open source and don't even have any accountable people at all, and god knows how many people working professionally are suddenly held hostage by some dude who just felt like going backpacking in south america for 6 months without giving any notice to anyone.

View on HN

Build everything in-house or be beholden to some dude going backpacking is a false dichotomy.

It'd be like saying I always make my own food from scratch — have you seen the state of the burger van down on the corner? You can't trust food made by others.

All frameworks aren't created equal — as with any tooling, you choose something based on the features of the framework but also the longevity, reputation and ecosystem built around it.

Thank you for this common sense reply. Can you imagine someone wanting to roll their own Flask? Their own React? It's like most people here seem to be siths and only deal in absolutes.

Yeah, but this has other trade-offs than the other two options of just using a 3rd party framework and inventing your own. Not saying that this is not viable though.

Then your architect needs a fresh course in how to decide what open source project to use. When its a critical spot you first check how it is maintained. Its that easy.

Yeah but isn't this example just a trivial config bug? We're not talking about core functionality here. You're extrapolating from a minor nuisance to "a huge liability in depending on the evolution of undefined number of other organisations and their code bases" which is quite a leap. Just do config the way everyone else does; again it's not a differentiator.

Thinking about this case more, this is exactly what you want from frameworks: compatibility guarantees. Frameworks break compatibility, but deliberately and slowly. Will your in-house framework do that? Will it announce and well document its intent to deprecate functionality in favor of new features? Will it find all the users of it across your enterprise and work with them on migration strategies? Will it build in deprecation notices for literally years? Will it build in tests for the bridging changes? Django does all of this, for you, for free.

Good news, the framework is open source! You get to fork it, fix the bug and get every other functionality for free!

At which point it becomes an in-house framework, which is what they were trying to avoid I the first place.

Reply on news.ycombinator.com