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?

Comments

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, BluetoothThunderbolt charging from T…

Listening for Window Resize events with Prototype

Recently, I came across an issue I had with full-screen (more specifically, full-viewport) canvas drawing. It all worked fine, except that the canvas dimensions must be specified in pixels, as opposed to percentages. This means you can't just set the canvas' width and height to "100%" and be done with it...

The dimensions were automatically set when the page loaded, but if the user resized the browser window after that, the canvas would stay the same size, and would be either too big or too small. Thus, the canvas must be resized every time the browser window is resized.

Prototype makes all of this easy. All that's necessary is to attach a listener to the onresize event of the window object, and then use document.viewport.getDimensions() to determine the new width and height.

Here's some sample code:

Event.observe(window, "resize", function() { var width = document.viewport.getWidth(); var height = document.viewport.getHeight(); var dims …

Drawing Dashed Lines on an HTML5 Canvas

The canvas element in HTML is great, but has one strange shortcoming: it cannot draw dashed lines (natively). However, dashed lines seem like a pretty common thing to draw, which only highlights the problem.

Looking around, I've noticed several solutions to this problem. Some use trig, and others use their own libraries that must be imported. So in the end, I decided to create my own method.

This code will add the function to all canvas elements, both those already on the page, and any that are dynamically added later.

Here is the code:
CanvasRenderingContext2D.prototype.dashedLine = function(x1, y1, x2, y2, dashLen) { if (dashLen == undefined) dashLen = 2; this.beginPath(); this.moveTo(x1, y1); var dX = x2 - x1; var dY = y2 - y1; var dashes = Math.floor(Math.sqrt(dX * dX + dY * dY) / dashLen); var dashX = dX / dashes; var dashY = dY / dashes; var q = 0; while (q++ < dashes) { x1 += dashX; y1 += dashY; this[q …