Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby on Rails 4.0.0.beta1 released

weblog.rubyonrails.org

Post reply on HN
Print view View original

81–90 of 91 posts

Re: Ruby on Rails 4.0.0.beta1 released

#81

Post by joesb »

merry-christmas wrote: post #23
xutopia wrote: post #19

Earlier quoted context omitted.

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.

Funny that ASP.NET had the same thing, called Smart Navigation, back in 2003.

TurboLink does less, so there are less things to screw up.

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.

Re: Ruby on Rails 4.0.0.beta1 released

#82

Post by steveklabnik »

ksec wrote: post #70
steveklabnik wrote: post #35

Earlier quoted context omitted.

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 w…

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 h…

> 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.

Re: Ruby on Rails 4.0.0.beta1 released

#83

Post by steveklabnik »

pmarsh wrote: post #72
xutopia wrote: post #19

Earlier quoted context omitted.

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.

But if two pages have the same resource URLs for their css, js, etc they should be cached by the browser so moving from page to page shouldn't be reloading them. 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.

I did some speed tests here: https://github.com/steveklabnik/turbolinks_test

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.

Re: Ruby on Rails 4.0.0.beta1 released

#84

Post by steveklabnik »

33degrees wrote: post #49
steveklabnik wrote: post #29

Earlier quoted context omitted.

Matz likes the fact that it Just Works and you can't accidentally have weirdness based on how your code runs. There aren't any plans to remove it at this time.

I can imagine a whole bunch of gems suddenly breaking if this changes...

That's true, but I don't buy that argument: look at how fast everyone has updated their gems to be Ruby 2.0 compatible. The Ruby world likes running on the edge; if MRI forced us to consider thread safety, we'd learn about the issue much quicker as a community. Since we'd be forced to. ;)

Re: Ruby on Rails 4.0.0.beta1 released

#85

Post by steveklabnik »

davidw wrote: post #63

Is the web socket story substantially the same? In other words, Rails just isn't that great a platform for it? I think Rails is great, but this is one area where it's not a good choice.

We don't do anything specific with WebSockets. ActionController::Live may be able to help you there, in theory, but I'm not incredibly educated on the subject, to be honest.

Re: Ruby on Rails 4.0.0.beta1 released

#87

Post by DanielKehoe »

Here's an article that shows how to set up both Rails 3.2 and 4.0 with Ruby 2.0. Uses some new features of rvm. "With both versions on your machine, you’ll explore the new features of Rails 4.0 while continuing to develop projects with the most recent stable version."

http://railsapps.github.com/installing-rails.html

Re: Ruby on Rails 4.0.0.beta1 released

#88

Post by eCa »

steveklabnik wrote: post #26
5vforest wrote: post #17

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.

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... 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 patch…

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.)

Re: Ruby on Rails 4.0.0.beta1 released

#89

Post by steveklabnik »

eCa wrote: post #88
steveklabnik wrote: post #26

Earlier quoted context omitted.

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... 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 patch…

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.)

In order to use just JavaScript... you just write JavaScript. Nothing special. If you don't want to use it at all, you can also remove the gem from your Gemfile.

> 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.

Re: Ruby on Rails 4.0.0.beta1 released

#90

Post by VeejayRampay »

davidw wrote: post #63

Is the web socket story substantially the same? In other words, Rails just isn't that great a platform for it? I think Rails is great, but this is one area where it's not a good choice.

The general opinion in the Rails ecosystem seems to be that WebSockets don't solve any real problems and that they are a toy.

The only mentions of WebSockets I've seen from people invested in Rails are mostly made of people actually deriding them and passive-aggressively making fun of people that use them or want to (generally in a bunch with MongoDB, Hadoop, Cassandra or other modern big data tools that don't fall naturally in the Rails ecosystem).

But then again, it's not like they have an infinite amount of time to invest into everything and anything and they worked on SSE for Rails 4 on top of shitloads of additional goodies, patched a lot of security issues so overall I'm pretty happy as an end-user.

Post reply on HN