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).
• Partial support for template language parsing in your asset files (e.g. Mako or Jinja2 template tags in your JavaScript or CSS files).
• A unified Python 2/3 codebase.

Feel free to check it out on GitHub or browse the documentation, and share here or open a GitHub issue if you have any comments or suggestions.

It's been several months since I've had a chance to update The Great Web Framework Shootout, but this weekend I decided that it was time to dig in and freshen things up a bit.

Not only have most of the frameworks seen new releases since the last revision, but I finally decided to move all of the tests over to Amazon's "release" version of the Ubuntu LTS AMI.

Below is a quick summary of what's new in this revision:

• All tests were performed on the updated Ubuntu LTS AMI (ami-fbbf7892 ubuntu-images-us/ubuntu-lucid-10.04-amd64-server-20110719.manifest.xml)
• The updated AMI was configured with Python 2.6.5, PHP 5.3.2, Ruby 1.9.2p290, Apache 2.2.14 (default config), mod_wsgi 2.8 (embedded mode), and mod_passenger 3.0.9
• Rails 2.x and 3.0 were dropped from the "full stack(ish)" tests in favor of Rails 3.1.
• CakePHP 1.2 was dropped from the PHP tests in favor of 1.3, but Symfony and Yii were added as they seem to have considerable market share.
• CakePHP's caching engine was incorrectly configured during the last round of tests, and this has been corrected.

Circle me on Google+ to keep track of further updates, and feel free to contact me there with any questions or comments.

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.

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.

There are already ...

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.

There are many PHP accelerators available, but I have chosen APC for use here (mostly due to its inclusion in the upcoming PHP 6 core).