Hacker News Reader

Comment by coldtea | Hacker News Reader

>It can't be, because all the people spending their time on bespoke solutions are solving the same problems over and over again separately, whereas the people working on shared solutions keep building off each other. Over the long-run it gives a massive quality advantage to the shared solutions.

In theory, yes.

In the real world, "the people working on shared solutions" get distracted too easily, follow latest BS fads, change course and rewrite everything for no good reason (too numerous projects to mention). And some of them are just plain mediocre framework designers in an industry that embraces mediocrity a lot more than it should...

What's even worse most frameworks are not that extendable without going out of your way when you need some custom functionality. So as soon as your problem becomes interesting, and you could really use some help from a framework, it's when they tend to break and you have to work around them...

View on HN

>What's even worse most frameworks are not that extendable without going out of your way when you need some custom functionality. So as soon as your problem becomes interesting, and you could really use some help from a framework, it's when they tend to break and you have to work around them...

Then you discover the framework designers consider your problem too far from their core target use cases and so show no interest in improving that area of the framework. The community question why on earth you were trying to solve that problem in the framework in the first place, and tell you that obviously you should have used a different framework from the start.

Frameworks all target different use cases; often simply the ones the designers happen to have faced over the years. Half the battle in choosing a framework seems to be finding out what those target uses cases actually are - most frameworks seem to think they are good at everything.

God forbid your app evolves and changes such that no framework fully supports all your uses any more...

(That's not to say frameworks are bad, I just think there's a bit too much religious fervour involved when discussing them.)

> Then you discover the framework designers consider your problem too far from their core target use cases and so show no interest in improving that area of the framework. The community question why on earth you were trying to solve that problem in the framework in the first place, and tell you that obviously you should have used a different framework from the start.

Either they're right or they're wrong. If they're wrong, then you have a golden opportunity to start contributing to the framework yourself by writing the extensions, incorporating them into your projects, sending them upstream when they're ready. If they're wrong then you'll be able to work that into your development workflow and you won't lose any speed by packaging up a PR or whatever.

If they're right then this will feel like pulling teeth.

I've seen this a few times with projects I've worked on. I think what it comes down to is this: "despite the trouble I had with feature x, did the framework save me time and effort because 90% of the work (i.e boilerplate) was done for me".

If the answer is no, then using a framework was probably a mistake. However, for 99% of web applications, I don't think the answer to this question is a no.

Reply on news.ycombinator.com