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 rails automatic includes for css and js.
Not happy with error messages, can be very hard to decipher what is going on at least in the beginning. Got easier as time went by BUT sometimes you'd get an error related to a view or form helper, but it would say something like "no route for YZ" which would seem to indicate the problem was in the route not the view.
Some IDEs have issues with ROR ERB files, i.e. they would not highlight appropriately or consistently.
Had a nightmare trying to namespace controllers - putting controllers into a subfolder responded very differently.
Sometimes it is just too much magic going on.
The differences between environments - js/css includes would work fine on local environment but not on hosting environment.
It is an opinionated framework - and sometimes I don't like those opinions
Saw weird errors in partial files that would fail when included, but if the code was just put into a single file there was no issue.
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.
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.
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.
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.