Posts tagged: WEB FRAMEWORKS

Eric Meyer recently wrote a post titled “Flummoxed by Frameworks” that received a lot of commentary. I belatedly added my own two cents. I have a feeling that this isn’t the last time the subject will come up; I’m copying my own response here (along with the link to Eric’s post) mostly so that I can find it later when I want to explain this to somebody else!

Eric, you mention that you wrote all of An Event Apart’s registration stuff using PHP and MySQL. I take this to mean that you did it once. Imagine if you did it three times, or five times, or fifty times for different clients, with minor variations. Imagine how sick you’d be of re-implementing the same core features over and over. Your approach would change a little bit with each job, as you discovered better ways to implement certain features. Imagine the nightmare of trying to support all those clients each one using a slightly different snapshot of your learning process.

The Zend Framework was released a few days ago. This is a PHP5-only web application framework from Zend, “the PHP company.” It has been in development for a long time, but if that had a chilling effect on the development of other PHP frameworks, it’s hard to see.

I’m going to go straight for my grim conclusion here: I think many of the other PHP web frameworks in development have no long-term prayer against Zend. It’s not about technical merits, it’s about the business case that Zend is a safer bet than five random guys with a Trac install and a cool logo.

Released today: web.py. (Source, documentation, backstory.)

Even though everybody (including Aaron) refers to this as a framework, it’s a lot more library-like than most of the frameworks it’s ostensibly competing with – by design, it seems. It’s very compact – only about 1000 lines of fairly dense Python. (About 275 of those are a template for pretty error pages adapted from Django though.)

Personally, I find the compact, all-in-one style very appealing. Less for a newbie to absorb and less for an experienced user to keep track of. Yes, it does require a template engine and a database wrapper to be useful, but the core is still extremely lean.

Looking at this ticket, endorsed by Subway creator Peter Hunt and this post by Turbogears creator Kevin Dangoor, there’s clearly a non-zero chance that these two frameworks – which are, as I noted in my initial post on Turbogears, very similar architecturally – will join forces.

I agree with Kevin that “saving Python from Ruby” or whatever is not a goal worth focusing on. But focusing developer momentum behind a demonstrably popular web framework model is.

Yesterday, Ruby on Rails 1.0 was released. It came along with a nice website redesign, too. And some teasers:

Rails 1.1 is already pretty far along in development and will see some of the biggest upgrades of any Rails release. Hopefully some time in February.