Convince Me Why I Should Ditch PHP for RoR

What is it about PHP that makes you want to abandon it?

Things you can do in RoR you can't do in PHP: - Search through its documentation to find it's badly or incorrectly documented - Use crappy gems such as Devise which give you hours and hours of fun Googling how to customize it - Wait for 30 seconds for your development server to start

Have used Rails for 2 years, PHP for 5 years and Django for 3 years. My advise: go for Django. Awesome documentation, a fast booting development server and Python libraries are documented really well. All batteries included and it beats RoR performance easily.

I don't see any good reasons to switch either. Ruby might be an objectively better language, but the cost of switching is high if oyu know PHP through and through and use a MVC coding style.

RoR wont yield any benefit over a good PHP framework, and isn't a very good reason to switch.

Good reasons to switch:

- namespace implementation is bunk

- first class functions are second class

- the stdlib

- the insistence of the PHP devs on doing things in an orthogonal fashion to what the community wants

- only to relent years later with a half-assed implementation of a feature that's standard in modern languages (like finally)

If you do have these problems, and you find a language that suits you, let me know. I've been struggling with the limitations of PHP for years, and I haven't found anything better. PHP's ubiquity means that there's almost certainly a library or extension out there for whatever you need.

You'll probably earn more money.

You should not. Don't believe the hype. What you shóuld do however is experiment Experiment with as many languages as you can, It will make you a better programmer.

At the end of the day, these things are tools really. Focus on your customers, product, feature-set, etc. If you find that implementing feature x is going to be really difficult/impossible in PHP, look at other tools that measure up to the job. Else, stick to PHP. That is what you know and that is what you will be most productive in.

I'm regularly getting a headache when using PHP again. But it is the language I started with. Maybe you should use RoR to broaden your horizon.

I'll bite since there are a lot of cop out answers. First, why is there only room for one tool in your toolbox? Learn them both. And then learn something else. When you become proficient in multiple languages and frameworks you'll invariably find things you like in each of them (as well as things you don't). All of this adds up to experience and taste—both of which are essential to writing good software.

My apologies for the length, but I started writing something for a blog post that I never published and thought it may be of use. There is no reason to be scared of RoR, but it can be frustrating. I'm just starting to feel more at ease with RoR in the past few months. I really like it and would encourage you to learn it. If nothing else RoR developers make more money.

Long story short if you are patient with RoR I think is a great asset to have in your programming toolbelt. But be prepared to hit the wall when you try to do something that is very easy to do in PHP but at least tricky with RoR. I had a lot of problems with routing, subfolders, the asset pipeline, gem dependencies. Running RoR on a windows machine is kind of a nightmare.

Here are the details - this is kind of long;

I really like the organization that is enforced with RoR, although to some degree you can get some of that with a PHP MVC based framework.

I have a love hate relationship with it depending on what I am trying to do. I really like RoR features like dynamic find methods for db queries, but there are are moments when I hit the wall with the limitations in RoR that I want to ditch it to go back to PHP. Debugging statements especially in the view with helpers can be hard to figure out. PHP is nice when a single line of code fails the line where the error occurred is easy figure out. This is not always the case with RoR.

My biggest advice when learning RoR? Skip everything as it relates to coffeescript and the asset pipeline, just include your css/js as standard html tags in your views. There may be a big advantage to coffeescript/asset pipeline for some people, but the learning curve is steep, and it is utterly ridiculous for an app to fail due to compiling js/css and the asset pipeline. And this happened a lot early on. This is the thing I hate the most of RoR. My experience was that coffeescript and asset pipeline while running in production did not provide enough of a benefit to offset the time wasted to resolve the errors.

The failures I've had with the asset pipeline has been maddening. My first error on a deployed app in production was a css file that was not 'compiled'. The magic at times can be great until it isn't.

The PHP documentation is so clear and easy to understand, while RoR documentation has a tendency to be oblique and lacks examples. I'm on the same page as hekker mentioning the faults I have with documentation.

One of the best thing about RoR is the ability to leverage gems in your own code base, it really accelerates things when you want to add new features quickly. The drawback is that most of those gems do a lot of things behind the scenes stuff and again you might hit the wall.

These are some notes I made when I started sketching out a future blog post for my experience with Rails. This is mostly negative stuff. However even with all these negative bullet points I would definitely do it again and will use it more often going forward;

Documentation is subpar compared to PHP - php has so many well illustrated examples right in the documentation, RoR doesn't always cover that.

Even looking for the find method attached to ActiveRecord or ActiveModel is confusing - a find method with no record fails miserable, i.e. record = Record.find(value that does not exist in the db) -> FAIL

deployment is a pain in the ass, and its more expensive to deploy using rails, compared to PHP.

With php you just send the files up via FTP - Rails doesn't work that way difference in the gemfile comparing Linux to Windows: your css/js files need to be 'compiled' using RoR

I needed to add 2 additional gems to get my stuff to work on linux environment, execjs and therubyracer. These do not work on windows, at least without some serious work involved that is beyond my knowledge. I had a devil of a time getting rails and mysql to work on windows. I already had apache and mysql for PHP development and I did not want to install a bitnami RoR package.

The Windows Ruby interpreter crashes frequently, even just on tripping on r...

It'll make you cool.

It's not an either/or, but having some Rails experience will open up a lot of good opportunities to you. The kind of people you want to be working for are likely to be looking for Rails developers. There are of course lots of good PHP jobs out there, but you've got to wade through a lot of real stinkers to find them.

As someone who recently switched from PHP + CodeIgniter to Rails, all I can say is try developing something in Rails, you won't look back :)

Don't switch. Instead try of building something in Rails, like do attempt the tutorial at railstutorial.org.

Then, if you like it. Switch. if you don't, atleast you would learn trick or two which could help you in PHP dev as well.

Learn your OOP, algorithms, and your programming. Then decide, learn Ruby first then decide. Most of these answers are one liners and you shouldn't base your decision on that. Most frustration and trouble people get with PHP/Ruby/RoR is that they haven't learned the fundamentals and "it's crap!" because you can't figure something out because you don't have the fundamentals of it down. If you are particular to a framework you're always going to turn a blind eye to some feature that you don't agree with. That is going to be true for anything you get your hands on.

With that being said and I being a PHP developer and have been learning Ruby/RoR for a few months(obsessively). I like the elegance of a lot of the solutions and tricks. And the general mindset of the community. Any book, tutorial, or screencast I pickup always mentions best practices and how to make your code clean, lean, refactor and extendable. This is done to a point that I feel safe in assuming that is the overall mindset.

It's not an easy decision, but you shouldn't have to make it. Don't think of it as a "ditch". You're keeping your knowledge of programming. That should be emphasized, you're applying this knowledge to a new area, hopefully learning more, which can in turn be applied to PHP helping you better your craft.

Both PHP and Ruby are turing-complete languages, so, by definition, there aren't any things that you can do in RoR, but can't do in PHP or even COBOL for that matter.