7 reasons I switched back to PHP after 2 years on Rails

In my view, your love of SQL and your focus on your existing tables were the big barriers here. Writing a procedural system in an object-oriented framework is a poor match. Treating the database as the main focus, rather than an implementation detail is, from the Rails perspective, the wrong approach. And Rails is very opinionated software; it does its thing well, but if you want it to do something else, it's not a good match.

And I'd note that integration is only a problem if you're integrating components via the database. In effect, you've duplicated the schema everywhere, making it impossible to change. Integrate via APIs rather than your database, and integration isn't nearly as big a deal.

Doing something from scratch, in a one man team, after circling around the issues for two years, is a little different to working in a team with a new problem and needing a clean framework with (omg) Opinionated methodologies.

I wrote a lot of php code as well, and after 3 years, soon 4 years with ruby, I am 100% sure that ruby is a LOT better than php in EVERY aspect (i dont consider rails to be a part OF ruby), and I think your conclusion is WRONG in any way that PHP sucked because you "became a better programmer".

I will tell you the truth:
PHP as a language sucks.

I agree on one point... the domain language of php, the world wide web, should be solved BY ruby. All what is possible in php, should be possible with ruby as well. I hope matz decides to adopt this, because I am 100% sure that people will use ruby instead of php IF they can use ruby just the way they can use php (which means, no stupid mod_ruby errors for example)

I actually agree on one more point - hype is never good, what really matters is IF you work BETTER with these tools or not.

People, trust me - PHP is ugly, and will ALWAYS stay ugly. I have long ago jumped away from PHP. Only because rails doesnt fit your needs, doesnt mean Ruby as a language does not fit you!

I think I can agree that this should make the rails developers THINK about these issue and attempt to SOLVE (or easen) them, too. Because it seems like a rather legit reason and the arguments within it can be well voiced to improve rails...

It is also true that ruby *can* grow very complex, but it really matters on the programmer. Whenever possible, one should strive to pick the shortest, cleanest, easiest-on-the-brain solution instead of a "magical solution" (unless it is a very clean and clear human readable and nice to maintain DSL of course ;> )

Show us an example of:
1) What you tried to accomplish.
2) How you tried to implement it in rails.
3) The rails code that "didn't work."
4) The "beautiful" PHP code you created instead.

> William Pietri:
> In my view, your love of SQL and your focus on
> your existing tables were the big barriers here.

Bingo. Objects, their responsibilities and relationships first, database second (in Rails).

I loved the part about the database as an "implementation detail." That sings to me.

Taking an extreme stance to breaking down the problem domain yields the best results for me. Who keeps track of my appointments? My first answer was "me." Then I stood up and paced around the house for a bit. Upon sitting back down I wrote...

./script/generate model AppointmentBook

Break it down. Down. Down.

Know this: straight out the gate, even with little MySQL/SQL knowledge I know college grads that know and love Ruby on Rails that can code entire websites and admins in manner of weeks not to mention localization and advanced features like cacheing and advanced logging systems.

One important thing to learn from these guys and gals out there: they write tests alongside their code and think in that manner. All their code and program design fit together and they develop better code and projects because of that.

You are stating pure opinion without discussion anything substantial.

Dont fault the author for liking SQL and its relative if not portable efficiency. The fact is it works and its way better than some pretend ORM like rails (ooh look johnny a WHERE clause builder!) which says well you cant do any joins that are meaningful to your application unless you pull it all back and iterate the old fashion way.

SQL allows you to let the database do the work. But as far as alot of RAILS or other ORM users are concerned, pulling back rows from individual tables and "joining" them in memory in a very inefficient way is somehow beneficial. Because they dont know how to leverage existing technology.

And thats what I liked about this article. Because it is true. Rails and ruby may cover for you for a while, but in the end you will have to do heavy lifting.

So your little login and your "oh I coded a website" and I dont know SQL and how databases work. Is a bunch of bullshit.

ORM and especially active record is fools gold for people who will never learn what it takes to actually get the job done.

But it is a good learning tool for people in a hurry.
Learning how to fail.

If you read that here, I think you need to adjust your browser.

Which is why we are outsourcing software development.
Because they dont know SQUAT.

It would be interesting to see, if you pick rails for a future new project if things would be different, and, two years down the road after many enhancements and changes, which codebase is more manageable, and should you have to recruit others for help, which they find easier to work with.

But some other things to consider:
Webprogramming does not stop with PHP or Ruby. There are so many alternatives. You have choosen what you knew. But what would happen if you had tried something else? Here are some ideas:
1) OpenACS http://openacs.org/
2) Seaside http://www.seaside.st/
3) Some lisp based stuff AllegroServe, Hutchentoot etc
4) Some scheme based stuff
5) Erlang stuff
6) Objective-C
7) Java
8) Perl
9) Python
and so on .....

I've tried so long:
php stuff (serious)
lisp stuff (very serious but with very less success)
openacs (just had a look)
rails (has saved me from spending another few months on the lisp stuff)

I for my part are quite happy about rails. Maybe it's it's model that suits me that good...

Regards
Friedrich

I'm familiar with the situation here. The deal was this: Derek was not a programmer; he was a musician. He learned some PHP and cobbled together the old CDBaby site by himself. It was good.

Then, he heard about Rails, and became infatuated with it. He proceeded to attempt a rolling rewrite of CDBaby's frontend and backend both (the backend is large, because of inter-label and digital distribution stuff) in Rails.

At this time, Derek had no experience with the following things:

* any language other than PHP
* systems integration and interoperability
* Rails
* object-orientation
* the MVC pattern
* managing a development team

Project fails. All right. As he has learned in #2, legacy compatibility trumps everything. Also, ship early and often.

As you can see in Derek's post about MySQL encodings, he's not always the clearest thinker. Even above he says that REST means POST-only destruction, which misses the point entirely.

His team was fine (mostly just Jeremy, until another developer was hired in the last months). Rails was fine. But there were a lot of things wrong with the project plan ("rewrite everything, eventually") and with the project leader, who was convinced he had found a silver bullet.

No framework saves you from your own inexperience.

Out.

To Richard Hertz and Cornelius, and others asking for more concrete examples: maybe some day.

I finished the rewrite a month ago, and it's taken me a month to find the two hours it took to write this post, which I did for the benefit of an invisible someone someday.

To show in examples what I love about my new PHP code would take hours and hours more, and I might do it some day, but I've got years' worth of things that are more important for me to do, first. Maybe some day I'll just put it all up on a public svn server, but I'm not ready for that yet.

Also, when considering it, I thought my specific code that made me happy probably wouldn't make you happy. I just designed a little system for my tastes, and that's the point.

Bob, Rails is not just ActiveRecord. Our heavy lifting is done on a service layer. Rest assured, it blasts SQL away. Bob, how many millions of hits a day does your site get?

Saying that it is better to use bare PHP and custom made templating system (isnt PHP a "clever template" after all?) is better than starting with Ruby and ERB is pure nonsence to me. Ruby is much better language (pure OOP in Ruby vs hacked in OOP in PHP) but has some downsides in deployment. Integration is not an issue when using REST and Webservices, but i guess that would be too hard to implement in PHP ;-)

Look, if something was really good you all wouldn't have to work so hard to defend it. It just might be possible to develop software using something else.

Wow, you and your posse made a site with links that lets you search. And you did that in 4 months with 5 people? Respect. I just can't imagine doing that so fast any other way.

A problem that both have is that their Unicode-handling sucks big time (which is why I would have argued in favor of Django/Python, they're at least getting there)

Maintenance-wise you'll almost always be much better off with Django, Tapestry or Rails. Especially since your maintenance-phase will almost always be about 4-10 times as long as your development-phase.

And as both Ruby and PHP are Turing-complete there's nothing that can't be done with each of them (except implementing 64-bit integer handling in less than 80 lines of code in PHP), including implementing each other.

cheers

Even trying to relate that with rails and use it as a point of difference between rails and php, is totally lame. Once again, rails didn't fail you. You failed yourself.

However you can do better.

I agree to your point about php and R&R...

R&R 's too simple, that's exactly what kills it, it will never make it to the top.

php - your house wife, it WORKs for you, however ugly
R&R - your beautiful one-night-stand, however you can have 20 of them each year

I can say it right here: any language that requires too much brain power, absolutely and definitely WILL NOT make it to the top.

WHY? No managers likes thinking too much, unless the efficiency really is important.

My ability of being able to "Get on with it" while you are still tweaking your R&R code, is PRICELESS - why?? because I grabbed 2/3 of your customer before you laugh your site!!

To be WINNING in this world you had to take risks, if you haven't been investing 180~190% of the all you've got[startup $$], and talk to 1000+ of your potential customers, your project would most likely to fail -
NOT because your code or service is BAD, but because you spend just a bit of time TWEAKING on computers when you should be communicating with someone else...

Remember: business is always business, you are selling a service,
if you are only an employee, who take proud of the clever code and admiring comments from colleagues, then you WILL always be an employee.

Take risks, work hard, COMMUNICATE, and HAVE FUN.
You will find your millions or billions[with luck+ lawyer/acc friend].

Did you or your rails "expert" do any of these things?

We have use rails to develop an enterprise software system which is now in production with a number of clients, so I am speaking from first-hand experience here.

The Ruby interpreter is currently slow and will hopefully improve over time. But there is no reason why a site that can't be written in 2 years can be written by YOU in a month using PHP. By your own argument, "when I took a real emotionless non-prejudiced look at it, I realized the language didn’t matter that much."

So what the hell was the problem?

2 years and you can't build craigslist for CD's using rails. Jesus.

Just my experiences there,

G

I'm coming from a Java perspective here, rather than a PHP perspective, but I will not use database interface engines like JDO which turn 1 clear concise line of SQL (stuck into a prepared statement) into 10 messy method calls to do the same things, with a horde of behaviours that aren't what I want it to do. Spending months fighting and bypassing JDO's issues was a nightmare, and I will never do it again. Writing some DAOs with PreparedStatements took a tenth of the time, far less code, and is far more maintainable by someone who knows Java, but doesn't have JDO experience.

That said, things like Struts and Tiles - lightweight frameworks that make your work easier without limiting the power available to you - are good. Indeed Tomcat itself is a framework for writing a webserver that takes all the webserver grunt away leaving you to just write the logic.

What I don't understand is why you didn't drop the limiting framework - Rails - and just stick with Ruby. I don't know Ruby, but Rails must be built upon libraries for database use, etc, that you can access yourself, write your own SQL statements, do things the correct way, in a language you admit you like?

On the other hand, when you need to do something quickly, it is far better to do it using mechanisms you know and understand.

Anyway, to your... arguments?

1. "But when I took a real emotionless non-prejudiced look at it, I realized the language didn’t matter that much."
So you're saying that end the end you went back to the language you were most comfortable with, not that Rails couldn't handle your app, right?

2. The One Big Day switch doesn't work. We have tried it before, and you end up getting a flood of repeated questions and you end up confusing a lot of people. The best way to do this is to prioritize the intranet pieces and website pieces and switch sites an intranet apps one at a time. We have 30 intranet apps being used by a few hundred people... We held big meetings to say, "hey, this is going to change and this is what we imagine it will look like." A few months later, their pieces started changing and they were (mostly) prepared. But, doing it in pieces allowed us to re-evaluate how each project was being used and make improvements, where your One Big Day approach limits you to trying to build it to function as it did before as quickly as possible.

3. Yeah... there's a lot of crap in Rails. A lot of plugins and libraries that never get used, and there are several libs that are just too unstable for real use. It would help if they cleaned up the docs and API a bit. This is a problem :(

4. Small & fast... you mean Rails, right? It's easy enough to set up a mongrel cluster with Apache proxy balancing that your 2U LAMP server should've been able to handle most anything.

5. Rails lets you do exactly the same thing.

6. I think those who use the object associations directly in Rails are doomed to failure. You can't just do someobj.otherthings and expect it to be optimized in any way. You can do direct SQL in rails, but what I like to do is: someobj.otherthings.find(:all, :conditions => "otherkey='asdf'", :select => "the, fields, I, want"). I adjusted all of our queries to be limited to only getting what I want and it improved performance significantly... especially in cases where I'm sorting after-the-fact through hashes of arrays and whatnot.

7. I kindof see where you're going with this, and agree that any exposure to a new language is a growing experience.

What I'd like to see are specific examples of what you couldn't do with Rails or what exactly made it more difficult. Without specific examples, I have to say, your post just sounds like a PHP fanboy that gave Rails a try, did learn some interesting stuff, but went back to what he was already more comfortable with. I suppose there's nothing wrong with that in itself. The ridiculously misleading and idiotic summary on slashdot of your post:

"Two years later, through blood and sweat, the project was then canceled because of limitations of Rails. Rails just wasn't meant to do everything since it is very much "canned" project"

Now that I've actually read the article, it is obvious you didn't mean your post as flamebait, but you are lacking specific examples of how Rails didn't meet your needs.