5 ms·

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

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.

awj 14y ago
According to recent discussions, turbolinks. It's built into Rails 4 and essentially works by making a call out to the server to fetch raw html and replacing some/all of the DOM with the result. 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.
- JuDue 14y ago
  Turbo links is more suited to traditional web pages. Backbone for single page mini-apps.
  - ibrahima 14y ago
    For traditional web pages does it ever make sense to use Backbone/Ember/etc? I've used Backbone on one project and I kind of like the MVC aspect for some things but the thing I'm working on right now is more of a traditional web app. There are some interactive forms where it kind of makes sense to have a model and a view that reacts to changes in the model, but in the end the form is POSTing to a standard rails controller rather than using AJAX calls to update fields when they change. Right now I'm handling that manually since there aren't too many fields but I wonder if using something like Backbone would be a good idea for this use case.
    - steveklabnik 14y ago
      In the recent discussions about Discourse, it was said that on slower connections, it feels way snappier than a server-side solution would be. 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.
      - ksec 14y ago
        I agree. I would love to see some article on What TurboLinks actually breaks and How to avoid it. As much as the world love JS and Client Side Rendering. My Experience is that most of these people are either designing it with Chrome in Mind ( And hell yes they are ) or People using other browsers with a single tab at a time. ( Tell me if any single developer test their website in a Multi Tab environment ) 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.
        steveklabnik 14y ago
        > I would love to see some article on What TurboLinks actually breaks and How to avoid it. 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.
    - bratsche 14y ago
      I can't comment on Ember or others, but I think Backbone fits into traditional apps just fine. Where I work we're generally a traditional app with many server-rendered pages, but we have a few parts of the site that needed more complex client-side code and we opted to use Backbone for those. 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.
xutopia 14y ago
Rails 4 uses turbolinks. It is a mechanism that instead of loading a new page loads up the HTML via AJAX and replaces the entire content of the page without reloading all the resources(css, js, etc...) 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.
- merry-christmas 14y ago
  Funny that ASP.NET had the same thing, called Smart Navigation, back in 2003.
  - anko 14y ago
    smart navigation is very different. Besides not being supported across browsers, it was more like automatic anchoring.
    - merry-christmas 14y ago
      Nope, it's not automatic anchoring. It uses JS (iframe AJAX) to retrieve a new page from the server and display it without flicker.
  - byroot 14y ago
    2003 or 2013, ASP or Rails both are terrible ideas IHMO. At least as a default. 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.
  - emidln 14y ago
    Much further after that, there was a jQuery plugin called taconite that let you do this from arbitrary languages. The idea was that you can handle all of your templating server side and build the template into a simple xml document that had tags corresponding to jquery dom manipulation functions. You return the template with the right mimetype, and the plugin handles translating your xml template into a dom update. This has been handy a few times to keep all of the display logic centralized in a single templating mechanism.
steveklabnik 14y ago
It just so happens that one of my major contributions to this release was writing a 'working with JavaScript in Rails' guide: http://edgeguides.rubyonrails.org/working_with_javascript_in_rails.html http://edgeguides.rubyonrails.org/working_with_javascript_in... 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.
- jrochkind1 14y ago
  Awesome, thanks so much for writing that guide. 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!
  - steveklabnik 14y ago
    Any time. Please let me know if any parts of it are confusing; the first example I wrote was pretty bad, and someone chipped in with a way better one. :)
- _frog 14y ago
  Just want to chime in and say how fantastically ActiveModel::Serializers and the Ember.js REST adapter work together. I built a project with them over the weekend and the experience was overwhelmingly frictionless to a degree I hadn't experienced doing this kind of thing in the past.
  - steveklabnik 14y ago
    Thanks. I've been kinda ignoring AMS in order to get this release out the door, but now that it's out, expect to see much more soon...
- eCa 14y ago
  Why is the answer on how to use Javascript to use Coffeescript? Does all RoRists use CS instead of JS, or is it considered best practice? (I don't use either Ruby, RoR, Coffeescript or Ember.)

awj 14y ago

According to recent discussions, turbolinks. It's built into Rails 4 and essentially works by making a call out to the server to fetch raw html and replacing some/all of the DOM with the result. 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.

JuDue 14y ago
Turbo links is more suited to traditional web pages. Backbone for single page mini-apps.
- ibrahima 14y ago
  For traditional web pages does it ever make sense to use Backbone/Ember/etc? I've used Backbone on one project and I kind of like the MVC aspect for some things but the thing I'm working on right now is more of a traditional web app. There are some interactive forms where it kind of makes sense to have a model and a view that reacts to changes in the model, but in the end the form is POSTing to a standard rails controller rather than using AJAX calls to update fields when they change. Right now I'm handling that manually since there aren't too many fields but I wonder if using something like Backbone would be a good idea for this use case.
  - steveklabnik 14y ago
    In the recent discussions about Discourse, it was said that on slower connections, it feels way snappier than a server-side solution would be. 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.
    - ksec 14y ago
      I agree. I would love to see some article on What TurboLinks actually breaks and How to avoid it. As much as the world love JS and Client Side Rendering. My Experience is that most of these people are either designing it with Chrome in Mind ( And hell yes they are ) or People using other browsers with a single tab at a time. ( Tell me if any single developer test their website in a Multi Tab environment ) 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.
      - steveklabnik 14y ago
        > I would love to see some article on What TurboLinks actually breaks and How to avoid it. 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.
  - bratsche 14y ago
    I can't comment on Ember or others, but I think Backbone fits into traditional apps just fine. Where I work we're generally a traditional app with many server-rendered pages, but we have a few parts of the site that needed more complex client-side code and we opted to use Backbone for those. 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.

xutopia 14y ago

Rails 4 uses turbolinks. It is a mechanism that instead of loading a new page loads up the HTML via AJAX and replaces the entire content of the page without reloading all the resources(css, js, etc...) 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.

merry-christmas 14y ago
Funny that ASP.NET had the same thing, called Smart Navigation, back in 2003.
- anko 14y ago
  smart navigation is very different. Besides not being supported across browsers, it was more like automatic anchoring.
  - merry-christmas 14y ago
    Nope, it's not automatic anchoring. It uses JS (iframe AJAX) to retrieve a new page from the server and display it without flicker.
- byroot 14y ago
  2003 or 2013, ASP or Rails both are terrible ideas IHMO. At least as a default. 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.
- emidln 14y ago
  Much further after that, there was a jQuery plugin called taconite that let you do this from arbitrary languages. The idea was that you can handle all of your templating server side and build the template into a simple xml document that had tags corresponding to jquery dom manipulation functions. You return the template with the right mimetype, and the plugin handles translating your xml template into a dom update. This has been handy a few times to keep all of the display logic centralized in a single templating mechanism.

steveklabnik 14y ago

It just so happens that one of my major contributions to this release was writing a 'working with JavaScript in Rails' guide: http://edgeguides.rubyonrails.org/working_with_javascript_in_rails.html http://edgeguides.rubyonrails.org/working_with_javascript_in... 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.

jrochkind1 14y ago
Awesome, thanks so much for writing that guide. 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!
- steveklabnik 14y ago
  Any time. Please let me know if any parts of it are confusing; the first example I wrote was pretty bad, and someone chipped in with a way better one. :)
_frog 14y ago
Just want to chime in and say how fantastically ActiveModel::Serializers and the Ember.js REST adapter work together. I built a project with them over the weekend and the experience was overwhelmingly frictionless to a degree I hadn't experienced doing this kind of thing in the past.
- steveklabnik 14y ago
  Thanks. I've been kinda ignoring AMS in order to get this release out the door, but now that it's out, expect to see much more soon...
eCa 14y ago
Why is the answer on how to use Javascript to use Coffeescript? Does all RoRists use CS instead of JS, or is it considered best practice? (I don't use either Ruby, RoR, Coffeescript or Ember.)