16 ms·

Using sufficiently powerful programming languages, we can create better libraries that use lazy evaluation and higher-order functions. Well, yes. But the whole

Using sufficiently powerful programming languages, we can create better libraries that use lazy evaluation and higher-order functions. Well, yes. But the whole point of using a framework is that it's already created. The next time I go to a client who wants a scalable international web application that needs... well, the same stuff that's in pretty much every other scalable international web application. Why shouldn't I run it up on a framework that provides all that and save myself (and the client) six months of building, glue code, integration, and all the other testing? One of the arguments against frameworks is that they're hard to learn: On the upside, while frameworks often need the be “learned”, this is less so the case with libraries. People read whole books on how to use a particular framework, but they usually just start programming against a library. Right. So I go and learn a framework, once. In a few weeks of not being visibly productive, I front-load the next 2-5 years of my life and my actual day-to-day job of creating the unique stuff -- the business logic, data tier, front end -- becomes much more productive.

ckluis 12y ago
I would argue in your specific argument the next layer up is using a prebuilt CMS not just a development framework...
- coderzach 12y ago
  If your customer just wants a blog, why not use wordpress?
jasonwocky 12y ago
> The next time I go to a client who wants a scalable international web application that needs... well, the same stuff that's in pretty much every other scalable international web application. Why shouldn't I run it up on a framework that provides all that and save myself (and the client) six months of building, glue code, integration, and all the other testing? Sounds like you're a consultant / freelancer (like me). For folks in our position, frameworks are win-win. We can become specialists in them, get things implemented quickly and more cheaply than an alternative, and satisfy our clients. Of course, also having been on the other side, I know that the pain of frameworks comes later, in long-term maintenance. This is because the frameworks more or less "define reality" for the applications that are hosted within them. And when an applications business needs start to reach beyond what the framework is capable of making easy, then the development tradeoffs start to get nasty.
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 ago
  I 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.

ckluis 12y ago

I would argue in your specific argument the next layer up is using a prebuilt CMS not just a development framework...

coderzach 12y ago
If your customer just wants a blog, why not use wordpress?

jasonwocky 12y ago

> The next time I go to a client who wants a scalable international web application that needs... well, the same stuff that's in pretty much every other scalable international web application. Why shouldn't I run it up on a framework that provides all that and save myself (and the client) six months of building, glue code, integration, and all the other testing? Sounds like you're a consultant / freelancer (like me). For folks in our position, frameworks are win-win. We can become specialists in them, get things implemented quickly and more cheaply than an alternative, and satisfy our clients. Of course, also having been on the other side, I know that the pain of frameworks comes later, in long-term maintenance. This is because the frameworks more or less "define reality" for the applications that are hosted within them. And when an applications business needs start to reach beyond what the framework is capable of making easy, then the development tradeoffs start to get nasty.

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 ago
I 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.