Integrating Ruby on Rails and Angular

Let’s say I have a Rails app that I want to use to serve as a JSON API for an Angular app. How should I set it up?


  • until the teams working on this project are big enough to want to split into “client” and “server” teams, I want one codebase because it’s
    • simpler to keep in sync
    • easier to work on the front-end and back-ends simultaneously
  • For initial simplicity, Rails should serve both the client and API code
  • For later simplicity, breaking out the client from the server should be easy so they should be minimally coupled now


  1. get a Rails app, e.g. via “rails new blog”
  2. turn off the Rails asset pipeline so the only html/js is that generated by the Angular application
    1. edit /config/application.rb
    2. add this line within the “class Application” block in
      • config.assets.enabled = false
  3. add the Angular application to the Rails codebase
    1. cd /app/assets/javascripts
    2. brunch new my_app_name
    3. cd my_app_name
    4. bower install
  4. make your new Angular app send its output to the rails “public” folder
    1. edit
    2. change “public: ‘_public'” to “public: ‘../../../../public'”
  5. generate the Angular code, which will output to the Rails /public folder
    1. ./scripts/
  6. start the rails server
    1. cd ../../../..
    2. rails server

Done, enjoy!



Setting up Sublime Text 3 for Markdown, CoffeeScript, Jade, LESS, Stylus and Ruby

Mostly notes for myself:

A tour of angular-brunch-seed-modularized

The code

Why Angular-seed?

It’s an easy way to have a starter app to build on in the Angular way

Why Angular-seed “modularized”?

The original seed has files broken up by type (directives, filters, etc.) but Misko and long-established best practices say it would be better to have the files broken up by feature (user profile, product display page, etc.).

Why use angular/ui-router instead of $routeProvider?

It allows output to multiple named views, nested views, etc. Routing and ng-view was mentioned by many online as pain points for larger apps so this arrangement should be much better.

Why Brunch?

It makes it very easy to get a complete development environment set up in seconds. For me, it was more mature, simple and reliable than Yeoman, though the reliability difference is hopefully gone by now.

Why base it on Angular-brunch-seed?

It has a great ready-to-roll JS development environment, with these features:

  • Coffeescript / Jade / Less / Stylus automatically compiled on save
  • auto-reload during development saves you from manually refreshing the page
  • Javascript / CSS minification for production
  • karma integration for unit tests
  • Twitter Bootstrap integration, with themes

Why Coffeescript / Jade / Less / Stylus?

Coding gets complex. I like to have the code look as simple and clean as possible, so problems and opportunities for better design are more visible. These compilers make the code syntax simple and clean.

  • Their downside, though, is that they add more syntax to learn and a compile step. If you want to simply not use them, it’s easy, see the docs.

What’s different, now that it’s “modularized”?

Check out the /app/sections folder, where you’ll find this structure that can easily be expanded upon to have directives and filers like /app/scripts does







What’s different now that it’s using angular/ui-router?

In index.jade, see the ui-view entry, which sets up the ui-router directive


In, see the bottom where the states are specified.

That’s it, it’s that easy.

How to integrate Rails and Yeoman

How to integrate Rails and Yeoman

Angular-brunch-seed-modularized, now with better routing for complex apps

Angular-brunch-seed-modularized now uses angular-ui-router for routing and views

Instead of using the $routeProvider, it uses angular-ui-router to allow output to multiple named views, nested views, etc. Routing and ng-view was mentioned by many online as pain points for larger apps. This arrangement should be much better.

My GDoc notes on Angular, in case they’re helpful

My GDoc notes on Angular, in case they’re helpful

A modularized version of Angular-brunch-seed

I created a modularized version of angular-brunch-seed to make it easier for people (including myself) to build apps that follow Misko’s best practices.

Want more detail? From the additions to the docs:

Angular-brunch-seed is awesome, a great start for making Angular apps. I wanted this “modularized” version because Misko recommends organizing code around features rather than type of code, like controllers.coffeee, etc. (see this 10/27/13 presentation).

That is, organize your modules by feature. Instead of one big module, have one module per feature (or page). This is better now for

  • unit testing
  • working with larger teams (to not step on each others’ work)
  • preparing for the future because modules will be able to be lazy-loaded and so this structure will be either required or firmly recommended

I was partly inspired by ng-boilerplate.

Updated notes on Ember and Angular

Ember vs Angular

I’ve been studying the two for a while and I thought my notes might be useful for others. If you spot errors or have additions that might help others decide, please leave a comment and I’ll update the text. Thanks, enjoy!

My take overall

It would be lame not to say where I landed after all this reading, so here it is: I like Angular’s declarative easy-to-read markup (“it’s just extended HTML”), its use of dependency injection everywhere, the simplicity of its direct action on the DOM, and its highly flexible directives for making components. It seems more inherently modular and flexible to me, less prescriptive than Ember but with enough power for pretty much any application. That said, Ember promises to be tightly integrated with Rails (like Java-Granite?) so for a committed Rails shop Ember may well be the better choice (but then what happens if you switch server technologies as you grow?).

My rule of thumb is that Ember is basically automating well-thought-out Backbone application construction, very much as Rails does for ruby server app construction. It’s good for those who think in terms of creating complex web sites.

On the other hand, Angular extends HTML itself, creating new component sets that can be used as quickly and easily as the “<table>” tag. Angular is good for those who think in terms of creating complex applications in more traditional software.

Things that worry me about Ember

  • No one seems to know how asynchronous testing should be done
  • Ember Data is very much a work in progress
  • Though they’re simplifying it to only work with conventional APIs, so it could stabilize fairly quickly, performance characteristics for it are unknown since it’s been changing so much, and therefore the same is true for how to optimize it
  • A nice set of links about Ember’s recent growing pains, especially the links from the Ember team
  • Errplane had a rough time with Ember, mostly because of Ember Data
  • Does its structure tempt one to make monolithic client apps rather than combining small apps to make a bigger one?

Things that are exciting about Ember

  • Yehuda Katz
  • Familiar concepts for Rails devs
  • Notes on a happy migration to Ember from a Rails app

Things that worry me about Angular

  • Do directives make markup harder to read? (I think actually they make it easier to see the intent of the software, especially for junior devs)
  • Directives have some complexity to them, which may limit their use (On the other hand, they’re really flexible and could handle making complex components.)
  • Why are there so few public libraries of directives if they’re so handy? Angular 1.x has been out for a year. (Possibly it’s that most users are enterprises that are less likely to share code)
  • Complaints from a blog: Not every framework is perfect, and you’ll find scenarios where Angular is not a good fit. There are certainly scenarios when change detection will be milliseconds slower than observing changes. It’s not obvious how to track animations or respond to focus events. Form validation is subpar. Angular is not minimalistic and comes with strong opinions. Writing lower level components, like custom directives, requires some focused effort. You also need some understanding of prototypal inheritance to avoid getting into trouble in more advanced scenarios.
  • How easy is it to use widgets from other libraries, like Bootstrap? The issue is the bindings, you need a way to pass values into the widgets. I think it might be easy because it’s just HTML. Put the widget in, have the bindings and use it. But I need to test it.
  • Something to be careful about with Angular: Unfortunately it is way too easy to add slow comparison into angular, so it is easy to build slow apps when you don’t know what you are doing. But we hope to have an answer by providing an instrumentation module, which would show you which are the slow comparisons.

Things that are exciting about Angular

  • It makes HTML markup declarative, which is nicer and more flexible than the more standard iterative approaches
  • It uses dependency injection everywhere, so both testing and programming in the functional style are easier
  • Google uses it on major production sites
  • Google funds its development (though Tom Dale asserts that an order of magnitude more are working on Ember)
  • Directives should make sharing assets and functionality trivial across projects; you just need to depend on a company library of new HTML tags
  • Using Bower to manage your directives
  • Its end-to-end testing system is very simple and cool
  • Performance looks good if this is at all to be believed (I think it’s really of very limited value as a measure)

My summary of the arguments I’ve seen

Ember advocate says: Ember integrates more easily with widget libraries like Bootstrap
Angular counter: the wrappers are pretty easy to make (where’s that ref?)
Counter counter: The way AngularJS manages the DOM is somewhat at odds with the way people are used to building CSS and “widgets”. AngularJS does a lot of DOM *re-structuring* whereas a lot of widgets do a lot DOM *hiding*. This caused a number of problems with things like Twitter Bootstrap which has a lot of “content” DIVs with “active” classes on them to indicate show/hide. The problem was, we have AngularJS actually ripping those things out of the DOM with ngSwitch so the concept of “active” becomes irrelevant at the CSS level and only relevant at the DOM level.

Ember advocate says: Ember will integrate seamlessly with Rails
Angular counter: true, Ember will always be tighter with Rails, for good and bad

Ember advocate says: Ember’s templates are just strings and so can be compiled on the server, improving app startup speed
Angular counter: those templates are separate from DOM so updates have to be inserted into the DOM using innerHTML, which can clobber ongoing user input; using the DOM directly simplifies cases like that, improves consistency and is worth the insignificant startup speed cost

Tom Dale arguments for why Ember is better, with Angular counter-arguments

Ember advocate says: Ember is based on Cocoa, Backbone and jQuery; it uses the best of all to make writing apps in the browser that feel native
Angular counter:Ember is bolting on non-web stuff from Rails and Cocoa. Angular improves HTML, the actual core of the browser experience

Ember advocate says: Angular is a research project; Ember talks about MVC whereas Angular talks about scopes, directives and transclusions
Angular counter: this seems pejorative and misleading. Angular is used by big players like Sony and DoubleClick (Double Click talked about their 100k SLOC javascript Angular app here, though DC is Google property) and appears to have a strong community. It’s not the Rails community, though, like Ember has. Angular talks about MVC but also talks about “scopes, directives and transclusions” because they’re necessary to solve problems that come up when you add new HTML tags. No one has to do that, it’s a power-user feature

Ember advocate says: Ember’s template syntax (Handlebars) is nicer
Angular counter: Not really, it’s more complicated since you’re not just working with DOM but instead bolting something onto it

Ember advocate says: Ember should be faster starting up because Angular has to compile and link the whole DOM whereas Handlebars templates can be compiled server-side
Angular counter: No one seems to comment on slow startup being a noticeable problem

Ember advocate says:Ember should be faster at model-view update cycles because it has listeners on each item rather than using simple dirty-checking like Angular. Ember achieves O(1) performance from data bindings whereas dirty-checking makes Angular O(n), which is why Misko Hevery recommends no more than 2000 bindings in a current view; Ember doesn’t need to limit you like that.
Angular note: Angular dirty-checks everything under the $scope that was used for a call or binding update, not the entire page (unless you call $rootScope.$apply()). You can have 40,000 elements on your page, split up into 20 groups, and if you have each group in a separate scope then angular will dirty-check at most 2,000 elements at a time.
Angular counter: dirty-checking simplifies developer effort and markup by not requiring endless “get() and set()” entries; it also is fast enough for practical purposes now and will soon be blazing fast when Object.observe lands in Chrome and FF (it’s landed in Chrome Canary and is likely to be in AngularJS 2.0, so data bindings will go from O(n) to O(1))
Ember counter: “get() and set() won’t be needed when ES6 proxies land

Ember advocate says: Ember has more people working on it, meaning more man-hours of development: “By making this a truly community project, instead of a “by Google” project, I believe we get an order of magnitude more man-hours contributed to it.”
Angular counter: Angular has a thriving community that contributes, it’s not just Google (ref?)

Ember advocate says: If you ever want to render your app on the server (for indexing by Google crawlers or to make first loads display faster), Angular requires you to boot an entire browser environment like PhantomJS, which is resource-intensive. Handlebars is 100% JavaScript strings so all you need is something like node.js or Rhino.
Angular counter: why would that be a significant problem?

Ember advocate says: String templates are easy to divide up and load lazily, if your app starts getting large.
Angular counter: dividing up the HTML seems just as easy. For lazy loading, just use different Angular apps for different pages, right?

Ember advocate says: Angular allows you to embed arbitrary expressions that live update, which means that Angular has to recompute them every time an involved variable changes, which could be slow
Angular counter: this is a worthwhile tradeoff. Ember makes you specify your dependencies, which is a hassle. Having the computed properties be easy for developers to write makes life better and, used carefully, doesn’t have to slow down the app noticeably

Ember advocate says: Ember is much better positioned to take advantage of the performance benefits of ECMAScript 6 features like Object.observes because Angular has to use a custom parser
Angular counter: the opposite is true

How to install Ruby 1.9.3 and Rails 3.2 on Amazon Linux

Naturally, I tried this the direct way first, installing from source but hit an error in a gem native extension.

So I found this much easier way using RVM and wanted to share it!

First install RVM

Then it’s really easy

  1. rvm install 1.9.3
  2. rvm gemset create rails32 (to create a gemset to use with the latest rails)
  3. rvm 1.9.3@rails32 (to set that ruby as current, with that gemset)
  4. gem install rails –no-ri –no-rdoc

Done, enjoy!