Why not Rails … yet?
So straight off the bat, why did I decide on PHP as the server-side technology to use for my little project?
Well, first of all, I knew more about it than any other scripting language — meaning I knew enough of the language itself and its structure to be reasonably confident in turning out good, object-oriented code from the get-go; I knew enough about its pitfalls for the learning curve to be reasonably shallow; and I knew how to get it deployed quickly and easily.
Since then, I’ve read a great deal about Ruby and Rails, and I now nurse the idea that at some point I can migrate the server-side of the app to Rails. My experience writing a whole lot of fairly in-depth Javascript spoiled me for writing PHP (it became really frustrating not to have things like first-class functions, object and array literals, array comprehensions and the like when switching from the client to the server-side code), and I really yearned for the power and beauty of the Ruby language. And Rails just seems like the most forward-looking approach to coding for the web that’s out there at the moment. The Zend Framework makes a lot of stuff easier for me, but it has the slightly faux-enterprise feel that a lot of PHP projects have (big long horrible class names etc.) and, at the moment, no convincing architecture for models or ORM (I know, I know).
So why not Rails … yet?
Well, there’s been a fair amount written about this already, but I’m afraid I fall into the camp (ghetto?) that fears the deployment and maintenance issues that Rails presents at the moment. With PHP, when I want to deploy, I just upload the code and there we go. If I screw something up, I just fix it, upload the code and there we go. Yep, I’m on a shared server. And I really don’t want to be responsible for administrating my own (virtual) server — there are big gaps in my knowledge, as a self-taught programmer, which I’d really prefer that, for now, someone else deal with. The idea that when I start a Rails app it’s running until I stop it or (shiver) the sysadmin has to, because I’ve done something stupid which has resulted in runaway resource consumption, gives me the fear. PHP’s shared-nothing, request-to-request architecture is like a lovely comfy blanket in comparison.
If we could have a mod_ruby and a Rails that worked with the simplicity of PHP right now, I’d switch, right now. Until then, or until I become a lot more confident in my sysadmin-fu, I’m sticking with PHP — reluctantly.
Filed under: PHP, Rails, Ruby | 2 Comments
Tags: PHP, Rails, Ruby, zend framework
Search
-
You are currently browsing the Pausebuttonedit weblog archives.
Oh totally – the shared hosting dilemma eats away at me. I am very interested in Rails and I’m using it to do an art history database at work right now – but only because I have my own server and I can set up an apache proxy to mongrel fairly easily.
I am about to start a personal project with some friends right now and I really want to use Rails, because it’s fun and trendy and I’ve enjoyed working on it – but I don’t want to shell out the big bucks for hosting when I can attach it to the end of my existing dreamhost account. Even the private server version of dreamhost which allows a limited Mongrel experience is just too expensive to justify, since my hosting is just for little art projects, the label, etc.
I wrote Project Blood Team 2.0 in PHP with the CakePHP framework, which is a lot like Rails. At the time it was easier for me to deal with things in PHP, but now I’ve gotten the feel of Ruby so it would probably annoy me now.
And then again, I really hanker for what’s possible in Ruby, and Rails. Like isn’t it ridiculous that it’s not yet possible to properly implement the Active Record pattern in PHP? I read that PHP 5.3 will fix this, by properly supporting late static binding, but in the meantime it just adds to the general Clunk of PHP. And every time I have to reach for the manual to remember which way around the needle and haystack are in array_key_exists() a little piece of me dies …