

Postmortem of a drupalist leaving Drupal after 12yrs - cies
http://berk.es/2012/10/01/farewell-drupal/

======
jacquesm
At the risk of making a lot of enemies: Drupal sucks in many ways (as you
rightfully assert), but so does rails and most other frameworks. Frameworks
are usually designed by people with an itch to scratch, not by people with a
lot of training in how to set up something like a framework in a solid and
consistent way.

So right now you'll feel that the grass is greener on the other side, in
another 5 years or so you'll know the limitations of rails and you'll realize
that the new boss is just the same as the old boss.

The way we do web development in general sucks. We stitch together a jumble of
technologies (some scripting language or compile language for the backend,
javascript, html, css, SQL and whatever else you want to throw into the mix)
in order to produce a user experience that tries to hide all that under a
friendly front.

The limitations of this non-consistent development environment are all too
visible in the end results and result in a ton of ways to shoot yourself in
the foot performance wise or in ways that result in security problems.

The whole concept of 'a framework' needs to be re-visited, it's ugly. But for
now it gets the job done.

Good luck on your switch to rails!

(another former drupal fan, now using Yii after a consult by another HN
member, a bit closer to rails, much cleaner than drupal, still PHP (that's not
a blessing, but also not as much of a curse as it is made out to be)).

~~~
berkes
As always, obviously the answer is "use the right tools for the job at hand".

But there is a little more to it.

The more assumptions your framework makes, the less free your are to implement
what you have in mind. Meaning: you'll not be able to deliver exactly what
your clients want.

I prefer an environment with a good balance between assumptions and turnkey-
solutions. So that I don't have to write all that silly HTTP, database and
template handling from scratch, everytime, but at the same time makes no
assumptions about the implementation.

Rails (or Django, or YII, or any more such frameworks) have been architectured
around that notion.

The notion to keep out of your way when it comes to how things should look
(sidenote: I remember the Drupal-days where you had sidebar-right and sidebar-
left hardcoded into the core!), or how they should behave. Drupal does not
offer that freedom. Not even with 20+ modules is it possible to have exactly
that login/invitation-workflow that many clients demand. Simply because it
makes a lot of assumptions about the login-workflow.

This is why I (and I have been eating grass on both sides of the fence for
over 5 years) know, for sure, that for me and my projects, Rails is the best
choice.

Had I not invested so much in learning Ruby, Rails and its community, I would
have gone for Python/Django, as that community and filosophy fits even better
with my workflow.

But, Rails is great. Not as a fanboy, but as someone who has developed Rails,
Symfony, Cake, fromscratch, Wordpress, and lots, lots of Drupal-systems over
the year.

There really are lots of good cases where Drupal is the best choice,
certainly. But these are not my (favorite) cases.

