It’s been a while since I saw a “non-religious” aproach to a language decision.
While showing your view, you kept a clear prespective of the scene.
Conviced us, readers, that you’ve explored it well and for that particular case, the best option is RoR.
Congrats for this beautiful post.

Thanks!

Ein super interessanten Vergleich von ZF und RoR gibt es auf Codedifferent, unbedingt auch die Kommentare lesen, sind vom Zend Framework Core Team und super ausführlich.
…

One thing I want to point out first: Plurality and competition in the field of scripting languages as well as web frameworks is the best thing that could happen to us! I love that we have the choice what suites best for us - or for the project we want to realize. And it’s great to see the communities growing on both sides.

I’ve got the chance to realize projects in ZF and RoR - so it cleared out that RoR fits best for me. But I only can encourage anybody to digg into both ways … and maybe even try some different frameworks, too.

Thanks for pointing on the capabilities of ContextSwitch - I did not stumble upon, yet.

So, let’s grow, inspire and invision both communities!

Wil has written a lovely response, but I wanted to respond to a couple of items in particular, item 7, MultiView, and item 6, TDD..

Regarding MultiViews, version 1.5.0 of ZF introduced a new action helper, ContextSwitch. This does basically what you’re describing — based on the request, it can decide what view to present to the user, and can perform a variety of actions, from setting the correct response headers to selecting an alternate layout. We offer, out of the box, the ability to return XML and JSON responses, but it’s extendible, allowing you, the developer, to decide what contexts you want available — and for which particular actions.

Regarding TDD, most contributors to ZF, myself included, use TDD to develop the framework itself. As such, there *are* mechanisms in place for testing your controllers. The problem is that it’s not easy. I’m attempting to address that, and am working up a prototype that will facilitate TDD with your applications — and make it simple. RoR *does* have excellent testing, and I want to foster that same spirit in ZF applications.

1) Ruby instead of PHP: It depends on your definition of ‘better’, but certainly Ruby has a more flexible, more dynamic object model with advanced features like incredible reflection capabilities and closure. I agree it is a gorgeous language- a language that CS professors can love. And certainly Rails would not be what it is- inarguably an elegant framework that solves many problems well- without taking advantage of many of its capabilities. But there is the performance tradeoff that is related to many of these capabilities. And I would venture to guess that many RoR developers don’t fully understand these advanced OOP capabilities to effectively use them (closure is considered an advanced topic in language design and use). And much of the elegance of Rails is obtained through syntactic sugar in Ruby, which I believe is a double-edged sword as it can obfuscate what is really happening in the language itself and its object model. This happens most prevalently in the configuration and DB migration files, IIRC. Rake also takes advantage of syntactic sugar. And PHP had very different design goals- it gained so much popularity because it was easy to use and didn’t require an formal training to write web applications. While the object model is relatively basic compared to that of Ruby, many PHP developers appreciate the fact that they can still write apps in purely procedural code. My point? Ruby is great at meeting its design goals, and I love using it. But PHP is also great at meeting its design goals, and I love the fact that we have so many useful sites as a result. Working with several languages has also left me with the distinct impression that the language typically has little effect on the final quality and capabilities of the product. Good PHP/Zend Framework developers can write a site that is just as interesting and advanced as Ruby/RoR developers.

2) Vision-Driven-Community: The Rails community is undoubtedly vision-driven, but that doesn’t mean that the ZF community isn’t (I know you aren’t saying this directly- I just wanted to make this clear.). We are not Rails. We don’t want to be Rails, although we certainly have adapted some of its good ideas to the ZF project. W feel we can solve some problems better with a different philosophy. Let me give you a few examples reflecting our vision. . .
We believe in building from the ground up to simplicity and providing useful extension points all along the way. We believe in convention AND configuration- it should be entirely left up to the developer in our opinion so we will continue to provide full support for both. We believe wholeheartedly in opinionated software (who wouldn’t?), but we do not believe in opinionated software frameworks. For example, we intend to support REST and SOAP equally because they are both out there in the wild. In fact, SOAP is common in the enterprise, which is one environment we aim to excel in. Many people have built frameworks on top of ZF, and I find that fascinating. In a sense, we are continually building a new framework on top of our existing framework as we build up to the the out-of-the-box functionality similar to what Rails offers now. But we’ll support any AJAX framework, any web service, any PHP ORM technology on the backend; we won’t define what a model is for every project (right now we don’t have any concrete definition of a model, and this is very much on purpose). All of these are extremely risky strategies in today’s web dev environment. We believe they are what’s right for ZF. To me, ZF therefore represents a very vision-driven project. Whether it’s as vision-driven as Rails is a matter of opinion IMO.

3) Scalability: There are several examples of large, high scalability sites written in ZF, too. I happen to have the privilege of knowing there are some *enormous* sites that are either in the works or considering ZF. I don’t see this as a point of differentiation in the projects.

4) REST: We also have REST client and server implementations in ZF. I don’t know how they compare to REST support in Rails as of 2.0; I’ve heard that REST is integrated quite well in RoR now.

5) Database-Migrations: We don’t have DB migrations in ZF yet. When we add them they will likely be built on the flexible Zend_Build tooling infrastructure, which is now in the proposal/prototype stage. We think they are important, and we have some opinions about what would be best for our users that differ somewhat from those of Rails. For example, it is unlikely we will build a schema abstraction for migrations since we belive the DDL differences in databases that back ZF applications are too great, plus it may be more obvious to our users to use the DDL that they are already familiar with for their database of choice. FYI, the proposal you link to is outdated and will likely have to be refactored or rewritten to work on top of Zend_Build.

6) Test-Driven-Development: Yeap, RoR is definitely a leader in facilitating TDD. We are currently building out our capabilities here with API’s to test controllers and other utilities, but we have certainly have a ways to go. BTW, all the code written on the Zend team for ZF is done with TDD, and I am a huge believer. I am also a huge believer in agile methodologies, and this may be a direction we go in for future project management; I haven’t figured out how to best implement it in a OS project yet.

7) MultiView: I believe this could be achieved easily in ZF using a combination of view helpers and client detection. In fact, we’ve talked about shipping a device database like dotMobi or WURFL with the ‘fat’ ZF distribution (stay tuned for what that means). This should help our users address different interfaces for different devices with different capabilities. We already have examples of controller actions handling asynchronous requests. I will forward this to Matthew, who is much more capable than I to fully address this issue.

Now for the points at which Rails doesn’t excel as much. I hope it is clear from what I’ve said above that I believe Rails does excel in areas where ZF does not, and I can’t necessarily say much about Rails with respect to the assertions you make. I can say something about ZF’s corresponding capabilities, however.

. . .if the application has to run on a Windows Server: I’ve never tried to run Ruby or Rails on a Windows server. I know that PHP runs well and that Zend distributes a well supported Windows stack called Zend Core. AFAIK, ZF runs perfectly well under Windows, and many of our users are running Windows/ZF in production seeminglywith no more problems than those running Linux.

. . .if you only need the actual date on a static webpage: First off, *every* component in ZF is use-at-will. Even the MVC components. You can easily deliver almost entirely static resources without incurring the overhead of the dispatch loop in ZF. This is the first point on which I strictly disagree with you. ZF is only big if you choose to use a lot of our components, and/or you choose to trade off some performance for maintainability of the app. This reflects our ‘unopinionated software framework’ philosophy.

. . .if you as a developer do not understand an English word: I have some ‘buzz metrics’ that I routinely monitor, and without a doubt Rails is more popular in the states. Our sweet spot seems to be Europe- especially Eastern Europe- and the far east. Of course, ZF documentation is pretty thorough, and we’ve been fortunate enough to have community members give back in the form of documentation translations. Our docs are more or less fully translated in to 6 language, and portions are translated in about 30 languages IIRC. Our international support is not unintentional. Here are a couple of examples: 1) We will avoid facilitating pluralization of models (more or less undefined at this point, as mentioned above) for database tables as English pluralization is irregular and it doesn’t help those who don’t understand English with readability at all. Also, to give you an idea of how much we think about our non-English-speaking users, before I joined some referred to ZF as ‘the Zend Framework’, including some content on our site. I explicitely requested that we standardize on ‘Zend Framework’ because keeping the article would make it very awkward to discuss it in a foriegn langauge. I’m not sure how international the contributing community is in the Rails project, but I can pretty safely say most of our users are non-English-speaking. We don’t have any non-English resources on our site beyond the translated manuals, however. I personally would like to see the entire site localized in several languages, but we can’t do everything we’d like to see done at once.

Finally, I want to make it clear that we don’t see ourselves racing against RoR in any way. The web development community has become *huge*- there is more than enough room for several agile-oriented frameworks. Even if you consider the PHP community alone, there is enough room for ZF, CakePHP, Symfony, CodeIgniter, and any number of other PHP frameworks. The fact is, we all have our strengths, and there will be projects better suited for RoR or Cake- or ZF, for that matter. This is why I really don’t believe that straight comparisons between frameworks without the context of a project’s requirements is very useful. If your project’s requirements can be satisfied with RoR and is unlikely to grow beyond it’s easily available capabilities, I’m likely to recommend it. It is built with simplicity and short ramp-up in mind, and it is a more mature project than ZF. If you’re talking about an enterprise app that must integrate with legacy applications or a complex app that will require many points of extension, you’ll find my recommendation will be different. At the risk of sounding *too* biased, it would probably be Zend Framework.