@TheKeyboard Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.

Welcome to the 4th and final day of reader feedback week here. Today’s topic is one that comes up over and over and over and over again: web application performance. In particular, I wanted to discuss web application performance and frameworks.

After seeing a slide from a presentation at FrOSCON about CakePHP’s performance in the incredibly-unrealistic-and-irrelevant “Hello World” competition against vanilla PHP and other PHP frameworks I came up with that very aggressive statement you see above. That prompted a flurry of tweets by other people about their thoughts on that matter, and so on and so forth. I believe my earlier statements were misunderstood, so I shall clarify them here.

I stand by the statement “frameworks are about increasing development speed, not application speed”. I’ve talked about frameworks plenty in the past, and they all promise you this: if you build things according to their rules (and this is the really important thing to remember) then you will gain a significant increase in application development speed. If you fight against those rules, why are you even bothering to use the framework? The goal is to speed up development time by following a set of conventions on how the application is put together.

So, if you’ve had enough courage to build you application with your framework of choice, you should have a working application. That doesn’t mean it is as fast as it could be, but remember the mantra I shared earlier: “make it work, then make it work better”. Where frameworks typically fall down is in the “make it work better” part of that statement. Travis Swicegood pointed out to me when it comes to frameworks “…actually, a really good one should have mechanics in place to do both” (referring to increased development speed and application speed).

So, if you have a framework that actually cares about application performance (perhaps unfairly some frameworks have decided that performance is sole responsibility of the developer, not the framework itself) then it should come with things to make your application a little more responses. Things like built-in output caching, or features in their ORM/ADM that cache your schema, things like that. But in the end, there is only so much you can to make a framework-built application run really fast. Sometimes you can do it with just the additional features I mentioned above. Sometimes you can’t do it because the architecture you’ve chosen for your application won’t let you. And sometimes, you can’t do anything about it because it’s too hard to modify the framework itself. These things happen. Look at Twitter and all the contortions they have gone through trying to take what was initially a Rails application and push it’s performance up to it’s current level.

There are also lots of 3rd-party solutions to help you make your application perform better. Memcached for caching data (ask me some time about my Memached story at an old job). Alternative PHP Cache if you’re running PHP. Squid. nginx. Mongrel. Those are just the ones I can think of off the top of my head. Some of them are even framework agnostic.

Having a framework that lets you BUILD things fast and RUN things fast is the perfect situation, but not too common. I used to get mad when I’d see people asking if can scale, because I felt it revealed a certain level of ignorance in the person asking the question. I’ve now come to the conclusion that what they are really asking is if can scale without them doing any extra work. Usually, the answer to that question is FUCK NO (emphasis mine) because scaling is an issue that goes far beyond just a simple framework.

See, not every framework is slow. Some frameworks, due to their internal structure, are faster than others. I’m okay with that now, not so okay in the past. In a lot of cases, the bottlenecks in your application aren’t code-related. I’ve come to understand that too, especially in the new Javascript-driven world web applications have started to run in. If you think Twitter is slow because they chose Rails, I think that you do not have a firm understanding of how Twitter actually works. Or maybe you don’t care because it’s easy to make fun of Rails and Twitter.

Luckily, we have lots of free and easy-to-use tools at our disposal that let us look at our up-and-running web application (remember, Just Build It, Damnit!) and see how it’s performing. Things like Siege and YSlow are just two tools that their use will give you huge insights into the actual performance of your web application.

You shouldn’t be GUESSING how your application performs, you should KNOW what is going on.

The summer is always the worst for me in terms of blogging. That’s when I have to run my team in the IBL, play slo-pitch (or softball for my American readers) at least once a week, do side-jobs to help pay the bills, and spend time with the family. Phew. So, that leaves little time for the types of activities that lead to good blogging. But never fear, I will continue to dispense what wisdom I can from here. So, here’s some of the things I’ve been thinking about.

Closures and lambdas coming to PHP

Via twitter I found out that PHP 5.3 is going to have lambdas and closures. I suggest you google around for a better explanation of what they are, but they are an incredibly powerful tool. If you do any Ruby on Rails work, you end up using them. If you use jQuery, you end up using them. I had a conversation in twitter with Mr. Git Book about this, where he accused me of being a “closure hater”. Believe me, I’m not a hater of that particular programming construct. I simple expressed my feelings that given how horribly some PHP programmers abused OOP concepts, I imagine the same things happening with lambdas and closures. Please prove me wrong.

Where The Hell Are The Easy Layout Editing Tools For Non-Designers?!?

I have a side job where I am taking an existing app and converting if over to CakePHP, but preserving the look and feel. What this poor designer-challenged programmer needs is a tool that will take that existing HTML and let me edit it in a fairly intuitive way so I can fix the so-many-damn-tables-I-want-to-bleach-my-eyes layout that exists. Can nobody help me with this? Sheesh. I don’t want to burn up my billable hours fucking around with layouts.

The Framework Jihad

I need a “Framework Jihad” t-shirt. Size 2XLT, please.

Yes, the arguments about frameworks will just not go away. Which one is best?!? Why should you even use a framework?!?! And the more it goes on, the more ambivalent I feel about it. I cannot think of the last time I wrote a PHP script that was NOT part of a framework. Hell, even my Python programming has been 75% Django and 25% straight Python, but that’s only to do things like loading up databases with info from a CSV file. But here’s what I think: the Framework Jihad is winning.

If you substitute “modularized code with standardized API” for “framework”, would that make people feel better? I use frameworks because so much of the infrastructure code is stuff I DO NOT WANT TO WRITE ANY MORE. After 10 years of doing this, it’s time I stopped reinventing things. My old motto of “just build it, damnit!” requires a structure around your application to let you quickly build something. To me, that means a framework that has taken care of database access and application flow and templating.

The number one complaint about frameworks appears to be that they are slow and have all sorts of overhead. Fair enough, but I tell you what: I’ll worry about scaling when I, you know, have something to worry about. If I get to the point where I have to worry about scaling, then I have done very well indeed. Despite our desires, not everyone can create a Flickr or Twitter. They are the lucky ones. The rest of us should shut up and just build something.

It’s just too easy to dismiss the Framework Jihad as irrelevant. Like many things in life, dismiss it at your own peril.

I like to check out the programming section on Reddit on a regular basis because it usually contains some interesting links. Yesterday I came across a link that discussed the fallout surround a presentation at phplondon08 where panelists on a discussion of frameworks got heckled but some guy claiming to be an expert on what a real MVC framework is.

All major Rails clone PHP frameworks that exist on the market today are a complete and utter failure. All of them call themselves MVC frameworks and none of them implement actual MVC. In fact, some of the worst ones merely resemble MVC, and have no right whatsoever to be called frameworks. Whatever benefits of sexy ORMs and flexible build systems and scaffolding and other secondary tools these frameworks have are nullified by the fact that using them results in architectural chaos which is no better than your usual spaghetti code. This is because the people who wrote Rails didn’t bother to understand MVC, and the PHP amateurs who were excited about the idea of getting done more in less time blindly tried to clone Rails into PHP and in so doing not only replicated the stupidity of Rails into PHP but also multiplied it by their own incompetence and PHP’s shortcomings as a language and a platform.

No, tell us how you really feel about it.

Anyhow, this guy apparently works for the Agavi project, a (wait for it) MVC framework written in PHP as an “evangelist”. Well, he certainly talks like you would expect an evangelist too.

The comments for that post are really interesting too, as people take their usual swipes at PHP, and CakePHP, and the Symfony guys come out in droves to talk up Symfony, and on and on it goes. Sadly, this is not a unique occurance on the web.

So, back to the topic of the post. Is this guy right? Is *nobody* except Agavi doing it right on the PHP side of things? I took a peek at their documentation. Lots of statements about what a framework should and shouldn’t do.

(Author’s note 03/10/08: removed code example as, well, it’s not really relevant to the discussion, other than making me giggle about mixing business logic with presentation logic)

Digging through the documentation some more, it’s quite dry. Short and sweet, not a lot of tips on building an Agavi app from scratch. Again, to be fair, that might not be the point of the documentation. But it’s approach is very, *very* different from the “Rails way” that CakePHP has been following. Before you flame, there is nothing wrong with the “Rails way” because, if nothing else, it has forced developers to crank their skills up a notch and actually *think* about what they are building.

I knew one of the original developers of Mojavi (of which Agavi is a fork) and he was a really smart guy (Hi Shawn!). My early forays into framework use was with Mojavi, when trying to convince a previous employer that we needed to rewrite this monster PHP application with Mojavi so we could get things like a private branding version of the site done a lot easier.

When I compare this to Cake, they are as different as night and day. Agavi (and Mojavi) are heavily configuration-oriented (XML *everywhere* for config files), while Cake uses conventions to try and speed things up. But the real truth is this: they are both trying to separate your business logic and your presentation logic to make things easier for the poor saps who have to build these applications.

Our lovely heckler has missed the forest for the trees, as far as I’m concerned. It’s like complaining that you can’t call it a forest because the trees aren’t growing straight up and down, but tend to branch out in different directions. They’re still trees, right?

Frameworks are designed to try and help you to get things done faster *and* to organize your code in a much more consistent manner. Cake uses the Model-view-controller design pattern, and I think that the quote below makes it clear that Cake is doing it the right way:

Model-view-controller (MVC) is an architectural pattern, which at the same time is also a Multitier architecture, used in software engineering. In complex computer applications that present a large amount of data to the user, a developer often wishes to separate data (model) and user interface (view) concerns, so that changes to the user interface will not affect data handling, and that the data can be reorganized without changing the user interface. The model-view-controller solves this problem by decoupling data access and business logic from data presentation and user interaction, by introducing an intermediate component: the controller.

If you are trying to tell me that CakePHP does not follow that practice, then I am calling you a fucking idiot who is more interested in pedantic minutiae than understanding that there is more than one way to implement MVC.

As devoted as I am to the use of frameworks (although not THAT devoted that I would take the anti-lazy-programmer’s route of porting an existing non-frameworked app to use a framework) I do enjoy seeing what frameworks in other languages are up to. I’d like to share three with you that I’ve been following for a variety of reasons (mostly curiousity).

I’ve mentioned ErlyWeb in this blog before. Created by Yariv Sadin, it’s a web framework built to run on top of Erlang, which is a programming language created by Ericsson (the cellphone people) and open sourced a while back. Why do I feel it’s worth checking out? Erlang is legendary in it’s ability to supply a robust concurrent environment. When you use it to run phone switches, it has to stay up! 99.999% uptime makes Erlang barely break a sweat. Now, as web 2.0 morphs into Web Pi, there will be more demand for the type of interactive web apps that require statefull connections. The most common “Ajax design pattern” that requires concurrency is comet, where you want to continually push information to the client without it having to request that information. Given that much of the web is stateless, this is usually implemented as ‘pull’ with clients repeatedly polling data sources. Anyway, that’s a whole another discussion and I’d want to do lots more research before I get into that. Anyway, Erlang is ideally suited for large-scale interactive applications that would be sending information back and forth. Check out what Yariv’s been talking about.

My friend Kevin is a Perl hacker and he mentioned Catalyst to me and then I heard a great podcast over at FLOSS Weekly about Catalyst. Now, I’m not a Perl guy (I’ve used a little bit of it as part of the data-munging effort for the game the IBL uses) but if you’ve made a big investment in Perl and want to move forward with some more modern web applications then I think Catalyst is a great option. Listen to the podcast.

Finally, I took a very quick look at a web framework written in Scala called Lift. There’s a great write-up about it by Tim O’Reilly, and I think I will look into it further. Why should I care about Scala? Well, it looks very similar to Ruby in it’s syntax (and I have a smattering of Ruby experience) and it’s multithreaded (which should theoretically scale better on a single machine I believe). Besides, it never hurts to learn a new language. Evolve or die, right? I have a VPS that I can fool around on so why not see if Lift (and Scala) is worth investing some time into.