Rails JS frameworks: Ember.js vs. AngularJS(airpair.com)
airpair.com
Rails JS frameworks: Ember.js vs. AngularJS
http://www.airpair.com/ruby-on-rails/posts/ember-vs-angular-with-rails
7 comments
The article talks about SPAs, but doesn't go so far as suggesting that an Ember or Angular app could be a separate project altogether from the rails app, requiring no integration with rails, using the back end only as a REST api and serving the static SPA from wherever (say a CDN). There are tradeoffs with this approach, but some would consider this even easier or simpler than having the html/js app 'integrated' with the back end.
This is the direction we're moving on my company, we have group building a restful API, and then we have the front end team that are essentially their first client of the API. So far it's been an extremely positive experience, in the past the "front end" team was expected to dig in to the back end and build out the data collection themselves, now we can have multiple teams working on the same thing without stepping on each others toes because we know where demarcation point of the responsibilities are.
You might want to read this post from Shopify. http://www.shopify.com/technology/15646068-rebuilding-the-sh...
That's really interesting. I've actually put some significant effort into using batman but after a month I dropped it, mainly because of the lack of documentation.
I've also wondered about the pros and cons of doing separate backend APIs and having the front end be a separate client and then also the mobile clients. This seems to be the most theoretically clear/clean way to set stuff up but in my experience, having to replicate the models in javascript never has seemed like a good use of time.
I've also wondered about the pros and cons of doing separate backend APIs and having the front end be a separate client and then also the mobile clients. This seems to be the most theoretically clear/clean way to set stuff up but in my experience, having to replicate the models in javascript never has seemed like a good use of time.
May I know, how do you guys handle authentications and "cookies"/tokens?
You might be interested in https://github.com/lynndylanhurley/ng-token-auth and https://github.com/lynndylanhurley/devise_token_auth, which together collect (what seem to be) best practices for both frontend and backend for token authentication. We're planning on using it for our startup.
Accept authentication using HTTP-BasicAuth and create a token then use the token until it expires.
I do this often with Angular, except using Django as a backend with Django Rest Framework helping out with the API. I find that separating concerns like this leads me to much better code.
I do this as well albeit with Django as my backend.
Grunt has a few plugins that help you manage this as well. If you're using CoffeeScript and/or SASS then I highly recommend grunt-connect-proxy - it's trivial to set up and works like a charm. It's also really useful to stub out HTTP calls by setting up your grunt-connect middleware to deliberately return certain responses.
Grunt has a few plugins that help you manage this as well. If you're using CoffeeScript and/or SASS then I highly recommend grunt-connect-proxy - it's trivial to set up and works like a charm. It's also really useful to stub out HTTP calls by setting up your grunt-connect middleware to deliberately return certain responses.
I agree that this is the simplest way to be structuring a SPA these days. Integration with things that were not designed with SPA-first development in mind become incredibly convoluted, quickly. This is especially true when you want to take advantage of the build tooling that the JS ecosystem provides for. We quickly found ourselves completely bypassing the Rails Asset Pipeline in order to support an "integrated" project.
see also: http://blog.pedago.com/2014/01/21/goodbye-sprockets-a-grunt-...
We've since completely abandoned any Rails views and only interface via REST APIs (and have also migrated to Gulp). While having Rails generated views for admin boilerplate was initially great for prototyping, it probably created more headaches than it was ever worth.
see also: http://blog.pedago.com/2014/01/21/goodbye-sprockets-a-grunt-...
We've since completely abandoned any Rails views and only interface via REST APIs (and have also migrated to Gulp). While having Rails generated views for admin boilerplate was initially great for prototyping, it probably created more headaches than it was ever worth.
similar, a bit of a workaround, but works fine:
http://learnjs.io/blog/2014/03/17/using-browserify-with-rail...
I worked on a blog post for Ember and Rails (using the Ember CLI and building a completely separate Rails API)... Check it out: https://www.devmynd.com/blog/2014-7-rails-ember-js-with-the-...
You're right, and the main reason why the article doesn't go deeper into SPAs is because talking about SPAs with Angular/Ember and Rails is a topic so wide it could be its own article. I tried keeping it short, mentioning common Rails' integration caveats.
Noob question for people:
How do I do CSRF token for separate Ember/Angular app?
Since Rails can't write the CSRF directly on the front end page, how does CSRF work in that case?
How do I do CSRF token for separate Ember/Angular app?
Since Rails can't write the CSRF directly on the front end page, how does CSRF work in that case?
It's generally pretty easy in most frameworks to plug in to all XHR requests (see e.g. jquery's ajaxPrefilter). Then you can simply add a CSRF token to the header of every request (or possibly your authentication details directly).
The Rails unobtrusive adapter for jQuery jquery-ujs has a pretty neat implementation, you can take a look at it here https://github.com/rails/jquery-ujs/blob/master/src/rails.js...
token-bearer authentication scheme = 2 birds, 1 stone
[deleted]
[deleted](1)
If you start a new Ember project today, or want to try Ember and compare it with other frameworks, please use Ember-CLI: http://ember-cli.com/
The style of development CLI introduces makes you incredibly productive. A comparison of Ember without discussing CLI is missing an essential ingredient.
The style of development CLI introduces makes you incredibly productive. A comparison of Ember without discussing CLI is missing an essential ingredient.
Thanks for the heads-up, maybe I can do a follow-up article or add an update into this one to include ember-cli features.
Not only is it productive, it is officially endorsed by the Ember core team as the "right way" to use Ember.
Not only it is endorsed, it is Ember. The project will get lifted to Ember in github by the time Ember 2 comes around
Where can I find more info on Ember 2 roadmap? Thank you.
[deleted]
The Road to Ember 2.0 RFC https://github.com/emberjs/rfcs/pull/15
I really dislike having to start up a separate web server for every project I work on.
Why duplicate logic in the front end? We recently open sourced a lightweight framework for writing coffeescript in rails. It's fully compatible with turbolinks and let's you run only the JS you need. It's called RailsScript ( https://github.com/gemgento/rails_script )
I'd love this if it had a testing framework to go with it. The primary reason we went with Angular was because it was so much easier to test than the spaghetti of jQuery modules and the mess that are events.
Is there any differentiation between the two on API stability?
I got burned last fall trying to build an app with Ember as they kept making breaking changes, even between release candidates (!). Technically Ember was stable, but Ember Data (which is separate I guess?) was doing major refactoring on their API, and it cost us quite a bit of time just trying to keep up. Even today, their GitHub has a disclaimer that it's beta quality and under active development[1]. Ember CLI also says it's very much WIP[2], even though it seems to be the officially endorsed way to build Ember apps.
Does Angular make stronger promises about their stability? Is this sort of thing just the cost of doing business with cutting-edge frameworks? Or am I missing something?
[1]: https://github.com/emberjs/data#api-stability [2]: http://www.ember-cli.com/#community
I got burned last fall trying to build an app with Ember as they kept making breaking changes, even between release candidates (!). Technically Ember was stable, but Ember Data (which is separate I guess?) was doing major refactoring on their API, and it cost us quite a bit of time just trying to keep up. Even today, their GitHub has a disclaimer that it's beta quality and under active development[1]. Ember CLI also says it's very much WIP[2], even though it seems to be the officially endorsed way to build Ember apps.
Does Angular make stronger promises about their stability? Is this sort of thing just the cost of doing business with cutting-edge frameworks? Or am I missing something?
[1]: https://github.com/emberjs/data#api-stability [2]: http://www.ember-cli.com/#community
It seems like it is a bad time for finding enterprise-grade js frameworks. Ember has its disclaimer, Angular is impossible to recommend for new projects since 2.0 isn't out yet and will be entirely different than 1.x, react/flux is still releasing breaking changes, and I'm not sure what else would be considered a very strong candidate.
I found that http://knockoutjs.com/ (which I ultimately picked instead of Angular or Ember) takes backward compatibility very seriously (http://knockoutjs.com/upgrade-notes/v3.0.0.html).
> Is there any differentiation between the two on API stability?
Compare http://angularjs.blogspot.co.il/2014/10/ng-europe-angular-13...
> Our goal with Angular 2 is to make the best possible set of tools for building web apps not constrained by maintaining backwards compatibility with existing APIs
vs https://github.com/emberjs/rfcs/pull/15
> This is not a big-bang rewrite; we will continue development on the master branch, and roll out changes incrementally on the 1.x release train. The 2.0.0 release will simply remove features that have been deprecated between now and then. Our goal is that you can move your Ember app to 2.0 incrementally, one sprint at a time.
Compare http://angularjs.blogspot.co.il/2014/10/ng-europe-angular-13...
> Our goal with Angular 2 is to make the best possible set of tools for building web apps not constrained by maintaining backwards compatibility with existing APIs
vs https://github.com/emberjs/rfcs/pull/15
> This is not a big-bang rewrite; we will continue development on the master branch, and roll out changes incrementally on the 1.x release train. The 2.0.0 release will simply remove features that have been deprecated between now and then. Our goal is that you can move your Ember app to 2.0 incrementally, one sprint at a time.
The AngularJS guys have since modified their plans a bit: https://docs.google.com/document/d/1dZdq2L8EkzimgvU93ypLF9GJ...
TL;DR: they're dedicating team members to continue working on 1.X while they build 2.0. They're also planning out a migration strategy for anyone on 1.X when 2.0 launches
TL;DR: they're dedicating team members to continue working on 1.X while they build 2.0. They're also planning out a migration strategy for anyone on 1.X when 2.0 launches
Ah! Good to know, thank you!
Those are great news!
You forgot to quote the second part of the paragraph that says:
> Once we have an initial version of Angular 2, we'll start to work on a migration path for Angular 1 apps.
Not very intellectually honest of you, in addition you forgot to mention that you're an Ember contributor. Also, as have been said, this: https://docs.google.com/document/d/1dZdq2L8EkzimgvU93ypLF9GJ...
> Once we have an initial version of Angular 2, we'll start to work on a migration path for Angular 1 apps.
Not very intellectually honest of you, in addition you forgot to mention that you're an Ember contributor. Also, as have been said, this: https://docs.google.com/document/d/1dZdq2L8EkzimgvU93ypLF9GJ...
> in addition you forgot to mention that you're an Ember contributor.
I don't have any patches into Ember.
I believe they added in the migration path after I had read it, as that's why everyone had been so upset over the announcement.
I don't have any patches into Ember.
I believe they added in the migration path after I had read it, as that's why everyone had been so upset over the announcement.
Not much in terms of contribution to be found on Github:
https://github.com/emberjs/ember.js/commits?author=steveklab...
He has contributed to a great deal of other open source projects though. Mostly Rust lately it seems:
https://github.com/steveklabnik?tab=activity
https://github.com/emberjs/ember.js/commits?author=steveklab...
He has contributed to a great deal of other open source projects though. Mostly Rust lately it seems:
https://github.com/steveklabnik?tab=activity
About the Angular portion of CSRF integration - one can do this in other ways without disabling the check. One can create a factory that acts as the http interceptor that has the csrf injected. One can also manually crawl the DOM by using document.querySelector and inject the value into the http interceptor for appending to requests. One can also use an http request to fetch the token and have the token served via the xhr and manually bootstrap the app.
Angular is relatively unopinionated here.
Angular is relatively unopinionated here.
In fact, the article mentions in 6.2.2 one client-side solution to handle CSRF token by including it into the $httpProvider's headers.
this is more fun: http://vimeo.com/68215606
I keep forgetting I did this, lol. I gotta admit, I was surprised Tom came out on top so easily with this - not a man to underestimate! ;-)
If you're gonna step to me, better make sure your framework game is tight.
this is very old...lot has been changed for better in Ember and some what in Angular as well..
Readability issue: On my iPhone 6 in landscape I can't read the first couple words of every line because of the stupid little popup menu bar anchored to the left. Put some padding on the text.
Sorry for that. We are using an iPhone 5 for testing, and it seems that the larger iPhone 6 viewport is leading to some unexpected edge cases. We'll roll out a fix now and I will use this as an excuse to get a new phone :)