Postmortem of a drupalist leaving Drupal after 12yrs(berk.es)
berk.es
Postmortem of a drupalist leaving Drupal after 12yrs
http://berk.es/2012/10/01/farewell-drupal/
1 comments
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.
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.
Agree with you 100% up until Yii. (Yii::app() ALL THE THINGS!!!)
While it might be better than other frameworks, Yii is still a framework with all the failings. They get you to 80% REALLY fast and then you lose all those gains and then some trying to make the framework do that last 20% that you need. Usually you find yourself working for the framework instead of it working for you all the while thinking, "I could do this by hand faster."
While it might be better than other frameworks, Yii is still a framework with all the failings. They get you to 80% REALLY fast and then you lose all those gains and then some trying to make the framework do that last 20% that you need. Usually you find yourself working for the framework instead of it working for you all the while thinking, "I could do this by hand faster."
At the risk of also making a lot of enemies, I agree with you :)
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)).