Libraries versus Frameworks
sitecanary.com
sitecanary.com
I do agree on one point though, for small apps that you want to get going quickly, webpy is awesome.
That's the whole point.
For instance, once you know how databases work, an ORM won't save you that much time -- it'll just shield from the internals, which are what I find interesting.
If you're in it for the long haul, using a framework may well be a false economy - wasted effort.
The other point is that not using a framework can give you an advantage over your competition. It depends on what is important to your success.
Don't underestimate the amount of code needed to generalise over all cases a framework needs to support. Not using a framework does not mean to write that same kind of code myself because I only need to generalise over my own cases not everyone elses.
Frameworks _must_ generalise further than I do in any particular project because they cover a much wider range of cases. It's not just "magic" frameworks or badly designed frameworks, it's simply the logic of what frameworks are.
Therefore this claim you make is just not true: "but if you didn't have the framework, you'd have to learn all that just to get your app off the ground"
I think the term "hacker" has two definitions around here and in the web-development world.
* Those who are interested in the internals of the system at the lowest level (non framework hackers) * Those interested in developing and hacking the framework it self as a platform and knowing all the details and hacks on it (framework hackers).
Regarding the non-hacker just-programming-for-work people, I totally agree with you.
I think either type of hacker would be happy with using a framework if it wasn't closely related to what they need to do. For example, my latest app has a ton of Javascript code, but still needed some functionality on the server. I used Django to get that part done with quickly. For the actual Javascript, I used jQuery as a library, not an application framework.
As a side note, I feel Django does a pretty good job in being transparent. Once I've got it set up, it's transparent where in the view what loads and calls what, even if it is the loading/calling of templates and models. On the other hand, I never did get very far into Rails.
That being said, I know programmers who don't know SQL outside of an ORM, and if it hasn't bitten them in the ass yet, I am very confident that some day it will. I'm a hacker in that I will occasionally write my own http client or something like that, just to learn a new language or networking engine. I'm a professional hacker in that I'd just as soon use one already created by a competent person (or persons) and use my time to write something more interesting.
The mantra of "good coders code, great steal/reuse" has, for my entire career, more or less proven to be true.
Libraries are like strangers. The application and the library have a very strict interface. They stand arms length away. If something is malfunctioning in a library, you don't touch it, you either make the fix in application-space or use another library. There is a very distant separation between the two.
Frameworks are like spouses.. you marry in to them. They hold you hand, set rules, tell you how things will be done. This can be a good thing. You can accomplish things very fast. But if something is wrong between either one of you, you will have to get involved neck deep trying to figure out what's wrong, and fixes need to be applies to both. Just like a marriage, it's easy to get in to, and things progress very fast and happily, but if stuff starts going sour getting out of one is no fun.
Choice quote: I’d really like to give you this fork Jimmy, but you’re gonna need a knife and plate to use it.
But if you're any NIH on the side, the framework-as-bunch-of-easily-integrated-libraries approach really makes more sense. It also lets you try a framework incrementally, therefore decreasing risk instead of committing to a behemoth framework prematurely.
My framework would ask me how many people I want for dinner, what mood I'd like, and what should be on the menu. Then it would surround my table with exactly the right number of chairs, lay out appropriate crockery and cutlery for the courses, and switch on suitable lighting and music.
It would also give me a facility to override its choice of lighting and music to specific settings if I wanted to, and a way to tell it one of my guests is left-handed and another is a vegetarian so their places at the table can be adjusted accordingly.
Of course, my framework would suck at laying out food for a finger buffet for 50 at my big party, but then if that's what I wanted, I doubt I would have started with that framework anyway. And I'd still have to decide on the music and lighting.
The facility for including a child at the dinner just says //TODO.
In a decent framework, there are usually hooks for lots of stuff, but much of the time you don't use any particular hook because the default behaviour is what you want. In your case, it ought to have been possible to override the vegetarian dish preparation with a version completely of your own creation if you wanted to.
But in any case, there's not that much difference between this and building a project around a specialised library that doesn't have a whole framework: you're still screwed if you discover late in the proceedings that it's got nasty bugs and whoever produces it isn't willing or able to fix them. (If you get to invent another library that conveniently provides the same interfaces and has no bugs to use as a drop-in replacement, I get to pull an interchangeable and bug-free framework out of the same magic hat.)
The effort of replacing a library should not involve restructuring all your code as if you were replacing a framework. If you find yourself restructuring your whole code to accommodate changes in the library, maybe it was a poor library, too framework-like. :-)
I guess the distinction just seems rather artificial to me. It may theoretically be riskier to use a framework, in the sense that working around its limitations may be harder to do in the worst case. However, if you're working with bad interfaces and reluctant support, and the library is of any significant size and complexity such that you couldn't just reimplement it yourself in a worst case scenario, then you're basically screwed either way. Being only 75% screwed instead of 85% still doesn't ship your product. :-)
a framework calls your program whereas your program calls a libraryUnusual examples: A java applet is a framework. A SAX parser is a framework. Event-driven GUIs are frameworks.
Any exceptions?