Drupal vs. Ruby on Rails

Hello all,

Maybe the $subj is a little bit weird (i.e. apples vs oranges) but it is
a situation i am facing at the moment: We are developing a small web
site which will be mostly a CMS (more or less) and my colleagues is
arguing for drupal, and i am for RoR.

Maybe i can formulate the question in a different way: when to use a CMS
(not necessarily drupal but e.g. Radiant CMS) and when to use Ruby on
Rails?

I think if you really want just the usual functionality of a CMS, i.e.
like WordPress for blogging, then you can do well with
drupal/radiantCMS/WordPress/whatever. That means you install it and use
it.

But if you want a little bit of this, a little bit of that later (and i
think that’s exactly our case, maybe it won’t be even a little but
rather a bigger set of features) then i think in the long term it is
better to go for Ruby on Rails. What do you think? Where is the border?
We are both Java coders by trade so coding is not a problem.

Also when we go for drupal, if i will have to change something, i will
have to hack !!PHP!! PHP! Ouch. To cite DHH: ‘PHP is the devil’. Well,
who i am to argue?!

Please try to figure out some good arguments against drupal
It is not enough (for me absolutely, but not for my colleague) that it
is PHP - i need something better.

Thx,
Peter

Peter S. wrote:

Hello all,

Maybe the $subj is a little bit weird (i.e. apples vs oranges) but it is
a situation i am facing at the moment: We are developing a small web
site which will be mostly a CMS (more or less) and my colleagues is
arguing for drupal, and i am for RoR.

Maybe i can formulate the question in a different way: when to use a CMS
(not necessarily drupal but e.g. Radiant CMS) and when to use Ruby on
Rails?

I think if you really want just the usual functionality of a CMS, i.e.
like WordPress for blogging, then you can do well with
drupal/radiantCMS/WordPress/whatever. That means you install it and use
it.

But if you want a little bit of this, a little bit of that later (and i
think that’s exactly our case, maybe it won’t be even a little but
rather a bigger set of features) then i think in the long term it is
better to go for Ruby on Rails. What do you think? Where is the border?
We are both Java coders by trade so coding is not a problem.

Also when we go for drupal, if i will have to change something, i will
have to hack !!PHP!! PHP! Ouch. To cite DHH: ‘PHP is the devil’. Well,
who i am to argue?!

Please try to figure out some good arguments against drupal
It is not enough (for me absolutely, but not for my colleague) that it
is PHP - i need something better.

Thx,
Peter

Hi Peter,

I think you have to have a look at http://www.railfrog.com ( a next
generation CMS with Rails)
What they are trying to do seems really great for me. I know that a
Drupal core developer is also part of the Railfrog core developper.
Railfrog is current at 0.51, I hope the 0.6 will be soon for the public.

Regards,
Brice

I think you have to have a look at http://www.railfrog.com ( a next
generation CMS with Rails)
What they are trying to do seems really great for me. I know that a
Drupal core developer is also part of the Railfrog core developper.
Railfrog is current at 0.51, I hope the 0.6 will be soon for the public.

Thx for the reply! I will take a look at Railfrog for sure.
However, the second facet of my question is still open: Where to draw
the line between CMS and a DIY RoR app (a the function of the aditional
features, i.e. if i want the functionality of a CMS +1-2 small things,
then an existing CMS, but if i want 10 big fetures which would be
cumbersome to do with an existing one, i would go for RoR. The question
is this number - what is the critical mass of the additional features
where you already say ‘ok i won’t hack RailFrog but rather roll my own
code’…?

Cheers
Peter

Drupal comes with a ton of features. How many of those are you going
to use? You have to determine how long it will take you to recreate
those features in RoR. Then you have to determine what the next 10
features are. If they are pie in the sky type features that you may
not ever get around to then you may want to go with Drupal.

I would negotiate a compromise here… I would say, put up drupal, but
any new features that we want must be written in RoR. That way both
parties get what they want. Your partner gets a site up fast with
Drupal and you can use RoR to build new functionality. At some point
in time RadiantCMS or Railfrog can replace Drupal and you will be in a
pure RoR environment.

The problem is i never did something like this - i.e. to integrae new
Rails functionality into an existing workframe - how is this done in
errata: to integrate into a framework

On 5/12/06, Peter S. [email protected] wrote:

If you could post some pointers on this (not WS or other generic
technique as i did such stuff in Java already, but addressing the
concrete ‘how could drupal-RoR or Railfrog-RoR work together’ problem),
i would be very thankful. In fact, i am already because of this cool
idea

I have one question. Is this for you, internally, or for a client,
externally? I have never seen a “common” CMS work well without
headaches for a client. They will always eventually want something
against the CMS’s abilities. Then you are stuck developing the custom
framework you should have developed in the first place and then
migrating data to it (or at best hacking a framework that was never
meant to do what you’re needing it to do and you don’t know intimately
enough to quickly do). You could reimplement the core of drupal in a
decent amount of time in RoR.

Carl F. wrote:

in time RadiantCMS or Railfrog can replace Drupal and you will be in a
pure RoR environment.
I see. This sounds very good and most probably acceptable for both
parties.
The problem is i never did something like this - i.e. to integrae new
Rails functionality into an existing workframe - how is this done in
practice? Web services?

If you could post some pointers on this (not WS or other generic
technique as i did such stuff in Java already, but addressing the
concrete ‘how could drupal-RoR or Railfrog-RoR work together’ problem),
i would be very thankful. In fact, i am already because of this cool
idea

Cheers,
Peter

I have one question. Is this for you, internally, or for a client,
externally? I have never seen a “common” CMS work well without
headaches for a client. They will always eventually want something
against the CMS’s abilities. Then you are stuck developing the custom
framework you should have developed in the first place and then
migrating data to it (or at best hacking a framework that was never
meant to do what you’re needing it to do and you don’t know intimately
enough to quickly do). You could reimplement the core of drupal in a
decent amount of time in RoR.
Yep, exactly my thoughts. One small question to the last sentence: what
do you think how much is ‘decent amount of time’, if we consider really
just the very core of drupal (or similar -and build up the other
features later)

Cheers,
Peter

On Fri, 2006-05-12 at 15:52 +0200, Peter S. wrote:

Also when we go for drupal, if i will have to change something, i will
have to hack !!PHP!! PHP! Ouch. To cite DHH: ‘PHP is the devil’. Well,
who i am to argue?!

Please try to figure out some good arguments against drupal
It is not enough (for me absolutely, but not for my colleague) that it
is PHP - i need something better.

I’m not sure why you are fighting PHP.

Drupal is a fairly extensive CMS system whereas RadiantCMS and any other
CMS type system for rails isn’t going to be nearly as complete or as
polished.

Thus, to get a site up and running, you should be able to do that in far
less time using Drupal and PHP. The only issue where rails would make
more sense would be where you had to do custom programming to add
features that aren’t present in Drupal.

Craig

On 5/12/06, Peter S. [email protected] wrote:

Yep, exactly my thoughts. One small question to the last sentence: what
do you think how much is ‘decent amount of time’, if we consider really
just the very core of drupal (or similar -and build up the other
features later)

Honestly, I tried to install Drupal once and hacked at it for a day
and got virtually no where. So I have some…predetermined
angst…which is unfair. After wasting a lot of time searching for
the One CMS to Rule them All, have lost much faith in the
cookie-cutter-ness of CMS solutions. They are great for the core of a
community website, and I think good for open-source communities. But
I feel they are not good for the corporation (or software development
shops). (Personal opinion only, flamewars abound, your mileage may
vary.)

Looking at the feature overview (Features | Drupal.org) of Drupal
doesn’t look to be incredibly impressive honestly. Much of it is
built into (or highly trivial) with a bit of RoR experience.

User Management / Authentication = 4-8 hours
Content Management / Polls / Static&Dynamic = 8-16 hours
Blogging / Syndication / etc = 8 -16 hours (less if you use other code
or a plugin)

Honestly all other “features” there are basically built in or so
trivial it’s not even worth mentioning… Logging… Please… A
Log model can easily accomplish that in RoR (1 hour)… And it could
be implemented as a plugin so you can call it from any other Model /
View / Controller…

I would say it would take 1 - 2 weeks to get a better system that will
be more easily extensible and do what you want it to do, and only what
you want it to do. CMS’s are too bloated, get feature creep from the
community, and are convoluted… But that’s just my humble opinion.
They have their uses, but I’ve given up on them for “external” or
“client-based” development. (Conversely, if you are familiar with one
and have successfully implemented a few sites, then go for it… But
you need to study them fairly well and understand how they do things
to apply them to a project.)

We have also created a “core” application (in three flavors, mostly
authentication schemes–pluggable) that we use as a basis for all our
Rails apps… So we basically have a CMS core without the bloat and
feature-creep to start from. I recommend all software shops do
something similar that works for them. You made it, you know it.

I would also like to mention the fact that our core flagship clients
are J2EE clients. And we are mostly disgruntled Java programmers.
Just kidding, Java has its uses, but I can see many places that RoR is
a great fit. PHP has its place too… But you have to apply things
where they fit, and I think RoR and Agile Web D. is a better
fit for dynamically changing things like client websites. When was
the last time you heard from a client “perfect! We’ll never need
anything beyond this…” And if you do hear that, just expect the
call next week…

Java can stay on the back-end… But RoR should belong on the
front-end. (I don’t know enough about Ruby itself yet to contribute
much to the Ruby on the back-end discussion.) I personally, would be
thrilled to never write another JSP page.

I’m not sure why you are fighting PHP.
Are you kidding? This is a RoR forum
Well, because i like Ruby and Rails much-much-much more than PHP. I like
to code in Ruby/Rails very much, whereas PHP coding is more like a
punishment for me
Np offense, this is just my opinion. If PHP is your stuff, cool, but i
will stick with Ruby/RoR until something better appears (candidates are
not yet on the radar, at least not on mine)…
Drupal is a fairly extensive CMS system whereas RadiantCMS and any other
CMS type system for rails isn’t going to be nearly as complete or as
polished.
I believe you. But in my case it is the similar analogy as of Microsoft
Word
and Writely. Writely offers everything i will ever need to write MY
documents,
so although it is true MS Word has more feats, i won’t use it just
because of that, but i will take different points into consideration.
This point in my case is Ruby/RoR.
Thus, to get a site up and running, you should be able to do that in far
less time using Drupal and PHP. The only issue where rails would make
more sense would be where you had to do custom programming to add
features that aren’t present in Drupal.
Well, exactly this is my situation: We will need some (lot?) of features
in the future sure which are not offered by a CMS, and then it is
easier (for me) to hack RoR than PHP.

Cheers,
Peter

Curtis wrote:

angst…which is unfair. After wasting a lot of time searching for

We have also created a “core” application (in three flavors, mostly
fit for dynamically changing things like client websites. When was
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails

If the site you are talking about is mainly used like a CMS go with
typo3, why the heck Drupal ???

There is absolut no problem to add new extensions/functionality to it in
no way.

The best of all this CMS is the BE, with all the rightsmanagement for
editors, etc

If you need all that you will have a hard time to rebuild that with RoR,
also it isnt good practice to reinvent the wheel.

If yo would decide to port type (or Drupal) into something based on RoR,
at least it should be better…otherwise it makes no sense…and typo3
for example has 7 years in front, how much will it take you to port it
to RoR, not taking in count I am talking here about
developingtime…menyears would be 7 multiplicated by number of
coreteammembers and helpers…so probably there are 20, 30 or more years
of work in ??

I dont know…

If you not need nor 10 of the “thousands” of features typo3´s BE is
coming with, then do it in RoR, probably taking one of those packages
who started allready as a RoR CMS as a base

But the way you argue and reply to mails here, I have the impression you
allready have taken your decicion, so this is kind of “virtual talk”,
isnt it ??

In any way its much to abstract to be responded correctly from anyone
here as everything depends…noone knows better than yourself

Good luck

Matthi

PS: i would be really happy to see something like typo3 made “in” RoR
one day for sure, but I doubt we will see such thing soon…

Curtis wrote:

einventing the wheel… All 18 of them… But again, YMMV…

If you know you’re going to have requirements beyond what the existing
packages will offer, why implement one knowing you’re going to have to
rearchitect it? Why not save time initially and just create the whole
thing custom. (Preferably drawing on a core of something else, but if
you don’t have that, then you will have to write it at one point…
If you do it intelligently you can utilize it to get the next project
off the ground even more quickly.)

---

You probably allways will have, and good luck its that way, but thats it
where consultancies make money from

Short answer, as this is still the RoR list and I am the last who wants
to change that

If you need a couple fo new features BUT also all the features a package
as TYPO3/Drupal (I dont know it though) has, then you just cant reinvent
that wheel, cause it would take you years, meanwhile extending the
former in any direction ( I repaet it here at least for typo3: IN ANY
DIRECTION) is a matter of hours/days/weeks…depending on what you need,
but still you would have also developmenttime in RoR for the “new”
features, and even if this would be 30 times faster than just those 10s,
you wont earn the years you would need to rebuild what “others” build
over years in front, that is why you wont do that.

And…imagine you come up at 2015 with your own TYPO3/Drupal etc…you
client is leaving happily the door as a new one enters.

It turns out, he needs similar thing to the one before, but you would
have to add stuff to fit the new ones needs…dont tell me you would
start off again just cause you know his requirements are beyond of the
former clients one…

Cheers

Matthi

On 5/12/06, matthibcn [email protected] wrote:

If you need all that you will have a hard time to rebuild that with RoR,
also it isnt good practice to reinvent the wheel.

True. My only point was that I have been part of and seen too many
times where instead of reinventing a wheel that fits, people will find
any five tires and bolt them with square lugnuts to a semi… Well,
if you want the trailer to move, you need more than five wheels. And
you usually don’t find out about the trailer until two months after
the project for the truck is finished.

And I personally don’t like being in the position of then
reinventing the wheel… All 18 of them… But again, YMMV…

If you know you’re going to have requirements beyond what the existing
packages will offer, why implement one knowing you’re going to have to
rearchitect it? Why not save time initially and just create the whole
thing custom. (Preferably drawing on a core of something else, but if
you don’t have that, then you will have to write it at one point…
If you do it intelligently you can utilize it to get the next project
off the ground even more quickly.)

Peter S. wrote:

Anyway, thanks for all the replies so far, it was really good to hear
how others are thinking about this problem and know that i am not alone
with my thoughts… I am still undecided but at least much better
equipped for a discussion with my drupal colleague. Thx again!

Yeah, and by the way point him to typo3.org

We all know, the dude who invented the first wheel was an idiot. The one
who invented the other 3 was a real genius…

So maybe one comes up one day with the missing 3, hopefully in RoR, I
wouldn´t stop anyone from trying

Good luck with your project

Matthi

Curtis wrote:

the project for the truck is finished.
off the ground even more quickly.)
Well, i can absolutely agree with you Curtis (maybe because he told me
the things i wanted to hear ;-).

During my career so far i have reinvented the wheel a lot of times,
especially in my ultra-young-and-enthusiastic days (which is a bad
practice in general, of course) but i believe this is a question of
granularity: if you are doing something small (e.g. quicksort) it is
almost sure you are reinventing the wheel. If you move towards something
bigger, we can not always talk about pure reinventing, but rather
reimplementing with some customization. And if you are onto something
really big (like a CMS) it is almost certain that you are not going to
do exactly the same thing somebody already did, but at least a very
customized one, or maybe even a very different stuff at some places.
That’s why imho it we can not always throw something into the
‘reinventing the wheel’ bag, especially if it is something bigger. And i
believe this is exactly my case

Anyway, thanks for all the replies so far, it was really good to hear
how others are thinking about this problem and know that i am not alone
with my thoughts… I am still undecided but at least much better
equipped for a discussion with my drupal colleague. Thx again!

Cheers,
Peter

On 5/12/06, Peter S. [email protected] wrote:

Anyway, thanks for all the replies so far, it was really good to hear
how others are thinking about this problem and know that i am not alone
with my thoughts… I am still undecided but at least much better
equipped for a discussion with my drupal colleague. Thx again!

:: snipsnipsnippperoonie ::

I agree, in summary, with the core of the discussion. And I probably
have some current angst because it feels like nearly everything I’ve
been doing outside of Java lately has been helping to correct
badly-written PHP code. (Disclaimer: I am by no way saying that PHP
programmers, by definition, write bad code…it just seems to me that
the majority of bad code I see nowdays is PHP scriptkiddies code.)

A real developer can take any language and make it sing. It’s easier
to make some languages sing than others… RoR is like being given a
nice fat opera singer to work with; PHP is more like being given Clay
Aiken… But you can make either work.

In my experience, every time I’ve dug into a prepackaged CMS, it’s a
nightmare to get some things to work the way you want. Integration
sucks…but it’s a goal we all have. And I’ve hacked phpBB into more
“CMS” apps than I want to admit… Typo3 is a pretty well-written
package. But also, those people are working on these apps for years;
but it’s usually a labor of love, not money; so of those years,
usually weeks are only spent writing. If you have 40 hours a week,
you can put a decent CMS together in a short amount of time; even in
PHP…

I’m not advocating reinventing every wheel. Or that anything is the
One Silver Bullet. There is no Holy Grail of programming. There
never has been, there never will be…things are just too complex.
But part of being a developer is knowing the shortest, best path to
solve a problem. And RoR goes a long way in that for a large core
of things. Personally, I never want to see PHP again, unless I’m
hacking it apart and rebuilding it in RoR.

I maintain that anything PHP can do, RoR can do better and faster.
This includes a CMS. And I’ve seen some cool stuff coming out of the
RoR CMS projects. I can’t wait to see them after a stable run…a
little more maturity. But still…they will be a general CMS and not
always the solution. I await the day that Slashdot switches to RoR.
:: grins evilly :: That should stir up some people…

I wish people would stop calling Drupal a Content Management System,
its a canned community (or “Community Management System”) that happens
to give you the ability to edit and categorize some content. It is
very weak in the workflow department, nor does it support content
outside of the Web paradigm very well (to this day, there isn’t even a
decent File/Document Management component).

In fact, 90% of the Web-based CMSs are Community Management Systems –
and they’re not much better. Each piece of the puzzle has rough edges
or is tightly-coupled to a set usage: it really is a shame that so
much of the community development process is wasted on very
un-DRY-like activities, like writing an Amazon booklist widget or a
“shoutbox”… 27 times, in 27 different PHP CMSs.

On the other end of the spectrum, you’ve got the Java “scientists”,
writing Portlet and Framework specifications with barely a functional
forum component to show for. In fact, there are more frameworks than
features meaning you’re pretty guaranteed writing everything from
scratch or following some obtuse specification down a dark tunnel, for
reason unknown to you, except that “its the way its supposed to be
done”.

I think RoR is the sweet spot here. Writing a site with the usual
suspects – simple categorization/taxonomy engine, authentication
engine, dynamic menus, and basic CRUD content entry – is pretty much
done with a handful of RoR community components and built-in RoR
functionality.
Create it. Display it. Secure it.
Thats really the tri fecta of every interactive Web site nowadays and
almost out-of-the-box, you can accomplish all of this with RoR.

To me, RoR comes much closer to the UNIX philosophy of “many small
programs doing one thing very well” and the community seems to be
getting that – you don’t see as much conflicting agendas and alot of
overlap between components. And even if there is, I’d wager that the
RoR/OO train of thought puts interop and loose coupling at a premium
meaning that things tend to play nicely together.

Unless you’re building a canned community, I’d choose RoR.

matthibcn wrote:

So then have a decent look of typo3, and you are proofed wrong.
Actually he said “most” so if one is really good, then “most” still
qualifies.
None of them will have only the chance to compete with something as
typo3 for the next couple of years.

Period.
I wouldn’t be so sure. Open Source projects have a history of moving at
different speeds. As I mentioned in a previous post, the time scale in
OSS compared to real life is flawed. It’s like “dog years”. Perhaps we
should call them OSS years or something. A project that’s been alive
for 10 years hasn’t been in steady development by a large number of
people for the same timeframe. :: shrug :: There is nothing stopping
someone from commercially creating an RoR framework and releasing it to
a degree as OSS. Unlikely maybe, but putting absolutes on it is silly.

How many authentication/login systems do we have, how much
globalisationProjects are on its way…etc pp
This repeated stuff isnt the fault of php nor of RoR, its based on the
fact, that pl think they are faster, better if they reinvent the
wheel cause their needs are going beyond of what they get right now…
This proves my point. A component doesn’t work for what I needs, so I
write one that does. It doesn’t matter if there is more than one way of
doing something. It’s doing the exacty same thing twice that’s
silly. There is some duplication of that sort likely, but that’s human
frailty…none of us are perfect.

Actually, he specifically stated that they would have to add a fairly
significant portion of functionality not provided by Drupal at a future
point. Thus my entire suggestion for rolling their own instead of
utilizing a PHP framework. It was the basis for my statements about
trying this in the past and having nothing but nightmares. I now know a
few PHP frameworks fairly well (well enough to develop modules for
them). It is a nightmare, particularly PHPNuke. I couldn’t even get
Drupal working on a development laptop. I probably missed something
simple, but the second time I followed the installation instructions
precisely (I rarely have to RTFM–with Drupal I did and still didn’t get
it working). :: shrug :: There is too much “hack something to avoid
reinventing the wheel” talk in software development for me…and it
annoys me. If there isn’t a wheel that fits…write one. You’re not
reinventing it, just redesigning and reimplementing something you won’t
have to hack later.

GravyFace wrote:

I wish people would stop calling Drupal a Content Management System,
its a canned community (or “Community Management System”) that happens
to give you the ability to edit and categorize some content. It is
very weak in the workflow department, nor does it support content
outside of the Web paradigm very well (to this day, there isn’t even a
decent File/Document Management component).

So then have a decent look of typo3, and you are proofed wrong.

In fact, 90% of the Web-based CMSs are Community Management Systems –
and they’re not much better. Each piece of the puzzle has rough edges
or is tightly-coupled to a set usage: it really is a shame that so
much of the community development process is wasted on very
un-DRY-like activities, like writing an Amazon booklist widget or a
“shoutbox”… 27 times, in 27 different PHP CMSs.

Yeah, that is what most people are missing in typo3, the community
stuff.

And the same un-DRY activities pop up here in the RailsCommunity,
otherwise you canT
explain the various activities and starting CMS packages all over the
web based on RoR, out of
my head I could call at least 3 or 4 yet.

None of them will have only the chance to compete with something as
typo3 for the next couple of years.

Period.

Anything prooving me wrong is very welcome, cause I would also prefer
rails over php, but one has to be pragmatic, not ?

How many authentication/login systems do we have, how much
globalisationProjects are on its way…etc pp
This repeated stuff isnt the fault of php nor of RoR, its based on the
fact, that pl think they are faster, better if they reinvent the
wheel cause their needs are going beyond of what they get right now…

engine, dynamic menus, and basic CRUD content entry – is pretty much
RoR/OO train of thought puts interop and loose coupling at a premium
meaning that things tend to play nicely together.

Unless you’re building a canned community, I’d choose RoR.

Unless you dont have to deal with various editors once the site is
running, or even various levels
of editors, decent rightsmanagement for each step in the publishing
process unless you dont need
clever multilanguagesitesetup and contentmanagement, unless you dont
need…go with Rails, and make
sure to post us an URL for the project once you have finished it

So, just to avoid any confusion: I dont argue against RoR at any point,
I dont argue for php either, I would
prefer RoR over any phpsolution, BUT “he” was looking for a CMS TODAY,
"he " wasnt asking what happens, if
one farday he would need to use a CMS but also extend it probably…this
is all that vague…I think this whole discussioon
was quite useless as the starter left us assuming , assuming,
assuming…instaed of sketching out his needs in detail and
asking based on that, but I wonder if he has sketched his needs for
himself yet…

Anyway, I am out of this discussion at this point…

There must be a difference between pragmatic and fanatic at some point,
and for sure one could (re)build phpbb or oscommerce in RoR,
but then, who will, how long will it take…and better, where is this
TODAY ??

Regards

Matthi