Sean H. wrote:
Ok, but what about RoR vs. some of the PHP frameworks that are coming
up in its wake?
I work in a largely J2EE shop. We have a few very monolithic java
apps and I can’t stand JSP. Now granted, some of it is because of
shortcuts programmers have taken (because of time restraints mainly).
But, even if you are very careful and refactor, there are decisions that
can cause lots of issues (caching and persisted classes and all sorts of
crap). We are currently rearchitecting a lot of this stuff to get rid
of the boxes that we are in with “nifty” technologies that promised to
fix stuff. I may be stretching the issue a bit, but it’s still
difficult sometimes to do even some normally easy stuff. :: shrug ::
I, myself, am pretty good with PHP and my boss is as well. We can
easily come up with working applications for various web clients.
However, we have never successfully been able to deploy a current
framework. We’ve tried at least ten of them (two of them “commercial”
ones). Not only that, but customers generally don’t like huge,
convoluted administration systems. Just consider walking a client
through security with PostNuke. :: grin ::
While PHP has its place, I’m currently investigating writing a few
things in RoR as proof of concept apps. I hope we can move from PHP to
RoR.
I also don’t put much stock in all the One True CMS stuff. I expect I’m
not the only one that has wasted weeks on it. Not that they don’t have
their uses, but I’ve been in condition upon condition where a client
will state “This is magnificient! But we were in a meeting demoing the
softare and the CEO said it needs to be able to do X, Y, and Z”. No
problem, right? Well, a couple of times the framework nearly
prevented X and Z, and we had to write around a lot of stuff to
implement it. If we had rolled our own we would have known instantly
what we could do. I’m with DHH on this and I’ve only been working with
RoR for a very short time.
We have tried in a full development, client setting the Nuke variations,
Drupal, Mambo, and too many others to remember. None of them worked
without major hacks. And the “framework” which includes login /
security usually is either so damn complex that it’s worthless or so
rudimentary it’s useless. As I’ve heard many times, with a “CMS”
(particularly the PHP ones) you usually get 80% or 120% of what you
need. And the extra 10-20% of what you need takes twice as long as
rolling your own entire framework would have (and that’s in PHP, imagine
the time savings with RoR).
Instead, our solution was to have about three core frameworks with PHP
ranging from simple to complex and mostly having to do with the security
systems. Then we can start off with core code that we know (stored in a
code repository, of course). We can select the one that makes the most
sense for the project and build upon it. I figure we’ll do a similar
thing if we move to RoR. It really would take a minimal amount of time
to do in RoR. The PHP versions have taken a while to perfect…but it
works better than any framework out there for us.
Remeber, clients don’t want to hear, “well we’ll see what we can do”.
They hear “they don’t know what they and their software are doing”.
That loses you business. With RoR, you don’t have to hack a framework
to make it work right. You can take a week and have nearly the exact
stuff they want to demo it. :: shrug :: It just works… That doesn’t
mean it’s always easy… But we didn’t become programmers for an easy
job. 
Bottom Line: My clients have been extremely impressed with “Hey, do
you have a couple of minutes to pull up the staging site and walk
through those changes we had discussed this morning?” They are used to
hearing “Sure, we’ll have it tomorrow, or the next day… We’ll give
you a call then.”
