Re Ruby on Rails - personally tried enough frameworks to want to wait a long time before committing real effort to it. Have a rule these days not to take frameworks seriously until someone is able to describe how it "sucks". At that point the sort of insight required to build real apps with it starts popping out. ROR is still on the hype curve right now.
It's great that it's become a focal point for many developers, something lacking for any equivalent Perl, PHP or Python framework. That guarantees a longish future and no doubt plenty of supporting libraries, both important for betting your development project on it.
But The make-or-break for me is the "edge cases" (the moment you step beyond CRUD), plus how things start to look when the feature list grows.
Specifically, a couple of issues I have from doing nothing more than trawling ROR documentation (which should probably be directed at a mailing list but David H scares me;), so here goes...
I've seen the approach of mapping actions directly to methods before in a PHP framework called ISMO (http://ismo.morrdusk.net/). From trying one project in anger with it - started off nicely but breaks down when you start needing to implement things like a authentication with permissions global behaviour (read Intercepting Filter) which needs to be bubble through to individual actions. Also things like an Application Controller, such as for a form with multiple parts, required blood. Perhaps Ruby can prevent the same happening with Rails in a way that PHP can't but need to see that before I believe.
Otherwise Ruby on Rails lacks ease of deployment right now. As I see it only "ASP" type technologies can deliver that, number 1 now being PHP. And ease of deployment is not just a feature for newbies. It opens up options like "just in time" code generation and caching which, in turn, create new possibilities for optimization and scaling smoothly. Along those lines, another rule I have these days is if it does l10n at runtime, move swiftly on.
Sick as it may seem, I'd recommend exploring Python as an active generator for PHP (i.e. you never touch / extend the PHP yourself); Python working as the design / modeling tool. In general PHP "works best" when it violates all rules of sane programming (other than security of course); as raw spagetti, perhaps because PHP was always meant to be just a template language.
The spagetti nature of PHP can be preserved while employing sane coding practices by using code generation. Right now the tools aren't there and no one's really explored the potential. The furthest walk I've seen in that direction is Scriptol - http://www.scriptol.com/ and some template engines written in PHP itself, such as WACT's http://wact.sourceforge.net/index.php/TemplateComponentArchitecture.
Stepping out of what platform makes most sense for a moment, PHP's installed base represents opportunity for anyone writing applications which target it and figure that's the bottom line. There's a joke, where I came from, about the answer you'll get if you ask a local farmer for directions: "Ooooh, you don't want to start from here!"
Sick as it may seem, I'd recommend exploring Python as an active generator for PHP
Yes Harry, that does seem sick. Sick! Horrible! The debugging horror! The deployment nightmare! That is the framework I really, really don't want to see... maybe if you keep it in the basement and never tell the neighbors it was ever born it would be okay. But do not reveal such a thing to the light of day, please!
Oh well, guess you don't want to see this http://eric_rollins.home.mindspring.com/pgen/ - Ruby again ;)
Apologies - got rant some more;
"Sick! Horrible! The debugging horror! The deployment nightmare! That is the framework I really, really don't want to see..."
Perhaps as a general framework, yes but for more specific application, where the design stage involves a narrower range of choices, it can work well.
There's a perfect example I forgot - Worksheet Server: http://www.jedox.com/. Design / development is done with Excel and the generated PHP code is not meant to be touched directly - it behaves something like a "component" on the web server. Further changes are made in Excel, overwriting the previous set of generated PHP code. So PHP acts as something like the "byte code" of a Worksheet Server "runtime". Did a review of it a while back http://www.sitepoint.com/article/php-apps-excel-worksheet-server.
And a potential candidate would be tools like JAlbum (http://jalbum.net/) which normally spit out HTML. Could easily be used to spit out PHP and add all those features some people seem to appreciate on their galleries, such as hit counts and comments.
Otherwise the devil is in the details - I don't see debugging horrors and deployment nightmares as givens - depends what you're doing and how you do it. Sure anything that involves generating code will itself require significant development overhead but
As one simple example of Python aiding PHP development, using Ned Bachelors COG, you might have something like:<?php /* [[[ import cog from myapputils import getdsn dsn = getdsn() cog.outl("$db = DB::connect(%s);" %dsn) ]]] */ # While developing use this (will be replaced by COG) $db = DB::connect("pgsql://devuser:password@localhost/myapp"); //[[[end]]] # Continue with PHP script... ?>
The PHP script is still executable while hacking / debugging is in progress. Deployment could be a Python script that runs COG over the source then copies it to the producive environment, replacing previous versions.
I think it's reasonable when using static publishing to produce PHP. I'm not against all PHP generation. But I think it's important to keep the generation dumb; set some variables, include some other PHP files (which are custom written), and that's about it. It's the modeling in Python and generating PHP that would scare me.
I've been shopping web frameworks for 3.5 years now. Really just window shopping - I've had project ideas but not the inclination to pursue them in my limited time. Now that I've finished school and only work full-time this has changed a bit, and I've gotten more serious about a project. I still don't know if it would have gotten off the ground except for Rails.
I've developed with MS technologies for about 7 years and the last couple has been mostly web apps with ASP.NET/C#. For a long time, I've been deciding which Java frameworks I would use for my independent work...I've played with all the struts, spring, webwork, tapestry as well as a couple ORMs (thought I really liked Hibernate)and had pieced together what my "stack" would be. I really like the toolsets and active community there. For a long time, I've also been in love with Python but have never really gotten past "Whetting your Appetite". CherryPy really peaked my interest at one point and I even found well-priced hosting that supported it but I never went anywhere with it. I remember playing with Zope (at least, Zope DB) a little bit but didn't get far. Cannot say why now (it was quite a long time ago) and unfortunately I'm out of the market for the time being.
Maybe I am just a sucker for hype but Rails got me moving. I found a hosting provider to support me (and for a bargain rate, great service so far). Once I was sure I could actually deploy my application I started building it. This is after doing nothing but idly looking at various frameworks, reading various websites, following several communities over a period of years with only a few concepts for potential projects in the back of my mind. Rails HOOKED me. I had barely learned anything about Ruby before learning about Rails (what little I had learnedI liked less than Python, and as it didn't have a web framework of note I didn't pursue it further). I think Rails has taught me somethings about Ruby that I now appreciate more, but I still have a long way to go and ultimately don't know how I will feel about Ruby as a language.
Please understand, the rails tutorials and scaffolding have done nearly as much harm as they have good for Rails (and that is saying a lot). Rails != scaffold.
Yes, Rails views look like ASP/JSP/PHP spaghetti code. They are different, and you can find out why if you read more of David's holy writ but even better if you experience it for yourself. The framework guides you by convention to do things properly. Coming from standard ASP & ASP.NET, I never fully grokked MVC (I understand it, but I haven't lived it). I was often paralyzed by questions of "where does this type logic go". Rails seems to be telling me, and telling me in ways that I don't feel anxious or guilty about, and telling me quickly.
Really what attracted me to Rails though is not the hype or the scaffold or the 10 minute demo, although that certainly helps when I feel I'm making really rapid progress. What attracted me is the philosophy. Don't repeat yourself. Use convention instead of configuration. After using ActiveRecord going back and doing Hibernate (even with everything its tools can generate for me) really makes me sick. After using ActiveController and ActiveView, the idea of the struts or springs XML config approach makes me sick. Of course, ASP.NET makes me sick just by being what it is and by the generally accepted practices associated with it (same with PHP).
Truly, I don't have the Python experience to speak to it in ways I can speak to Java and MS technologies. But Rails sold me in minutes, and I've been shopping a long time. If the Python community can develop something as cohesive and/or market it as well, then it can win. Python I think is unquestionably a better general-purpose language than Ruby still, just based on its library and tool support as well as it its distribution and mind share. But you might not have that much time.# JeremyH