[Update: This now-complete series explains why I, as a previously steadfast PHP programmer, have made the switch to Ruby on Rails and never looked back.] This is not about any negative aspects of PHP. Instead, it is about the positive changes I found which make using Ruby on Rails an extremely pleasant experience. I mislabeled it at the start as you’ll see, but I hope you enjoy the content.

It’s time to kick off the 2013 weekly postathon with the start of my Introduction to Rails series! I’ll be providing a series of opinions and links to guide newcomers through various technologies which use, or are used by, Rails. These will give a high level overview intended to help direct your learning process. I suggest you also read this tutorial for detailed how-to instructions and specific language syntax.

So, who am I to be teaching Ruby on Rails? Good question. I’m a(n ex) PHP developer who has spent the last three months, full time, learning the RoR technology stack and using it to build a browser based CRM application for a startup I co-founded. This hardly makes me an expert, but I have a very good idea of what seems new and strange coming to Rails from PHP land.

Asset Pipeline

Our journey into this strange new environment will start with something called the “asset pipeline”. Picture the asset pipeline as a series of automatic steps taken by Rails to switch your assets from developer-friendly to browser-friendly. Two of the steps, concatenation and minification, are used only for production and help to make the site load faster. The compilation step, however, is something that should really interest developers.

If you’re like I was before starting with Rails you write your page markup in HTML. You write your stylesheets in CSS. You write your scripts in JavaScript. I’d heard of languages like CoffeeScript and Dart, but what stopped me from using them was the extra step between editing and executing. When I refresh a thousand times each day that’s a big extra step. Rails takes care of that for you. Edit a file and it is automatically recompiled.

The asset pipeline opens up a door to writing scripts, stylesheets and markup in any language you want without the additional overhead. Let’s have a look at the ones I chose.

Haml

Haml (HTML Abstraction Markup Language) is the solution to HTML. I was forced to learn Haml because the open source CRM we sold to help bootstrap the company uses it. At first I couldn’t see past the annoyance of having to learn a new way of doing something so simple as writing HTML, but after that wore off I was hooked. My favorite parts about Haml are:

  • Never worry about closing tags again. Ever.
  • Less clutter, fewer useless markup characters.
  • Proper indentation enforced by the parser.

If these don’t interest you, well, you’re probably better off staying with Embedded RuBy (ERB). It’s very similar to the way PHP or ASP handles code within regular HTML and won’t require any extra learning. For myself, I think the 5 minutes it took to learn Haml (it’s extremely simple) have vastly improved my happiness level when working with markup.

I’ve recently been introduced to another templating language similar to Haml with with fewer redundant characters. This tool is called Slim and I intend to use it on my next project!

SCSS

Remember all those times you said “I wish CSS had variables”? Well, I know I did. SCSS (Sassy CSS) has variables. Assign PHP-style variables in CSS fashion like $main-text-color: ‘#111’; and use them later in place of values (text-color: $main-text-color;).

That’s neat, but surely it’s not all SCSS can do, is it? You’re right, it’s not. In SCSS you can nest attributes, inherit styles from another element, and create mixins to share styles. The best part is that SCSS is a superset of CSS, meaning that any CSS code is valid SCSS. Pick and choose the features you want while leaving the rest pure CSS.

CoffeeScript

CoffeeScript is a language that compiles into JavaScript. CS has more concise syntax than JS for many common programming structures. In addition, CS uses neither brackets for blocks nor semicolons for line endings. You may not know it yet, but this makes CoffeeScript code feel far more like Ruby code than does JavaScript. Those used to native JS may find CS strange at first, but if you push past that point you’ll be well rewarded.

None of tools I’ve listed here today is a “game changer”. None will turn a poor programmer into a talented programmer. What they will do is save you time. No, I don’t expect you to take my word for it. I expect that if you’re reading this you are looking to improve yourself through education. Educate yourself. Learn the tools and use them. Compare for yourself and you will see the advantages.

This concludes the first part of my Introduction to Rails series. I hope you found it useful. [Update: Zero Downtime Deployment with Capistrano has been posted.]