Kay lives here

working with the web

rollerskates

Another angle on the frameworks debate

image.png

This post started life as a com­ment on Akash Mehta’s post on the Site­Point PHP blog Last we checked, PHP IS a frame­work, but it started to get long and ranty so I moved it over here.

I’m allowed to rant on my own blog, right?

Akash wanted to point out that an argu­ment often invoked in PHP vs Ruby on Rails debate — namely that Rails is a frame­work whereas PHP is a lan­guage and thus they can’t be com­pared directly — is not quite right because PHP was designed for the web and as such, it’s a frame­work as well as a language.

I think the same argu­ment can also be applied, to some extent, to Cold­Fu­sion. It prob­a­bly fits even bet­ter because Cold­Fu­sion, which pre­dates both PHP and ASP, was designed with speed and ease of devel­op­ment in mind, so the things that devel­op­ers need to do all the time – query­ing data­bases, loop­ing over result sets, send­ing email, doing remote requests – are built into the core lan­guage in such a way that they can be accom­plished in as few lines of code as possible.

This brings another dimen­sion into the frame­works debate (dis­claimer: I’m a big fan of for­mal frame­works). Is there a point where a web appli­ca­tion is so small or so sim­ple that adding a frame­work sim­ply adds unnec­es­sary over­head? Should the fact that Cold­Fu­sion is so web-application-centric be enough for the devel­oper to get the job done? I’m inter­ested in your thoughts.

Of course, Cold­Fu­sion has a very healthy frame­works scene whereas I get the feel­ing frame­works are not as wide­spread or pop­u­lar in the PHP uni­verse. Does this reflect ColdFusion’s greater focus on the enter­prise mar­ket – where appli­ca­tions tend to be larger, more com­plex and inte­grate with other tech­nolo­gies more? Is the fact that PHP has always been free and open source attract­ing a dif­fer­ent kind of devel­oper? Will the recent Open Blue­Dragon and open source Railo announce­ments change the CF devel­oper pro­file? Or is it too late for that?

Where was I even going with this?

So thanks Akash, for your deep thought-inducing post. I do have to dis­agree with your open­ing state­ment, how­ever — “When it comes to web pro­gram­ming lan­guages, PHP prob­a­bly holds the record for cop­ping crit­i­cism from the com­mu­nity at large” – I think the world title for Web Appli­ca­tion Lan­guage Whip­ping Boy is ColdFusion’s by a long shot!

10 Comments

  1. Dom, you’re such a hope­less fan­boy :D

  2. Pingback: PHP is not a framework at node.mu

  3. http://codeigniter.com — A PHP Framework.

    I have no other point but to shame­lessly pro­mote it :)

  4. Sorry, I dis­agree. PHP is a lan­guage. It just so hap­pens to have bind­ings for web stuff, which makes it a web lan­guage. It’s like say­ing Mat­lab is a maths frame­work — it’s not, it’s a lan­guage that has maths stuff built in.

    Besides, you can write com­mand line pro­grams and even win­dows (GTK on Linux at least) pro­grams in it, which kind of kills this debate.

    Hmmm. I should really post this on the orig­i­nal blog post :P

  5. As Myles said, PHP is no more a frame­work than Lua, or Ruby, or C++, or Com­mon Lisp, or any other pro­gram­ming lan­guage. Even fur­ther, the term frame­work tends to imply some over­ar­ch­ing design prin­ci­ple or phi­los­o­phy — some idea of ‘this is how we do it’ — that is entirely lack­ing in PHP. They can’t even fig­ure out how to work around the lack of name­spaces by append or prepend­ing to the name of every symbol…

  6. Myles and Thomas — I wasn’t really com­ment­ing on whether the state­ment “PHP is it’s own frame­work” was true or not — in actual fact, I don’t really care either way. The OP’s side has an answer they believe is true, based in prac­tise… your side was an answer that you believe is true, based in com­puter science.

    What I did find inter­est­ing was that the argu­ments being used in favour of PHP work even bet­ter when applied to Cold­Fu­sion. But I can get a bit one-track-minded like that :)

  7. There’s another one for PHP called Horde…

    But I was think­ing … I dunno… lan­guages that prompt crit­i­cism… How about Lasso + File­Maker? :) You know with all the talk about LAMP stacks and LAMBDA stacks, they could set up a Lasso Apache Ubuntu File­Maker (LAUF) stack, that’d be a hoot. :)

    Though seri­ously, I think from within any given soft­ware com­mu­nity it tends to seem that the com­mu­nity is always under attack from the out­side, whether it’s Microsoft tech­nolo­gies or Adobe techs or PHP or Ruby. If you study cog­ni­tive sci­ence at all, you come to real­ize that those sorts of skewed per­cep­tions are fairly universal.

  8. In response to the ques­tion, “Is there a point where a web appli­ca­tion is so small or so sim­ple that adding a frame­work sim­ply adds unnec­es­sary overhead?”

    From my per­spec­tive, a resound­ing yes. If you are writ­ing a small app all on your own and odds are that nobody else will ever touch it, just crank the fast spaghetti code. Heck, put the whole thing in a sin­gle file even. ;-)

    Now, I do sup­port frame­works, but they have their place and the quick and dirty CRUD apps that are more of a util­ity than any­thing else just don’t need it. I liken it to the peo­ple who feel com­pelled to nor­mal­ize a data­base down to using a table named GENDER with three columns, ID, GENDER_CODE and DESCRIPTION and ensure all the con­straints are there so the par­ent table stores the ID. Come on, just put M or F in your par­ent table and save the frame­works for the apps that really need/demand them. ;-)

  9. @Brad … I actu­ally agree with your assess­ment… How­ever I per­son­ally find that even for a really small app that only I’ll ever use, I’m able to crank it out a lot faster using DataFaucet and the onTap framework.

    That’s in part because the onTap frame­work doesn’t require men­tal acro­bat­ics around the notion of an “event” and its “results”. It cer­tainly allows you the abil­ity to code that way if you find a need, but it’s just as easy to just write a sim­ple page that cre­ates a DataFaucet activere­cord and uses that to pop­u­late a form.

    The other half of that story is that all the data nor­mal­iza­tion is already done and han­dled by the activere­cord. Before I cre­ated DataFaucet actu­ally, I wrote an arti­cle about port­ing Ray Camden’s Galleon forums to 4 dif­fer­ent frame­works (onTap, Mach-II, Model-Glue and Fuse­box 5) and although I didn’t port to any other ORMs, I did port the queries to the onTap frame­work ORM (now DataFaucet). That sub-article is also included in the DataFaucet doc­u­men­ta­tion, show­ing how I removed about 500–600 lines of code from Ray’s orig­i­nal components.

    On a very small app for just myself, I wouldn’t expect to see that many lines of code removed. If I mea­sure the amount of time I spend cod­ing how­ever, I spend less time and get more done when I use DataFaucet and the onTap frame­work. So it’s not always true that using a frame­work is extra over­head in terms of man-hours. In some cases it means fewer man-hours.

    Do I need to use DF/onTap for those apps? No. But I use them there like I do for other projects, so that I can get them done faster.