In the previous entries in this series I’ve been talking mostly about the benefits of the new web frameworks that have been popping up over the last year or so. And from a programmer’s perspective, there are certainly a number of benefits:
This time around, though, I’m not really going to be focusing on the benefits of web frameworks for programmers, because hopefully they’re pretty obvious to that audience — programmers wouldn’t be creating frameworks in the first place if they didn’t see the advantages.
But if you hang out in the right places, you’re likely to see a lot of programmers complaining about, rather than praising, frameworks; there are several common criticisms that come up over and over again as justification for dismissing web frameworks and their advantages. So in today’s installment I’ll be picking up some of these criticisms and doing my best to respond to them.
At first this seems like a logical argument — if you have the skill to do a thing, then you have no need for someone else to do that thing for you. But this ignores the power of convenience; sure, you could write all your own data-modeling code and all your own database-access code and all your own dispatching code and all your own templating code. But do you want to?
Maybe you’ve met some programmers who write desktop applications. Do you ever hear them saying “I know C and how monitors and graphics cards work, so why do I need someone else to write a graphics API for me?” How many of them do you know who bypass the operating system and hardware drivers and try to control the read-write heads of the disk drives themselves?
In one sense, a good framework is like an operating system; it takes the sorts of common low-level tasks that everybody needs, and deals with them for you; then, instead of writing code to handle those tasks yourself, you call on the framework’s APIs.
Though a good framework, just like a good OS, knows that there are still times when it’s useful to get a little closer to the bare metal, or its web equivalent. Which is why all the popular ones let you bypass their object-relational mapping and database APIs and just write SQL if you’ve got a situation where that’s the most efficient thing.
In that case, I sincerely hope you’re writing in C or some other compiled language. If not, you’re already trusting someone else to write part of your application — you’re trusting the people who wrote the PHP interpreter, or the Perl interpreter, or the Java virtual machine or whatever interpreter your language of choice uses.
Of course, if you wrote your own interpreter or VM, then you may ignore this point. Also, I salute you.
And odds are that you’re not just using the core language, either; if you’re a PHP developer you’ve probably used something from PEAR. If you’re a Perl developer and you’re not using CPAN, then you’re even crazier than most Perl developers I know. Every language in common use on the web is modular to some extent, and I’ve yet to see a developer who hasn’t taken advantage of that at some point.
So it’s pretty much a given that if you write web applications you’re already trusting someone to write some of your code for you. So rather than issue blanket statements about how you don’t trust anybody, and which frankly just look silly at this point, why not treat a framework the way you’d treat any other library or set of libraries?
Some of this is alleviated by the fact that most of the new frameworks are highly modular; if you don’t need a certain part you can leave it out. But again, this starts looking silly when we consider it in context; if you write PHP web apps, do you grab PHP’s source and strip out all the language features you’re not going to use? How many people do you know outside the embedded application world who recompile C libraries to remove everything they don’t need?
Frameworks are libraries of code which are intended to serve general-purpose use, which means that, like any general-purpose library, they’re going to include functions you don’t need. But the functions you don’t need are going to be different from the functions Bob in New York doesn’t need. And the functions Bob doesn’t need are going to be different from the functions Carol in Seattle doesn’t need.
That libraries will include more features that you’ll probably use is a constant of every type of programming. But having those features available is, for most use cases, not problem; the extra overhead of the codebase isn’t an issue (again, unless you’re doing embedded development which, if you’re a web developer, you’re probably not) and the convenience is too much to pass up.
This is based more on misunderstanding than anything else, and the misunderstanding seem to be based mostly on a feature in Rails called “scaffolding”. Scaffolding is an optional feature Rails offers — yes, that’s right, you don’t have to use it — which will look at your models and generate some stub views for you that implement basic CRUD functionality. This scaffolding works much like its physical-world counterpart; it’s a temporary structure that helps you get started, and that you throw away once you’ve finished building.
So this isn’t really the sort of code generation that programmers (rightly) tend to avoid. I’ve seen Django‘s admin application criticized in much the same way, again because of misunderstanding; the Django admin app doesn’t generate any code at all.
There is one place where frameworks do generate code which is intended to be used in the final application, though: when you’ve defined your models, they almost all will output the necessary SQL statements to create the appropriate database tables. But this isn’t an absolute: you’ll be able to edit those statements before they’re executed, if they’re not to your liking, and there’s typically also a mechanism to introspect an existing database and derive model definitions from that instead of having the framework create the tables for you. So again, this isn’t the sort of code generation that good programming practice tries to avoid.
I’ve been taking notes over the last month or two every time sites like Slashdot ran stories about frameworks, trying to keep track of the most common criticisms programmers were leveling at them, and I think I’ve covered all the big ones above. Sometime in the next couple days I’ll publish the fourth and probably final installment of this series: frameworks from the DBA‘s perspective.
Comments for this entry are closed. If you'd like to share your thoughts on this entry with me, please contact me directly.
I’ve started learning php by using freeform-framework it provides me with almost everything i need: MVC aproach, templates, SQL API, and so on. 1 drawback i think is very important that most time it keeps me off learning essentials of WEB development: request/response mechanism, headers, cookies and stuff. But i can look under the hood any time i need it, and i’m pretty confident i’ll see the best practices there.
So my point is that good frameworks are good even for newbies :)!
It’s always a good idea to know how web apps work, regardless of whether you’re using a framework or not. But if you don’t then, as you say, reading the framework code can often be a good introduction.
Okay, first, let me just precursor this with saying, “I like frameworks.”
“I don’t trust other people to write my application for me.” The problem has been a numbers game. How many people use an OS? How many people use a web server? How many people use a scripting language like PHP or Python? Now, how many people use FrameworkX? Each is a fraction of the first. I become less and less trusting the closer to my application it gets.
Now, Joe Cool working in CorpX has a project coming up. He has a month to finish it. Which framework does he use? If he does it himself, he should be fine. But if he decides to use FrameworkX and it turns out that it doesn’t meet his needs, he’s blown his deadline.
Using your kitchen analogy from another post, imagine coming into a kitchen and deciding to bake your cake. Everything looks good. Bowl, check. Mixer, check. Ingredients, check. Okay, let’s make my cake! Batter’s ready and oh wait… I don’t have cake pans!
Frameworks, including Django and RoR, also don’t really explain their application structure well enough. They try and sell the sizzle, “Look how easy it is to do X or Y!” That’s great, but I’m not creating a blog. I’d like to see a nice diagram showing the flow of execution within the app. Does it match my programming style? If software is opinionated, I want to make sure your opinion is in line with mine or we’ll be having an argument or two by the time the evening is done.
Jonathan, I can’t speak for Rails, but I guess I don’t understand where you’re coming from in saying that Django’s application structure isn’t explained well enough; the offficial Django tutorial walks you through the parts of a simple application pretty much in order (write models, write views, write URL configuration, write templates) and explains how they all fit together. The rest of the documentation goes into detail on each of those components.
Could you provide specific examples of things in Django’s documentation that you feel gloss over important parts of structure, or focus too much on “gee whiz” at the expense of everything else? I’d like to get any such things in our documentation fixed ASAP.
And as for trusting code, you’re right in that one of the biggest factors to judge by is who’s already using something (the other, as I’ve mentioned, is looking at the code yourself).
I’m not sure that your example is accurate, though, because I don’t know of any good programmers who, on a tight deadline, would use a tool without knowing in advance that it could solve their problem; frameworks don’t tend to have steep learning curves for experienced programmers, but they also can’t be picked up overnight — the choice to use one or not needs to be made when there’s time to conduct a proper evaluation.
Let’s go back to the Joe Cool example (Which is entirely accurate, because that’s right, no good programmer on a tight deadline would do that. That was the point — and why I used it as an example.)… He’s looking to make his life a little easier and wants to find a framework? How is he supposed to pick one? Just one. Take the top 5 frameworks and read 5 pages of documentation from each one. Heck, take a look at RoR, Cake, CodeIgniter, Django and you’ll notice huge similarities. Are they all the same?
How much documentation do I have to read to understand which of these is going to solve my problem? What IS my problem? (don’t answer that! :) )
Specifically, what I’d like to see is a nice diagram that shows how each thing works together. From Request to Response. URL Mapper -> Controller -> View -> Models (or however it works). Use some class names with some links into the documentation. THAT would be great to see.
Btw: I think Django has one of the best sites when it comes to explaining what it can do.
Hmm.
Diagram’s a good idea. I’m not a graphics whiz, but I know a couple; I’ll poke them and see if they’d be willing to help out.
I think going beyond that a better solution is, as smarmy as it sounds, to try to get some successful use cases and organize them to show people who had specific problems and how a framework helped solve them. Need to let that percolate a bit, I think, and figure out how best to handle it.
I was just about to post a comment about this on another entry (re: when FW aren’t right). My thought was referring to the
Adminfunctionality specifically, as “raw” Django seems probably flexible enough to do most anything. But if I could use/leverage/extend/etc. theAdminfeatures it would be a huge win — the kind that makes the decision on using a FW, and in many instances sets Django apart.So use cases of extending
Adminfeatures would be a nice addition; see if you can snap your fingers and have it done ;-) I have seen some apps with examples of where people are starting to do this, but input from those with more experience doing it would be great. Even a simple list of a few approaches to extendingAdminwould be good — including the common answer, “use the admin js hook”, and so on.Depending on what you want to add, extending the admin app can be easy or it can be hard; it’s one of those situations where we “make the easy things easy and the hard things possible”.
For example, the admin templates and template tags, on top of the
jsoption, provide some nice hooks for easily adding or overriding certain types of functionality, but I don’t yet have enough experience with that to write it up; maybe someone else who’s doing that sort of work could be poked and prodded into it :)Yep “make the easy things easy and the hard things possible” is kinda the crux — I need to figure out if it’s making non-easy things harder rather than possible (by having to work around/within the existing built-in assumptions). It will of course depend on what I need to do for a particular app need. I guess at this point the only way I’ll be able to tell is by rolling up my sleeves and digging in…