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.
- 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.
- "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.
- 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.
- 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?
Post a Comment