I'm not a hardcore programmer by any means, and I don't claim to really "know" Python, so this statement may not be 100% true, but I think it's close:

Learning Django is learning Python. Django isn't a domain specific language for Python. Django is just a set of Python libraries that give you a ton of useful functionality.

Jeff's completely right. In fact, the whole point behind Django's recent "magic-removal" work is to make Django behave the way any Python programmer would expect it to.

Frankly, all the framework bashing mystifies me. Jonathan, PHP *is* a web development framework (just not a very good one) -- it provides an environment for web development, so what else qualifies something as a "framework"?

Sure, you *could* write hundreds of lines of form validation logic, but why not let someone else's work do the heavy lifting?

Put another way, you *could* start your next web site by writing a web server, but why not use Apache? You could write your own data storage layer, but PostgreSQL/MySQL is much quicker.

Hell, you could start your next site writing an operating system, but I'll bet you trust Linux pretty well at this point.

Disclaimer left off my previous post: I am one of the lead developers of Django, so that's is all in my (not-so-) humble opinion.

I'm not sure .NET can really be be listed along with the other frameworks per se. It seems like "the .NET framework" is sort of a misnomer -- is it even a framework? ASP.NET certainly is, but .NET itself? Can you learn C# without learning .NET? Is that possible? What does "learning .NET" even entail?

( ... This is coming from someone who programs in C# on a near-daily basis ;) )

I took Jonathan to say simply that learning a framework is work. takes time, it's not as easy as some of the developers of the framework make it out to be. while it may not be intensive as learning the whole Python language, learning where to put the statements to enable the magical admin, or whatever else you do to build a website that is framework specific is what it takes to learn the framework, and why it is similar to learning a new language.

yes, the classes in the framework that do validation are very helpful, but there still is learning curve to figure out what those are. sure, this is obvious, but from what I read in those in the frameworks, this gets minimized. think blog in 15 minutes.

I don't think communicating this to people from experience is "framework bashing", but offering a realistic perspective on the frameworks. they save time, and may be very magical, but still have a learning curve that can be fairly steep.

It really depends on what your making, Generally I think learning the model view controller pattern will help you learn any frameworks that follow that pattern and for apps that have alot of forms pointing to database tables its really nice to have some built in automation for that. If your like me and have worked with other peoples php code you most likely will welcome the learning curve associated with frameworks as an alternative to learning the spaghetti code system they left you.

I'm a Java developer who primarily uses the Struts framework. I agree with Jonathans comments completely.

A lot is dependant on the scale of your system when you decide to use a framework. For a small system (this even comes from the Jakarta Struts website), it's probably not a good idea.

I find Struts (frameworks) invaluable on larger scale systems. It's ability to maintain a decent MVC is great and allows me to extend/support the system with great ease.

I firmly believe that larger scale systems should be supported by a framework. They simply enhance productivity.

Allow me to paste a comment I made on Eric Meyer's piece (there's a dual conversation going on on the subject). This is to reply to the "frameworks are limiting" argument.

Listen: HTTP architecture is request and response. The user press something on your webpage and the browser sends a request to the server, which in turn sends back a request to the browser to display. Any kind of web stuff you make has to be built on top of this limitation. Good MVC frameworks as Cake or RoR just put a class listening to your request (the controller) and another one to print the response back to the screen (the view). Those two instances (request - response) are a given in the web development world and there’s no way around them. inside the controller, the model or the view you can do whatever you want and whatever you used to do with procedural coding. Frameworks just lay the ground for you to place your code in the right places and enforce task separation, which is a good thing. I really don’t see how a good framework can keep you from doing complex stuff for the web.

Jonathan - I started reading your site when you posted the prequel to this article, and for the first time, I was reading what, in my opinion, was the work behind using a framework.

I think many people get drawn into frameworks not because of what they offer, but because it's the new cool kid on the block, Rails.

I also don't think that this is necessarily framework-bashing. I can't see a direct line here that straight up says frameworks in general suck (apart from the title).

I also am against the comment that said learned Django is learning Python. I would give myself enough credit to call myself a knowledgeable Python programmer, but Django was a totally new idea for me. Don't get me wrong, I think in the correct situations it is invaluable, but learning to use a framework is learning to think in that frame of mind, and learning the syntax of the framework itself (yes, I 100% believe that Django/Turbogears/Rails are abstracted enough to have their own syntax).

At least Django's documentation is pretty good.

But again, in that the reason the Ruby learners are learning it because they want Rails, the reason that Ruby HAS a 'de facto' framework is that Ruby isn't one of those 'hugely spread' languages.
If I made a language myself and made a great framework for it (which Rails and Django both indeed are), chances are people would also be learning that language just for the framework. That's not the case with languages like Perl or Python, since they're already widespread enough that most beginning (or advancing) programmers have heard of them. When they hear of Ruby, they also hear of Rails, but Django is for instance not "the" way of writing Python code for the web (which I'm not saying Rails is, but considering the amount of available frameworks, it's pretty damn close).
I'd say Python has two to three of this type of web framework, Rails-scale: Django and TurboGears (you could count Zope too). Here I agree that PHP far from has a de facto framework, simply because none of them are of this quality that the other mentioned ones are.

Well spoken Jonathan, action without knowledge is often called stupidity. Which is a little harsh to say I guess, but the point I take away from your post? Using a framework without understanding ”how is works” will propagate action without knowledge. And that is dangerous ground.

BTW - I hope to catch up with you at webvisions, if I make it.

They don't suck when you know them like the back of your hand. The JavaScript YUI libs have become my best friend. Not to mention I'll always spend an hour here and an hour there just picking apart the original source. It really is a life saver.

If people look solely to frameworks to do their job, they'll never know what the framework ISN'T doing.

You don't know if you don't know...

I have always been against frameworks simply because I felt it hindered me from learning the lanaguage, and in the process, I always felt I could just build my own for my own use.

"If people look solely to frameworks to do their job, they'll never know what the framework ISN'T doing."

Unless, of course, they DO understand what the framework isn't doing.

My point is the same as Snook's: if you use a framework, try to understand how it works.

That having been said, I'm not sure there's any great need to understand the ins and outs of the framework to get started. One of the beautiful things about frameworks is the low barrier to entry and success. It's definitely a good idea to understand what all it's doing and what all it's not, but it's not important to understand this before you download the thing and try it out.

A framework is this not merely a library of functions but since they are OO, they are called frameworks where functions can be prototyped, binded and extended.

Moofx and others adapted a larger framework (scriptalicious, protype) to a leight weight version. They did the work - that a developer would normally do - but this gave a ready-made solution for non-proogrammers.

For my internship I had to do a project in CakePHP... lets just say I never finished it, and it got handed off to someone else....

I looked around for a good MVC "rapid development" framework for PHP. I was considering CakePHP but it seemed pretty complicated. Then, I found Code Igniter. It's totally fucking gorgeous.

So simple. So clean. There's hardly anything to learn. It keeps your code clean. It doesn't get in the way. It does everything you need it to and nothing you don't. It's like the framework everyone wants to build but isn't sure where to start.

I strongly agree with your point of having to learn a framework. All these screencast that have become quite the fashion that claim to show you how to build application X in framework X in [insert number here] minutes are tottaly bogus, IMHO. Yes, they can quickly give you a feel of how code in the resp. framework looks like, but if you want to adapt the code just the tiniest bit and build, for example, a guestbook instead of a blog as in the tutorial, you have go to the documentation anyway and read up on the underlying concept. Often you have to go hunting for example solutions in Wikis or mailing list. If you would instead just rebuild the application as demonstrated in the tutorial, what would you learn? Almost nothing.

Chris-

I think you're really missing the point on the screencasts. Screencats aren't intended to teach you something. They're not trying to show how fast YOU can build something without learning anything. They're commercials. They're marketing. They're supposed to be a flashy, whiz-bangy ooh and ahh session. If you want a tutorial, read a tutorial. If you want documentation, read the documentation. Screencasts are neither. They're infomercials. That's it an that's all.

If you want to learn how to use an iPod, do you watch videos on Apple's website? Of course not.

@Jeff Yes, you're right.

But I know at least one framework, where a screencast doubles as a tutorial (I think, you know, which one I mean).

And I don't think that open source software should go for the same blatant advertising lies as proprietary software. Frameworks help you A LOT to get you up and running faster, but they cannot do magic. If you want to get anything serious done, you'll have to spend time on learning them. As a developer I know that and I don't blame the framework for it. Pretending to newbies that building your personal buzzword-compliant web app is a piece of cake and only takes minutes, will only create disappointment in the end (and turn away users).


I don't think the comparison with consumer goods like iPods is valid, because this is a totally different target group. If the screencasts where targeted at the management, I could understand this kind of exaggeration, but for that, there is too much gobbledigook in them.

Completely agree with you regards the frameworks - I've tried the Zend Framework (long way to go still I think), Seagull (overkill, unless you want to do CM) and CakePHP (liked that the best, although don't like the way they've laid their filepaths out - doesn't make sense to me), and none of them have really hit the spot...

Good site! Thanks.credit card

I have built many web sites, that are complex membership based. http://freeadplanet.com is my most recent. Programmed in PHP. Frameworks are similar to adding complexity over complexity, while trying to abstract alittle.

But, any good language, will already have the abstract built into the language.

Example: Getting the contents from a source, be it local file or from a URL, in PHP

file_get_contents('myfile.txt');

Now, what more do you need? Do I need a PHP framework for this? No...

Sure there are some things you need to abstract away, but then this becomes a collection of Class and or Function Libraries. No framework is needed.

Example: Writting a DB class to handle MySQL or Postgre can easily be done by writing a simple PHP Class. Many are available on the Internet, than just require() the class php file. No framework needed.

Frameworks tend to become bloated. And as previous people have mentioned, you end up learning the in and out's of the framework, rather than the language itself.

So, my point is this. If a language you are using does not have the right functions and extentions to get the job done, and requires a framework, than the language is probably lacking and should not be used.

What is worse, is trying to make a framework for a language that does not need a framework in the first place!

Frameworks add massive overhead as well. Not nearly effecient as using the natural API's that come with the language. Like PHP or Python for example.

Lastly, does one want to put on their resume a Django or CakePHP programmer? Or a Python or PHP programmer? I think the latter is more sane.