Of recent, I’ve been getting involved in a side project with two burgeoning, smart entrepreneurs. The idea we’re working on is really exciting (but secret!). We’re now getting passed some of the initial brainstorming and trying to get some prototyping done.
As we move into actual development, there have been some conversations over the technology stack we should use. Specifically, I was asked to make a comparison between PHP with MySQL and Ruby on Rails with a NoSQL option. The perception being that Rails and NoSQL was better, more scalable and certainly cooler than using PHP with MySQL.
Being I’m supposed to be the lead in this area, and seeing it as an opportunity to share knowledge, I did a bit of research to come up with decent backing for my thoughts. I realize this has been discussed many times before, by smarter people than I, but the end result of my response seemed worth sharing with a wider audience. So, here it is with some minor modifications from the original…
Concerns on scaling… just wait for it
These are somewhat valid, but most software engineers would likely say don’t scale until you definitely need to. It will be obvious before it becomes an emergency/Twitter fail whale state. At the same time, you still need to be lined up for scaling before the very moment it becomes crtitical. DHH recommends not building web apps on Access “databases” in order to be at least somewhat prepared to scale. 
All of Ruby on Rails, PHP (using a Web framework similar to Rails), MySQL and NoSQL data stores have options for adding scalability to them. It really comes down to whether or not that foresight was even remotely in consideration at the start of the project. If you’re reading this article, then you likely have that notion in hand. So I wouldn’t be concerned about preventing your systems from scaling when/should the need arise.
I’m fairly certain that Ruby vs. PHP is of negligible difference in performance as far as scaling concerns. Adding Rails on top of Ruby and some framework on top of PHP might make a greater difference, but I still couldn’t find much that was decisive regarding that kind of comparison. On the data side, even if you begin with MySQL as a relational database, it’s very doable to convert that to a NoSQL solution in order to gain added performance. Twitter didn’t abandon MySQL until it reached 50 million tweets a day! That’s nothing to say of its reading/surfing/non-tweeting traffic that was also putting demands on its systems.
This was a good thread on stackoverflow regarding some Ruby vs. PHP scaling:
http://stackoverflow.com/questions/2742580/scalability-of-ruby-on-rails-versus-php
Quoteable line: ”But keep in mind, that the need for scalability is something most of us wish they had, but really don’t.”
Ruby vs. PHP… FIGHT!
That kind of heading is often considered trolling for a flame war on just about every web development forum in existence. There will always be religious wars between people who prefer one language over another. I really try not to get steeped in those. However, I’ve been using PHP quite regularly for over 10 years at this point, and have only done a few things in Ruby over the past few years. So, in general I just know the ins and outs of PHP more than Ruby. In my book, neither one is really vastly superior to the other. I personally tend to lean towards PHP just because it’s more familiar to me. I know I can dig in faster and deeper rather than reminding myself of all the Ruby syntax to do the same thing (even if it is prettier). Do note, Rails does not come into the picture at this level. Additionally, code in any language can be written well and readable or downright crappy. That’s up to the people creating the application.
There are plenty of large, high-availability applications as examples of either language. Twitter, I think, still runs on Ruby. WordPress.com and Facebook use PHP.
Web frameworks… Can we fight now?
This is where Rails comes in. But there are also dozens of frameworks for PHP that to provide very similar functionality as Rails. Frameworks offer common web application functionality/structure instead of having to create it yourself. In the case of Rails, it allows the ability to use a very common development pattern known as the Model-View-Controller pattern (MVC). MVC gives you the ability to separate concerns (data, front-end/design, business logic) so that you’re not changing the file with all your business logic in it just to update a CSS font, etc. That’s a good and rather vital thing. However, since tons of frameworks offer this ability, there still isn’t a clear winner in this category. It still ultimately comes down to developer preference. No fighting necessary.
I’ve actually most recently been working in a newer framework that brings in an added layer to MVC (called HMVC for Hierarchical MVC). That’s called Kohana and it’s for PHP. I see HMVC offering even more ability to scale specific parts of applications, and so far everything I’ve done with Kohana has just made sense to me. I’ve been rather happy with it. It’s lightweight, but still powerful. It does what you want it do without so much black magic that you can also move it out of your way when you need more customization. But that’s just one lowly web developer’s opinion.
Here’s an article on being able to scale nicely with HMVC using Kohana:
http://techportal.ibuildings.com/2010/02/22/scaling-web-applications-with-hmvc/
You can do many, many other things to help scale PHP and Kohana. (Side note: that’s probably one of the most ridiculously thorough answers I’ve seen on Stack Overflow.)
Don’t use your platform to sell your app… it’s not as cool as you think
One other thing is I prefer to not have particular technology be a selling point for any web application. Sure, it can be something for über geeks to muse about when a web app reaches some level of ubiquity. Beyond that, users do not and should not care one bit about what language or framework or database a web app uses. As long as it solves their problem or pain, that’s all they need to know.
A final thought is that over-advertising the specifics about a web app’s platform can sometimes just invite hackers to take advantage of known exploits for the particular technologies involved. That’s perhaps one of the most important reasons to keep platform discussions internal to an organization. Safety and security first!
Conclusion
I could probably cover a few more points, but I’m trying to keep this from being a full day’s reading. Basically, I still believe there is no convincing technical reason to go one route or the other. Both languages with a suitable framework can very handily accomplish all of what most even modestly successful web applications aim to achieve, let alone a brand new site. If you run into any concerns about performance along the way, I assure you that will very much be a fantastic problem to both have and solve.
All that said, my personal inclination would be to go the route of PHP with a good framework (Kohana fits that bill) and MySQL. It’s more of a “leveraging existing knowledge” thing than it is a “better than the other” thing. But I’m always up for discussing more in-depth reasons to pursue other options.
So, do you agree with my assessment? Or does this not sit with you for some reason? Either way, let me know what you think!
