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.
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 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.
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.
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.
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.
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).
I beg to differ, at least for most websites/webapps.
If you serve your front-end in a static way (via for instance a CDN), you can make your landing page (and the pricing page, blog, etc.) ungodly fast: just make it purely static (or nearly so, as long as the extra content doesn't need to be indexed).
After all for most webapps the angular/ember/react/cappuccino (I was surprised to see that the latter is still alive) doesn't have to be the landing page.
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.
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.
I usually test my Rails/Angular projects with jasmine-rails jasmine-jquery and Sinon.JS. These three together let you test virtually any frontend js code.
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?
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.
> 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
> 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.
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
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.
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 :)
