Lee Blue has started up a series of posts talking about his reasoning for moving back to PHP from Rails in his applications. In his first post of the series, he looks at application "shelf life" and the overall lifespan of the project and how that relates to things like maintainability and upgrade handling.

I plan to write a series of posts about how we develop, deploy, and support our affiliate software and digital downloads applications. And why, after 5 years of Ruby on Rails development we switched back to PHP. One of the reasons is what I refer to as the shelf life of a web application. Let’s talk about what happens to a web application if you just let it sit.

He talks about the "rotting on the vine" that one of his clients' Rails 1.0 application faced when the later versions of the Ruby on Rails framework. He talks about how these kinds of upgrades cost money (and time) and how, with the right selections for the deployment stack, some of the costs could be alleviated. He gives the example of a PHP-based deployment setup and how much of the related technology has been stable and (mostly) unchanging over the years, just with new features being added. He offers a few suggestions to avoid this "app rot" and things startups/freelancers can do to help prevent it in their clients' applications.

Davey Shafik, a long-time PHP developer and community member/speaker, recently had to learn Ruby on Rails for a project at work. He's shared some of the experience (from the perspective of a PHP developer) in a recent post on the Engine Yard blog.

I know PHP. I mean, I really know PHP. Not just the syntax, or the idioms and idiosyncrasies, but why. I can tell you why something works the way it does, under the hood; and I was probably around when the decision was made to do it that way. Thirteen years with any language is a long time. [...] Ultimately, it comes down to: Is it the right tool for the task? Because of this, ultimately when I come to write a web site, PHP is my tool of choice. Know thy tool well, and it shall treat you well. Then along came Engine Yard, and I was exposed to just a ton of fantastic engineers who happen to choose Ruby as their tool of choice.

His project was the site for the Distill conference Engine Yard is putting on in August. He lists a few "WTF" moments he came across when learning and creating the site with Ruby including issues with parentheses on metod calls, method naming rules, implicit returns and variations on control structures. He also talks about some of the other technologies used to power the site like OAuth and S3 for image uploads (via paperclip). He finishes out the post by wrapping up the experience and talking some about the benefits of getting outside your comfort zone and learning something wildly new (language or other technology) to give you perspective.

In his latest post Padraic Brady talks some about the recent security issues that happened with Ruby on Rails that allowed for remote code execution and how, if you use code blindly, you could be in for a similar fate.

Code execution vulnerabilities are, by definition, hideous monsters. The ability for external inputs to enter an execution context (i.e. injecting or manipulating code that is executed on the server) can be difficult to spot through the haze of convenience that such machinations are often designed to deliver. In Rail’s case, that convenience was to automatically cast data entries in XML or YAML inputs into Ruby types including, unfortunately, Symbols and Objects.

These types of “buried” code execution vulnerabilities are still easy to locate in PHP, at least, because you are still restricted to normal code execution pathways in the absence of Ruby’s dark magic, e.g. eval(), include(), require_once(), system() and, let’s not forget, unserialize().

He talks about how, if you're not careful with the code (third party libraries) that you use in your applications - or don't adhere to good security practices in your own - you could be vulnerable to a similar style of attack. After some investigation on his part, he discovered an issue related to this in the Symfony2 YAML parser (now fixed with a new release).

To summarise…

Pay attention to competing applications or frameworks – their problems may also be your problems. If you’re worried about arbitrary code execution vulnerabilities then audit your code. You can even, as a sanity check, use grep to find uses of functions like eval(), unserialize(), etc and analyse where their parameters’ might originate from.

In response to some criticism about his previous post with some framework benchmarks, Wojciech Sznapka has posted updated results using the latest versions of each framework.

In my previous post Modern framework comparison I presented performance tests, which compared Ruby On Rails, Django and Symfony2. After recieving a feedback in comments I decided to run this benchmark one more time on my own laptop (instead of on my hosting). The reason was simple: enviroment was outdated.

There were some overall performance increases were seen, but some statistics were higher - the "time per request" for all of them grew, some by quite a bit. He presents these benchmarks with a caveat, though:

You should never choose framework based on benchmarks. Those shows them from one point of view, but there are plenty of other aspects, such as support, community, maturity, number of ready to use components.

In this new post to his blog Jani Hartikainen wonders if "everything needs to be integrated into a framework".

There is occasionally people asking about things such as "Is there an integration for X in framework Y?" Then they are disappointed when it isn’t, acting as if it’s a really bad thing. But why do things need to be integrated to begin with?

He points out that other frameworks (ex. Ruby on Rails) have a lot of things integrated, but he doesn't agree that this should be the standard. He suggests that, by not having tools that are tightly coupled with the framework you're using, you open yourself up to a wider, possibly better range of external tools.

One could argue that integrated libraries give you a productivity boost. While it may be so, I think the main boost you get is the very first steps: It’s easier to get started, but after that the benefit fades. In the long run, it may even turn into a poor investment in general, as you could have learned a general purpose tool instead.

In this new post to his blog Wojciech Sznapka compares three different frameworks - Symfony2 (PHP), Django (Python) and Ruby on Rails (Ruby) - in their request handling performance, lines of code and average community on Github.

If you ask me, which one is the best - I can't point one, all of them are very good. But let's try to measure frameworks. For purpose of this article, I created three applications in Symfony2, Django and Ruby On Rails. All those apps do the same - show two tables, one shows top USA cities (by population), second shows US states with highest number of big cities (above 100k citizens). I don't want to measure frameworks by echoing "Hello world", because it's pointless.

Each of his applications use the same data set and use a default ORM with optimized queries, HTML rendered by an internal template engine and rounded floats. His performance requests (using Apache's ab) for this sample application show Symfony2 being able to handle the most requests/second followed by Ruby then Django. Symfony2 comes in at a larger file size than both the others combined, though. As far as the community is concerned, Ruby on Rails outpaces the others with about three times as many "watchers" on Github.

Be sure to read the comments for some opinions, both for and against his results.

In this recent post Laurie Voss has voiced his opinion about the PHP language - that it needs to die, but also asks what should replace it.

The reason I know PHP has to die is because I've seen this before. Roughly a decade ago, PHP killed Perl. [...] As a language for newcomers, and especially for web developers, it was already dying in 1999 and was mostly dead by sometime around 2005. [...] There was no reason you couldn't write a perfect web app in Perl, but in PHP you'd do it faster and easier, despite the flaws in PHP itself which were, even then, already obvious.

He talks about moving on from PHP, why almost requiring a framework to do anything these days is a bad thing and how, despite the flaws the language has, he feels "trapped in a language that's losing its suitability for the task." He suggests that one successor might be Ruby on Rails but also points out some of the flaws it has including performance, Active Record and possible issues with code generation. He notes, though, that this isn't quite the replacement he had in mind and that there's just not something there to fill that gap.

Be sure to read the comments for lots of great opinions from both sides of the PHP opinion fence.

On the Web Builder Zone there's a new article from Giorgio Sironi that compares the current states of PHP and Ruby on Rails when it comes to adoption and overall options they each provide.

It has been said ad nauseam that comparing PHP and Ruby on Rails is unfair as one is a programming language and the other is a full-stack framework. In spite of this, we can compare PHP frameworks (which have learned a lot from their first releases) and Ruby on Rails, again not by piling up a list of features, which would be also cluttered by different extensions and plugins. I'm talking about the different approaches taken by PHP and Ruby framework developers.

He talks about the options (or lack there of) that each side of the same web development coin provide and how "magic" and configuration come in to play when developers are making their selections for the most relevant technologies.

In this new post to his KillerPHP blog Stefan Mischook voices his opinion on why he thinks PHP is the "King of the Web" (and wonders what happened to Ruby on Rails).

In 2006 I created killerphp.com because I wanted to make it easy for web designers to learn PHP. I thought PHP was THE predominate web programming language and I felt every web designer should include PHP as one of their core coding skills [...] Then Ruby came along...for a short while.

He looks back at the time when Rails was "the best thing since sliced bread" and was taking the web world by storm. Other Ruby frameworks have come along and are taking the lead (like a merge of Merb and Rails). So, what does Stefan think the problem was with RoR's climb to fame and popularity? The crucial pieces that were missing (libraries, functionality, etc) and its poor resource handling that could lead to some big problems with certain kinds of applications.

There's lots of great comments from both PHP and RoR-ers alike, so be sure to gives those a look too!

Juozas Kaziukenas has reposted a video created by the RailsEmnvy.com folks (one of several, check out YouTube for more) that does a "Mac vs PC" Apple parody commercial of Ruby and PHP.

Gregg Pollack and Jason Seifer from RailsEnvy.com do some Ruby on Rails commercials in the same style of the Mac vs PC ads. Videos produced by Jason Hawkins of MakeFilmWork.com.

Other videos include Ruby on Rails vs .NET, Ruby on Rails vs Django and, of course, Ruby on Rails vs ColdFusion.