What is the "Rails way" of doing AJAX calls and updating the DOM? I've been embedding Backbone views in the parts of my app that are the most interactive, but I feel like there's gotta be a better way.
Others mentioned Turbolinks, but they forgot about remote_form_for and friends.
If you _are_ building a full JavaScript application, Ember.js works really well with Rails + ActiveModel::Serializers. There might be some rough patches until Ember hits 1.0 final, but most of the pieces are in place.
JS in Rails had gotten confusing lately, with changes being made over time to supported options and 'golden paths', but insufficient docs on what Rails expected/recommended.
Thanks for working to rectify that!
(I don't use either Ruby, RoR, Coffeescript or Ember.)
> Does all RoRists use CS instead of JS, or is it considered best practice?
It is currently considered best practice to use CS instead of JS, which is why the gem is included in your Gemfile by default. Not every Rails project uses it; Discourse just ported all their stuff to JS, even though they started with CS.
Personally I just use Backbone and try to structure things in whatever way seems natural. It looks like there's been a lot of work done in integrating Ember.js if you want to look into that.
Backbone for single page mini-apps.
Frankly, I'm a server-side guy, so I prefer that kind of development, but there are advantages to SPAs, and like any good engineer, you should use the right tool for the job. Rails is modular enough that you can do whatever you want, Turbolinks is just a gem, so if you don't want to use it, you can just pull it out of the Gemfile.
If be willing to bet that the less dynamic interaction per page, the less an SPA makes sense. ;)
That said, I can also see how something like Ember gives you a nice way to do API-first development, so even if your site is more static, it could make sense.
As always: It Depends. Don't believe anyone who tells you they have a silver bullet.
Having JS heavy web page will slow down the browsers. That even includes Chrome, you just need a larger number of tabs. On Firefox a few JS heavy site with a slow computer will make your site experience sucks.
Although not a single user would blame the site ( It is always the browsers' fault. ) but to me, most of the time, the less JS the better.
Discourse is pretty fast, but to say 300K zipped JS file is peanuts just doesn't cut it for me ( How about 100K? That is peanuts. ) And again, slow JS execution and loading is something i have zero control of.
The big change is that instead of getting a clean slate every request, you now have one, long-running JavaScript environment. That's where Turbolinks derives its speed from, but it's the biggest change, and this difference in assumption has been where the issues have popped up.
Honestly, I have not followed turbolinks' development very much, so I'd look through the Issues if I were you to get a better idea of what kinds of things have cropped up so far.
> Discourse is pretty fast, but to say 300K zipped JS file is peanuts just doesn't cut it for me
Sure. I think you'd be surprised how quickly you can get up to 300k of assets in a site, though. Plus, you're only fetching it once, it's all cached afterwards. Regardless, as far as I'm concerned, the practice beats the theory. Turbolinks and Ember have both been show to speed up web sites in practice.
Backbone is a pretty slender library, you can pretty much use it however makes sense to you. You could go really hardcore and do a site that's client-side-everything, or you could do hybrid approach like we did.
So instead of having to deal with plenty of small ajax calls you just build an app as it would work in plain HTML and just use turbolinks to leverage AJAX.
Sure it can be very efficient, but it's a terrible default.
When DHH state: > except, maybe, compatibility issues with some existing JavaScript packages
Some ? Don't you mean most ? Even Twitter Bootstrap will leak memory if used in a turbolink app.
When coffeescript is pushed as default, I'm ok, at worst you don't use it and you have a useless gem. But turbolink is harmful if you don't know what you are doing.
TurboLink always replace the whole body, not just part of the page. There's no input focus to maintain. Server side render a page the same regardless of whether it's fetched normally or through TurboLink. Links fallback correctly on JS-disabled client.
This does not seem like a super great idea, like merry-christmas mentioned too much like ASP.NET.
I'll do some reading on turbolinks and see if there's something super I'm missing.
Apparently, even though the browser doesn't re-download the assets, it does re-parse and re-execute all of it. Which makes sense. This is where Turbolinks adds the speedup.