PHP5 Vs. CakePHP Vs. RubyOnRails?

OldJavaHack writes "If you could start a website (with MySQL for persistence) from scratch and you had a choice of PHP5, CakePHP, or RubyOnRails — which would you choose and why? Things to consider in your decision: 1. Maturity of solution; 2. Features; 3. Size of community of skilled users (to build a team); 4. Complexity/ease of use (for neophytes to master); 5. Greatest strength of your choice, and the greatest weaknesses of the other two. Here is a comparison of capabilities."

Rails

[Baddas]

I've worked in all three, repeatedly, and there's really no contest. Rails is so much easier to get concepts out, and has so many fewer bugs (in my experience), that it's silly to use PHP at this point, unless you have overriding reasons for choosing it aside from inherent qualities.

Doesn't it depend on what you intend to do?

[javakah]

There are different things that you can do with a website, so first of all it really depends on what you are intending. PHP5 will be great for building creating more traditional websites that are driven by HTML forms, and is probably the best thing to use for such purposes. Ruby on Rails seems to be meant for if you are planning to build AJAX apps. It's fairly easy, with a lower learning curve, but does have scalability issues. Another option that you might consider if you are looking for AJAX stuff would be GWT, the Google Web Toolkit. Larger learning curve, but very fast web apps. Really though, comparing PHP5 and RoR seems kind of like comparing apples and oranges. Just remember, figure out what you are trying to do first, then pick the language.

Re:Sure

[dedazo]

I should probably clarify my original post.

I've never used Ruby or RoR, but my impression of it seems to be one of great expectations and not a lot of delivery. I've read way too many blogs by people who built web sites with RoR only to have them crash and burn under load. Also, the language itself seems to place a lot of importance on clever syntactic sugar, which being an old fart I automatically dislike.

Now, "scale" does not mean the same thing to everyone. There's Digg and Wikipedia, and then there's the vertical business app that gets 200 hits per day. RoR might be a good choice for the latter, not so good for the former.

Also, although my experience with PHP is limited as well, it seems to me that it's a mature enough platform with a good runtime (that tends to be confusing at times) and a *massive* user base. The amount of readily available PHP code out there is amazing. It will take Ruby quite a few years to get to that point, I think. So maybe Ruby is not a good beginner's environment, application-wise. But that's just my perception of it. PHP is more to the point. On the other hand, RoR might be more mature and stable than CakePHP, just because it's been around longer.

The best tool for the job and all that, you know?

Oh... and BTW, first post =)

Focus..

[August Lilleaas]

May I remind you all of this:

http://www.flickr.com/photos/planetargon/1279842 54/

Yes, that's the creator of RoR talking about what he feels about other people not liking his framework. RoR is all about pretty code, if you don't like RoR, use something else.

So, that sorted that out. Now, troll!

Re:Sure

[crayz]

Can you describe some of your experiences scaling Rails? I'm currently serving up to 250,000 requests per-day with a handful of Rails apps, so I'm wondering where you hit the breaking point and had to switch to the crapfest that is PHP

There's no doubt that Ruby and Rails especially are much slower in execution time than comparable code written in PHP. That said, the PHP code would be 2-10x as verbose, take far longer to write, and be far less maintainable. With Rails you just throw more hardware at it and it will scale as far as you need to. If you're running up against real walls in Rails scaling, try Merb. If you're just a PHP n00b who wouldn't know decent OO-code if it punched you in the face, then by all means stick with the Personal Home Page language

Re:Doesn't it depend on what you intend to do?

[AaronBrethorst]

I disagree. Rails is fantastic for quickly rolling database-driven forms apps. It includes some nice helpers for quickly integrating asynchronous behavior (Ajax), but it's certainly not mandatory. PHP5 doesn't include an OR mapper, and nor should it; an OR mapper should be part of a separate framework or library (just as it is with Ruby and Ruby on Rails). I think that Rails actually has a fairly steep learning curve. It has *very* specific ways of handling most things, and trying to fight against these things will only come back to hurt you in the end. Additionally, since it requires you to function in an MVC mode, there might be an additional bit of learning present as you figure out how to properly separate your app into presentation, model and controller layers.

At the end of the day, it all comes down to need and experience. If you know how to use PHP, why not use it? If you have to integrate a new feature into an existing Rails app, then you'd better learn Rails in a hurry. Personally, I'll build Windows server-targeted web apps in ASP.NET because I know the tooling and the backend. If I'm hosting on Linux or UNIX, I'll write it in Rails because the language and frameworks are so much nicer to use than PHP.

Re:Sure

[dedazo]

Can you describe some of your experiences scaling Rails?

I work mostly with ASP.NET, really. Like I said in a later post, I have the impression of RoR being problematic for a lot of people, scale-wise.

There's no doubt that Ruby and Rails especially are much slower in execution time than comparable code written in PHP. That said, the PHP code would be 2-10x as verbose, take far longer to write, and be far less maintainable.

That is a tradeoff, of course, and it's really up to each person to decide the merits of a platform based not only on raw speed.

If you're just a PHP n00b who wouldn't know decent OO-code if it punched you in the face

No, not really. BTW, 250K hits per day is really not that impressive, especially with a "handful of apps". That's ~3 requests per second. I work with a single vertical application that handles roughly three times that at peak times.

Re:Sure

[Cafe Alpha]

That may change. I'm working on a native code Ruby compiler right now.

It's based (among other things) on the principle that you can optimize to your hearts content as long as you have the ability to de-optimize running code (and data) when something changes and your optimizations are no longer valid.

Re:Sure

[suv4x4]

I've never used Ruby or RoR, but my impression of it seems to be one of great expectations and not a lot of delivery. I've read way too many blogs by people who built web sites with RoR only to have them crash and burn under load.

You have the right idea about RoR (speaking as someone who excitedly spent /wasted/ a month learning into it). RoR has some hot ideas but it tries to be too smart and locked down for its own good.

CakePHP is a typical PHP open source project: random code, bloated, no direction. It's also cool, in a way, but I'd never run big project on it.

One promising framework for PHP appeared to be Mojavi, but it later stalled and was forked into Agavi. Agavi tends to try to be way too flexible for its own good (unlike RoR), and in the end is just not simple to use. There's just too much stuff in there you'll never use in a real world project, which complicates code understanding and development.

I also find the "CakePHP vs PHP5" question to not make any sense, I'm sorry.

Re:with MySQL, eh... so much for having a choice

[greg1104]

I recently finished a long comparison [postgresql.org] of PostgreSQL and MySQL in the context of mission-critical data that gives a lot more detail on the issues you bring up here.

Generate everything on the fly

[alexibu]

The paradigm of having web pages that you serve, and that are actually files on the server only works for a short time. Mixing any of these inline scripting languages into the HTML document stinks IMO.

As soon as your website is a bit dynamic you are better off generating everything on the fly.
You can describe content with databases and xml and CSS and then have your server generate actual pages from that.

I personally use c++ cgi scripts to generate all pages, as I need to do some computationally expensive crunching as well. Why learn a dodgy scripting language when you know how to do it properly anyway ? As soon as you need to do something different or slightly complex all these scripting languages start to become painfull and you need to start augmenting them anyway.

I realise that I am not a cool web developer, and there are potential security problems with using compiled languages, but this works well for me.

Alex

Re:In other words...

[SQL Error]

Nope. I know enough about high-scaling distributed applications to be dangerous, since that's what I do for a living. I know PHP runs sites like Wikipedia and Digg, among others. I know I've never seen a blogger go on record to complain about PHP not scaling as he expected, while for RoR that sort of thing seemed quite common in the last year and a half or so.

PHP doesn't scale at all. It's a shared-nothing system, so whatever scaling issues you run into are, by definition, nothing to do with PHP itself; they're Apache issues or Linux issues or MySQL issues.

I use CherryPy, which can be run as a shared-nothing system under Apache or as a standalone multi-threaded server. I haven't used Rails, but I believe it offers the same choice. If so, people running into Rails scaling problems simply weren't using it appropriately.

Re:Brrrr...

[doktorjayd]

hmmm

jsp as a presentation layer is fine. particularly for the i18n and heaps of readily available tag libraries which you simply include and scope.

java as a platform for web applications should really be always said as 'java is THE platform for web applications'.

once you step away from the 'type 1' or pure jsp ( or asp, or php ) apps and enter 'type 2' or MVC frameworks, your systems development gets a lot faster, more modularised and much more maintainable.

try struts, springMVC or any of the dozen or so high order open source MVC frameworks. watch JSF mature over the next year or 2.

scalablitly, speed, and available pool of talented developers... why on earth would anyone go php? ( case in point.. how many bank web systems are php based? )

Re:Sure

[dedazo]

You might want to check out YellowPages.com, Twitter.com, and OpenCongress.org.

Well, I "checked" Twitter [radicalbehavior.com]. Are the authors of the other ones also on record saying the technology they chose fails to scale?

Re:Tapestry

[whatever3003]

dear god no. Tapestry is a pile of poo and should be skirted if ever come upon.

I work day in and day out with this spectacularly under-documented, over engineered, verbose, often incomprehensible, brittle framework. While it is possible to do most web development you can think of in it, and it does go to great lengths to provide elaborate abstractions for the mundane tasks of forms, validation, widgets (components), parameter passing and so forth, these abstractions are often leaky and not at all extensible. This is a framework for Java enthusiasts only.

My biggest gripe is that it is ugly ugly ugly. From the sparse documentation, to the vague naming conventions, to the horrific url's that are generated, it's even an embarrassment to have it staining my resume.

Take a dip in the Django pool and then compare the two. Django will redefine any web developers ideas on how things should be done and how well they can be done.

www.djangoproject.com

Ocsigen

[Cultural Sublimation]

If you had really complete freedom and were willing to try out something radically different from existing frameworks, I would suggest you would take a look at Ocsigen [ocsigen.org]. It is based on the OCaml [inria.fr] language, which alone implies a different mindset from traditional frameworks based on imperative languages. Some of Ocsigen's cool features:

• Extends the OCaml type-safety into the generation of XHTML. This means that producing valid XHTML is not only "nice", but actually enforced by the framework: your programme won't even compile otherwise!
• The entire site is seen as a programme where each public URL is a function. The OCaml type-safety is extended to forms and internal links, meaning there can't be any inconsistencies whatsoever.
• With database bindings such as PG'OCaml [merjis.com], you can extend the type-safety also to database access. Think about it: the compiler checks at compile-time if your programme is consistent with the database itself!
• Functional programming is very high-level, which means rapid development and happy programmers.
• It is fast. And by fast I mean really, really, fast. How would you like your web framework to generate native code whose speed is close to that obtained with C?

Sorry if this sounds like a sales pitch, but I would just like to point out that there are wonderful technologies out there, if people were just willing to take a step outside the trodden path.

Re:In other words...

[Foofoobar]

I ran PHPulse, the world's fastest MVC framework for PHP with a 10 terabyte database backend gets millions of hits daily and having to send data to our team in Manila and Tijuana. PHPulse gave us near split second page loads. As for not scaling, tell that to all the companies like Disney, IBM, AT&T, MTV and others who use it on their frontend. It's the most widely deployed web language out there and there is example after example after example of it scaling.

Hell, even the Ruby, and Ruby on Rails site http://shiflett.org/blog/2006/feb/php-easter-eggs [shiflett.org]> need PHP in order to scale

Turbogears rocks!

[SimHacker]

I've developed a large complex project on an earlier version of TurboGears, with CherryPy/SQLObject/Kid, and I love it.

TurboGears is quite modular, and the newer modules are even better: SQLAlchemy instead of SQLObject (database interface), and Genshi instead of Kid (templating system).

-Don

Re:Sure

[knewter]

Well, you can get specific like that, yes. But please, follow the story to its completion [sharedcopy.com]. The issue was solved, and easily solvable from day one. (For a better solution to the same problem, see this link [drnicwilliams.com].)

I currently write chronically non-scaling Rails apps myself. I can write apps in Rails that scale well, but it turns out there's a huge market for sites that don't need to, and that's where I'm spending some time these days. I've also worked on a nicely-scaling social network site in Rails. There are plenty of tutorials on how to make sure your Rails app scales, but here are the things I'll have to do to my company's custom CMS to make it scale:

1. Make admins visit the site via admin.site.com
2. Turn off page caching for admin. requests
3. Turn on page caching for everyone else, and expire the caches every five minutes

Oh noes! The horror! Then it's up to Apache to handle pretty much every request. Of course, my use case only has to make static content scale. As long as you're actually writing nice stateless apps on the web, in whatever language, they'll scale. If a given URL has static content across visits, they'll scale insanely well, because you don't Mb>use RoR to serve the site in those cases, you use Apache.

Seriously rethinking RoR

[shagymoe]

All the posts I've seen so far complain about RoR's scalability. These people have obviously not worked with RoR because, while scalability might be an issue, if they'd really worked with RoR, they would know that DEPLOYMENT is what kills rails.

I jumped on the RoR bandwagon full bore and have been developing my app for over 1 year. The Ruby language is awesome and the framework takes the messiness out of web development. When I look at PHP code now I was to puke. With that said, I can deploy a PHP application is seconds...literally. Rails on the other hand, has had me working almost full time for 3 weeks trying to get a fucking test (not production...test) server up and running. It is completely fucking ridiculous to get a server set up that you could seriously test with or, God forbid, move into production.

I've been a Systems Admin for over 7 years and a programmer for 6 years and using Linux for at least 8 years so I'm no newbie or idiot. I've tried setting up everything manually as well as using Capistrano and Capistrano/Deprec and still haven't had success getting a server setup.

It is unbelievable how many crazy little nuances and bizarre configuration parameters you will encounter. In a short period of time you are just copying and pasting any random crap someone posted on the net that claims to have a working server. I've followed countless tutorials TO THE LETTER and this shit still doesn't work.

I even purchased the "Deploying Rails Applications" book from Pragmatic Programmers and STILL CAN'T FUCKING GET SOMETHING DEPLOYED!!! Possibly the worst written book ever and claims to give you everything you need to get the Rails stack set up on Ubuntu Dapper Drake and has almost zero setup commands. What a load of crap. Anyone could have written this book since he just lifted it all from internet posts. Good job asshole, thanks for nothing.

You know what happens to people who can successfully set up a Rails application? They start a fucking hosting company and make a shitload of money because hardly anyone else can do it. EngineYard, SliceHost, and RailsMachine are all examples of Rails programmers who started hosting companies because they actually made something work. It really just shouldn't be that hard.

Maybe someday Rails will be easy to deploy, but right now it is a fucking nightmare. It totally ruins all of the great things about Ruby and Rails. I'm starting to think it's all a conspiracy and Rails was just some kind of carrot to lure us all into purchasing expensive hosting.

The hype about Rails' faster development time is true right up until implementation and then it's a load of shit. Implementing a PHP app is like 2nd grade math, whereas implementing a Rails app is like quantum physics.

I've never been so fucking frustrated about anything computer related in all my life. If you don't have a high tolerance for wading through tons of bullshit, then I don't recommend trying to implement a Rails app at this time.

Re:Python and Django

[Richthofen80]

almost all of the API is procedural,

You're right, but is this necessarily a bad thing?

The web itself is procedural. Unless you're a sadist, web applications are broken out into different URIs that handle different part of the applications. Administration functions might be in myapp/admin ... and I break up each edit/add/delete into its own .php file. This way, it is inherently clear what the purpose of each file/URI is, and the functionality doesn't bleed over into 50+ deep include'd files so you have to search forever to find what you need. Especially if you're a small staff with a big project, I find that encapsulating the code for the specific job ends up being procedural on the web. The web is stateless so even if you have time to populate some decently complex object, you have to manually persist the object through later requests.

The only time I've found the web not-so-procedural is with shopping carts. Carts tend to be the kind of thing where an object makes sense $Cart->AddItemToCart(productID); makes sense to me. But on the other types of pages, like web reports, login screens, administration screens, etc? that stuff seems to be a simple branch: if POST, update database fields that map to form fields. If not, show database fields in form fields.

Re:Sure

[metalhed77]

You're totally off base but so is this article.

PHP is comparable to Ruby or ModRuby. Ruby on Rails is a framework.

Of course there's no scaling issues with these languages because they're just programming languages. Things like load balancing are something YOU have to take into account as you build your website and manually handle. You can architect things anyway you want, so if stuff fails it's your fault. This means DB transactions, sessions, templating, etc. are all things you have to handle. The language can't be at fault for these things.

Ruby on Rails is slower for many things because it saves you upfront development time and makes refactoring and adding features a breeze. For many people this is perfectly fine. I write intranet apps for my company in RoR all the time, and it's great. We do not handle many users, but we DO care about getting functionality fast.

Also, for some ridiculous reason people seem to think that RoR does not scale because an out of the box RoR stack may not scale perfectly (like Twitter). RoR may be slower than a tuned PHP script in some cases, but it scales horizontally just fine.

Lots of people may think Twitter and say RoR doesn't scale. But what they don't know is that twitter didn't scale because their DB didn't scale to handle that many writes. You can always throw more boxen at rails and get a larger pool of Rails processes to distribute the load to. You can throw Memcached at it to speed up queries as well, but at the time the whole Twitter complaint happened Rails only supported one database connection. This was fixed soon after. The fact is though, that once you have a service with so many reads and writes like twitter, out of the box ANYTHING is going to suck. Rails, however, gained the necessary functionality (Magic Multiconnections) and allows for all the custom tweaks, performancing tuning, and caching you'll need.

Re:Django.

[Anonymous Coward]

I also vote Django. It has been shown to scale well and can take advantage of caching and all sorts of fun stuff.

Re:Python and Django

[nuzak]

The web itself is procedural. Unless you're a sadist, web applications are broken out into different URIs that handle different part of the applications.

Sounds functional to me. Throw the inherent statelessness of the protocol on top for a bonus.