I'm not sure there's a lot of weight in the author's argument. The crux of his argument is that you'll eventually need to learn how the framework does what it does. Of course you'll eventually need to do that, but if you didn't have the framework, you'd have to learn all that just to get your app off the ground. It's a premature optimization to not use a framework. The key is to use a well designed framework that makes sense and doesn't get in your way once you have to start digging through its internals.
I do agree on one point though, for small apps that you want to get going quickly, webpy is awesome.
I agree with you on premature optimization. However, once you've learned how the internals work, using that framework doesn't save you much time in the future.
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.
No, I don't have to learn how highly abstracted ORM code works to get my app off the ground without an ORM. ORMs are much more complex than straight to the metal SQL or writing to a text file.
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.
That's the difference between using a simple, straightforward framework and "magic" framework. A well designed framework should expect that its users are going to need to dig through the internals and should design accordingly. It also should not force you to use any particular abstraction if you don't want to. Don't need an ORM? Don't use it.
Sorry, but you are just repeating framework marketing fluff. Have you read what I said about generalisation at all?
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, that´s the difference between professional programmers and hackers. Hackers cant stand to write code without understanding what is happening behind the scenes. Therefore they need to go deep into their codes and understand each aspects. In the other hand, when your code for a big company and follow a lot of rules and demands, you are more inclined to use solutions like frameworks, because you are not having real fun, your are just ... working. Make sense for you ?
I would disagree. I use frameworks because (a) they save me loads of time and (b) I already know how all that garbage works anyway. I know how HTTP cookies work; I have no desire to implement sessions myself because they're a waste of time and, frankly, proper cookie handling is a pain in the ass.
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.
This is what I would guess at first sight too, but reality disagrees: it seems lot of people around HN are very religious of their frameworks...
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.
Even in the web-development world, that might be too general of a description.
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.
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.
Bah. Why monolithic frameworks suck. If the framework is implemented as a bunch of nicely integrated yet modular libraries that you can use standalone, you can use the fork without the knife and plate.
Part of the benefit of monolithic frameworks is the third party tools built on top of it. If you choose libraries independently, you've avoided reinventing a few wheels, but there is more functionality you could avoid reimplementing than just the basic database interaction, template system and request handling.
There's a bit of a paradox here: a monolithic framework gives you less choice because you can't use only a part of it without great pain, however you have ostensibly more choice of functionality from third-parties since there's a standard way to use it that's hard to diverge from.
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.
I'm not sure that article is a fair discussion. To me, the framework wouldn't do as your quote says.
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.
Unfortunately, the "vegetarian" option was written by someone who eats bacon every day, and it's really buggy. Since it's wired into the framework, though, figuring out why it's serving chicken nuggets to the vegetarian is difficult.
The facility for including a child at the dinner just says //TODO.
I appreciate the joke, but you can have software that sucks whether it's a framework or a less structured library.
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.)
Having not enough hooks != having bugs. Library authors have to worry about being bug-free; framework authors have to worry about being hook-complete AND bug-free.
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. :-)
Sure, libraries don't need to worry about hooks, but they do need to worry about providing sufficiently flexible APIs for use in different contexts instead. Sooner or later, you've got to connect up your custom logic to the library/framework's general logic.
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. :-)
My favorite thing about frameworks? Whenever I go to a shop that uses them, I could always write something without the framework that looks like I used the framework but does things they never thought possible.
I do agree on one point though, for small apps that you want to get going quickly, webpy is awesome.