If you're like me, one of the first things you do when starting a new
web application project is set up a CSS alternative such as LESS or
SASS/SCSS. Those who aren't particularly fond of JavaScript might also
tend to add CoffeeScript. These "metalanguages" can assist in making
client-side/asset code more pleasurable to work with, as they typically
provide functionality that's "missing" in the the languages they get
interpreted into.

Some frameworks (e.g. Ruby on Rails) give you support for these
alternatives out-of-the-box, but in the land of less opinionated
software things can require a bit more work. Since I am personally a fan
of the
Pyramid
web framework, I've used the
pyramid_webassets
and pyramid_fanstatic
packages in the past to provide this support. However, these packages
are so powerful and comprehensive that they can also tend to be somewhat
involved in regards to configuration, so I recently decided to roll my
own Pyramid
add-on: pyramid_assetmutator

Although definitely not as "feature-full" as the packages I have
mentioned earlier, as of this writing it provides the following:

Support for piping (a.k.a "mutating") assets through pretty much any
command you like (its core functionality is quite rudimentary).

The ability to specify whether to have your assets "mutated" during
each request, or on each "application boot" (typically best for prod
setups).

Due to the popularity of these posts, I have decided to move
all of the benchmarking information over to its own dedicated page.
Please see the new framework shootout page for the latest
information.

This post is the continuation of a series. Please read Round 1, Round 2, and Round 3 first if you
are just now joining.

While I had originally intended for round 4 to showcase how
microframeworks are changing the way we do "quick and dirty" web
development (and how they make using PHP as "an extension to HTML" old
hat), my current programming habits have kept me involved in the more
"full-stack" framework solutions. So, rather than spitting out various
benchmarks of frameworks that I have little or no interaction with, and
since enough time has passed since the last "shootout" that the
landscape has changed a bit (with the introduction of
Pyramid and the release of Rails 3), I
have instead decided to showcase the most recent data on the frameworks
that I personally find myself in contact with on a regular basis.

Warning: Everything is different this time around.

These benchmarks were all run on a fresh Amazon EC2 instance in order to
(hopefully) achieve a more isolated environment. Obviously, since these
benchmarks have all been run on a completely different box than any of
the previous rounds, no previous data should be compared with these
numbers.

I recently sat down to coffee with a new acquaintance of mine who spends
much of his time implementing F/OSS projects at non-profit
organizations, and who had just stepped into a lead web developer
position using PHP. After sharing pleasantries we began trading stories
and talking about each of our "tools of the trade." When I mentioned
that I used to do most of my web development in PHP, but have spent the
past year or so trying to move as completely as possible to Python, his
response was: "Huh, I have never really thought of Python as a PHP
replacement."

Now, this guy hasn't exactly been living under a rock for the past 10
years—his resume was quite impressive and included projects in a number
of different programming languages—but as you can imagine, I was rather
surprised by his response and it made me wonder: Has the Python
community really been that bad at promoting the strengths of Python for
web development? Or, does the nirvana experienced by switching from a
language like PHP to Python just make us so at peace with the world that
we forget the hordes of developers still stuck with C-style syntax?
Either way, it got me thinking about a few of the reasons why I
decided to switch from PHP to Python; and why I not only see Python as
an excellent PHP replacement, but am surprised it is such a "best-kept
secret" for web development.

A lot of the information below is out of date. Please see the new
framework shootout page for the latest
benchmarks.

This post is the continuation of a series. Please read Round 1 first if you are just
now joining.

In Round 1, PHP was
looking like quite the tortoise of the group. However, if you're familiar with
some of the core differences between Python & PHP, you'll know that
Python has been "cheating" slightly.

Let me explain: By default, Python compiles each script into bytecode on
its first execution, allowing this bottleneck to be skipped on
subsequent runs. PHP, however does not perform this type of optimization
by default (in the 5.x line at least), so the PHP interpreter must
re-compile each file every time it is run. As you can imagine, this can
give PHP (without an accelerator) a huge disadvantage when compared to
languages such as Python.

With this in mind, I have decided to take Round 2 to focus solely
PHP. This will hopefully provide a clear picture of the benefits of
PHP bytecode caching (at least when it comes to page-views — the memory
benefits are a whole other story), and give you an idea of PHP's
performance with the help of an accelerator.