Skip to main content

Ruby on Rails vs PHP

In my past experience with Web Apps, I have worked with PHP (with MySQL). Now I'm working on my website and using PHP again. At work, however, we are using Ruby on Rails (RoR), with Oracle. This makes me want to do a comparison of the two. Obviously, I will compare RoR and PHP, but both using a MySQL database. Keep in mind that this is based on my impressions, not necessarily the best technical aspects of each language.

RoR Advantages:
  • RubyGems - It's extremely simple to install extra features (calendar date select, etc). Yeah, you can have libraries in PHP, but it's not as simple and polished as RoR. You can even define gem dependencies your app has in environment.rb and then use "rake gems:install" to install all gems your project requires.
  • Layouts and Partials - Let's face it: having a "standard.html.erb" layout (or template, if you will) and then having "" in it is just beautiful. Whatever content you create will automatically (or automagically) replace that. Of course, it's possible to do so in PHP, but not so elegant.
  • OO form submission - having form elements get processed automatically into a Hash when they're submitted is great! can be accessed with model[:attribute] in the controller when the form is submitted. IMHO, that's very useful. In certain cases it can be limiting, but most of the time it's good.
RoR Disadvantages
  • "Convention over Configuration" - OK, that may be good in some cases, but there's just too many conventions. Oh, I just hardcoded an HTML form, but that's supposed to "conventionally" done with helpers. Maybe a bad example, but it gets the point across. Many times, a developer won't know all of the conventions and will hardcode it, only to find out later (by whatever means) that it can be done some much more easily. Sometimes the convention gets in the way, but then it's hard to get around it. Don't get me wrong, I don't like excess configuration, but I'm not exactly a fan of excess convention either.
  • "The Rails Way" - There's no ONE right way to doing something. So why does RoR assume that its Way is the right way for that language? Rails wants you to do things their way. If you're creating a brand new app, with a new database, then it's great. Super simple. But what if you already have a database, and you can't change the field names because of existing apps? Ummmm..... What if you want a primary key that's not "id"? "The Rails Way" doesn't account very well for those scenarios.
  • 2+ databases - RoR is made to work with 1 database. Yes, it's possible to connect to others, but it's designed to work with 1. If you have more, then you have to do some wierd stuff that doesn't fell Rails-like.
  • So many files - There are so many files to work with in RoR. Typically, a table in the DB will correspond to a controller in your code. So for each of those, you have: a controller, a helper, a model, usually 4+ views (new, edit, index, show). That's 7 files for a single table. Some people will prefer to work with many files just to keep things organized, but it can get confusing. Take a 20-table DB, for example. Let's say each of those tables has its own controller. Also, let's have the 4 standard views, Excel export (index.xls.builder), and a form partial, to factor the form out of the new and edit pages. Thats 20 x 9 = 180 files!!! Not to mention the shared stuff, like JS, CSS, images, etc. So in the end, you have about 200 files for a web app.

PHP Advantages:
  • Control - With PHP, you have a lot more control over what goes on and how it goes on. In Rails, if there's some kind of relationship between objects, there's going to be a lot more queries going on in the background, even if you don't need them. Quite possibly, the same result could be achieved with a left join in the query.
  • SQL - Yes, I know. You can write your own queries in Rails, too. But with PHP, I know exactly what my queries are, and when and how many times they're executed. Yes, there's a find_by_sql method in Rails, but that's not the preferred way to do it.
  • Documentation - IMHO, PHP has better documentation than RoR. It comes with lots of examples, and even user-submitted tips and tricks. Somehow, the 4-frame layout of RoR documentation just doesn't stick too well.

PHP Disadvantages
  • Learning - It takes longer to get an app running with PHP than with RoR. At a minimum, you need to learn HTML, PHP, and SQL. With RoR, you have to learn just HTML and RoR (ruby with extra libraries). Personally, I would learn SQL, because you'll probably end up using it anyway to bend RoR to your will.
  • SQL - you have to know how to write SQL queries in order to have a database-driven PHP app. I put this under disadvantages because it's another barrier to entry for newbie programmers. But actually, I think it's a good thing. I think you should know what's going on behind the scenes, rather than relying on auto-magic Rails stuff.

Overall, I would prefer to code in PHP. It feels more natural to me than RoR. For me, there's just too much automation going on in Rails in order to fully appreciate its simplicity. But that's just my personal preference. I haven't (yet) tried JSP or ASP, but I would imagine that they're closer to PHP than RoR.

What are your thoughts on this?


Popular posts from this blog

Linux on XPS 15 9550/9560 with TB16 Dock [Update:3/29]

Finally got a laptop to replace my fat tower at work - Dell XPS 15 9560. I was allowed to choose which one I wanted and chose the XPS for its Linux support since Dell ships developer edition XPS's running Ubuntu so I figured Linux support would be better than other manufacturers. At first they got me the model with the 4K screen but my monitors are 2K and multi-dpi support in Linux is virtually non-existent and even hi-dpi support on its own is pretty terrible. So I got it exchanged for the model with the regular 1080p screen (which happened to also be the updated 9560 model), which works much better. I'm very glad to report that pretty much everything works, including the TB16 desktop dock, with just a bit of settings tweaking. This post is to help anybody considering getting this setup or looking for help getting things working. For now, I am running Kubuntu 16.04 with KDE Neon installed. List of things I explicitly tested and work: WiFi, Bluetooth Thunderbolt charging

My Views on Code Indentation

I have read many, many articles about the whole tab vs. space indentation thing. Personally, I don't necessarily agree with most of them. They will require the coder to use a specific indentation size and stick with it, even forcing that on other coders. First off, let me outline my method for indenting code. Then I will explain the reasons and advantages/disadvantages. When I indent code, I will use tabs, but only at the beginning of a line. To align something in the rest of the line, I will use spaces. If a line spills to the next line(s), I will indent that line two tabs further. Rationale: Tabs Why tabs? First off, they're compact in the file (1 byte each). This is really insignificant with current disk sizes, but still. If you indent in spaces, then your file will be larger (unless you indent with one space). Another advantage of tabs is that a tab is a tab. It doesn't specify by how many spaces the code is indented, but rather by how many tabs it is indente

Generating PDFs in Rails with Prawn and Prawnto

There are several different PDF generation libraries available for Rails apps. Some of these are PDF::Writer, Prawn, Ruport, RGhost, and FlyingSaucer (for JRuby). First off, Ruport is basically a higher-level API for PDF::Writer. FlyingSaucer is only for JRuby (because JRuby allows for loading of Java classes). Not having any experience with RGhost, I can't exactly write a guide for using it. So now it's basically between Prawn and PDF::Writer, unless there's another library I haven't hear of. However, to my dismay, there is not UTF-8 support in PDF::Writer. So Prawn ends up being the PDF generation library of choice. One thing to keep in mind is that Prawn and Prawnto are beta-stage (sometimes even alpha) libraries, so some code hacking is going to be necessary. Also note the Prawnto is not maintained or tested by the Prawn developers, so there's no guarantee that it'll work with future versions (especially since Prawnto's developer has been "below t