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

JComboBox with Disabled Items

Recently, I was working on a project in Java and needed to have a combo box, but with certain items in the list disabled (e.g. gray and non-selectable). At first, I simply set a custom renderer for the combo box which checked if the item was disabled. That, however, did not prevent the items from being selected. Thus, I set about to find a viable solution. There are plenty of solutions out there, but none seemed to work exactly the way I wanted. In the end, I ended up subclassing JComboBox to provide the functionality of disabling individual items. Here is my result, in under 100 lines: import java.awt.Component; import java.util.ArrayList; import javax.swing.JComboBox; import javax.swing.JList; import javax.swing.plaf.basic.BasicComboBoxRenderer; public class PartialDisableComboBox extends JComboBox { private static final long serialVersionUID = -1690671707274328126L; private ArrayList<boolean> itemsState = new ArrayList<boolean>(); public PartialDisableComboBox