3 ms·
Using a framework is great as long as you only want to do the things it's designers planned for. As soon as you want to do something else, unless you're very lu
by vilya 12y ago
Using a framework is great as long as you only want to do the things it's designers planned for. As soon as you want to do something else, unless you're very lucky, it sucks. If you're using a library you generally have more options when you get into this situation.
As with anything, choose whatever's most appropriate for the job. But, as a single data point, every framework-based project I've worked on - literally every single one - has ended up in that situation.
- gutnor 12y agoI have worked on all kind of project - lots of libraries, internal "framework" on top of lots of libraries, and plain framework. The comment "As soon as you want to do something else, unless you're very lucky, it sucks." applies to pretty much all the situations. To give my single data point I'm currently working on an application that is more libraries than framework, and the way we used libraries is clashing with what the application has been repurposed to do. In our case, the library can do it, we could have coded in a way that would have solved our current goal, however 5 years ago it did not make sense to do so, so here we are. More basically, the reasons you cannot chose the right framework that will meet your future need are going to lead into making the not-future-proof design decisions. That even happen when you do not use any library or framework. The difference with a framework is that it starts with its own history while you start fresh with a bunch of libraries. Initially you have a lot less chance to run into complex refactoring when you roll your own ( conversely, as parent said, you do not get any of the benefit that using a framework brings you: like enabling some powerful feature by configuration or with very minimal effort) The more code you commit however the less it starts to matter.