Tip #1 - Embrace Conventions

Rails and Ember both are opinionated frameworks. These opinions are based around conventions that make us extremely productive. As Rails developers we know this first hand. When learning Rails, you may have found yourself struggling to learn something...

Tip #2 - There is No More Page Reload

In any server rendered framework, page reloads clear state. Your app might have sections that contain a lot of AJAX, but for the most part you start with a fresh state every time a user clicks a link. Not so with a client-side framework.

In Ember...

Tip #3 - Start with the URL

In Rails, the Router maps URLs directly to a controller action. We have a file in Rails called routes.rb that contains these mappings and determines our URL structure (HTTP Method, whether they are nested, parameters, etc).

Ember works a little bit...

Tip #4 - Controllers Are Not Controllers

Controllers in Rails and controllers in Ember have quite a few differences. In Rails, controllers are responsible for fetching data from your models. As a Rails developer, you’ve probably heard the phrase “fat models skinny controllers.” This mantra...

Tip #5 - You Already Understand Models

Models in Rails and models in Ember look pretty similar. The major difference is that models in Ember typically hold attribute information, relationship information, and a few computed properties. In Rails models often contain more logic.

In both...

Tip #6 - Routes Fetch Data

In Rails, controllers have the responsibility of fetching data with optional parameters defined from the URL. In Ember, this same responsibility falls to the route.

Tip #7 - Feel at Home with ember-cli

ember-cli is the command line interface for Ember. It handles running a development server, tests, build tooling, generators and more.

You’re used to something similar with the CLI provided by Rails, so many of the commands will be familiar.

Tip #8 - Debugging & the Ember Inspector

When things go wrong in an application, you need ways to debug the problem. Ember comes with a few tools that work like their Rails counterparts, and one additional tool that’s very powerful.

Tip #9 - Nested Routes = Nested UI

When defining routes in Rails, related resources are almost always grouped together by nesting them.

# config/routes.rb
resources :artist do
  resources :albums do
    resources :album

When defining your routes in Ember, there is one very important thing to keep in mind. You should only nest your routes if your UI is nested.

Tip #10 - Take Time to Understand Promises

Promises are a JavaScript specific feature that don’t have a direct comparison in Rails. Promises are a way to deal with async behavior and can be thought of as an eventual value.

Ember makes heavy use of promises through the RSVP.js library, so it...

Tip #11 - Know how to CRUD

While there are some similarities to Rails, there a few differences to keep in mind when performing CRUD operations in Ember.

Let’s compare creating, updating and deleting a user in both frameworks.

Tip #12 - You Don't Need CoffeeScript

Because CoffeeScript is installed by default in Rails, you might be tempted to use it in your Ember app. Unfortunately, CoffeeScript brings a few annoyances and can cause problems for Ember developers. If you instead use the features provided by ES6 (the next version of JavaScript), you probably won’t even miss it.

Tip #13 - It's OK to Suck at JavaScript

Many Rails developers do not have heavy JavaScript experience. In Rails, we typically build out a page and wire interactivity together with jQuery. When snippets of jQuery get unmanageable, we might make classes using something like CoffeeScript.

Tip #14 - Bring Your Ruby Refactoring Brain

Ruby/Rails introduced many of us to great refactoring patterns; most of which have been around much longer than the language itself. Refactoring code in Ember can be daunting if you’ve never done it before, but you’ll find that many of these patterns still apply.

Tip #15 - Deploy it!

It’s common for Rails developers new to Ember to get a little bit stuck when it comes time to deploy their applications. Because your application is split into two separate repositories (it is, right?) it can be hard to determine the best way to deploy them so that they work together.