Hacker News Reader

Comment by danso | Hacker News Reader

So...what have people's experience been in trying to have fat-client-like speed with TurboLinks? Not necessarily with Rails 4.0, but in general? I imagine for some Rails users, the decision is not just whether to go from 2.x/3.x to 4, but whether to go to Sinatra + Backbone/Angular/Ember/etc

View on HN

The speed improvement from turbolinks can be quite significant. I have an application that was purpose built for pjax and later converted to turbolinks. Page loads are noticeably faster than without turbolinks, and are on the same order as a fat-client application.

The beautiful part is that while writing most code in pure Rails you don't need to think about turbolinks at all - it just comes for free.

BTW, turbolinks is a bit improvement over pjax. It is much simpler (since the whole page is loaded), discouraging some of the complexity that you might be tempted to introduce by pjaxing different parts of the page.

Converting an existing app to turbolinks will take some work, especially with how JS is handled. The key is to run your JS on the turbolinks "page:change" callback and then call the same callback on the initial page load:

    $ ->
      # Simulate turbolinks page change on document ready.
      $(document).trigger "page:change"

Does it still break horribly and double-request everything if you have things like <link rel="canonical"> in your website?

I don't know when it was doing that, but the current version of Turbolinks only seems to affect the Asset Pipeline. It doesn't do anything to random link tags on your page. I specifically checked a page with rel="canonical" and Turbolinks only made one request.

Last I looked at it, Turbolinks parsed the <head> section of the incoming request to see if any assets (which was basically...count the script/link nodes) changed. If they did, it went ahead and redirected to the requested URL, since it couldn't be sure that assets hadn't changed.

This meant that anything page-specific in your <head> caused Turbolinks to double the work your app had do to, and provided no positive benefit at all.

I'll check and see how it's behaving now.

Edit: Looks like concerned assets are now tagged with a data attribute. Glad that's in there now.

You're taking a lot for granted if you think Sinatra can act as a replacement to the Rails backend (security, helpers, etc).

Even if your UI is all in JS, Rails still saves a ton of work as an API server compared to Sinatra.

Any examples? My experience with Rails and Sinatra on a daily basis for the last two years has proven the exact opposite.

https://github.com/rails-api/rails-api#why-use-rails-for-jso...

That's definitely a decent list, but the problem for me is that you are also forced to have EVERYTHING ELSE! It's all nicely required in the for you in your app and there aren't straightforward ways to remove 90% of the stuff you don't want.

I work with rails every day for the last 6+ years and it was a revelation when I started. Now I still think it works decently well for large web-apps, but it's just grown way to big over the years. Basecamp is awesome and a great proving ground, but I'd wager the vast majority of apps written in RoR come no where close to needing most of what's included today.

I'm curious as to why having that stuff available is a bad thing?

memory overhead (both for the machine and human), modifying core classes unnecessarily, complexity of third party software, setting defaults to on that aren't applicable to 90% of apps (see turbolinks which breaks the way the web and browsers work).

I'll admit to being on a hard-core minimalist, simplicity, explicit coding kick recently, so I'm already biased against behemoth frameworks. Rails is wonderful if you need that level of complexity/features. I don't think most apps do and we're "forcing" everyone to write basecamp when that is overengineering for most apps.

I'd add security to that list. Rails' most notorious vulnerability was the result of an on-by-default feature that 90% of developers never even needed. I'm not suggesting that Rails is inherently insecure or that Sinatra/Rack cannot be exploited, but less unnecessary code leaves less potential for vulnerabilities; this is especially true in the Ruby world where many developers are eager to `gem install` anything with a few stars on github.

meh, I'm not convinced. I've written some very complex APIs and sinatra-contrib covers most ancillary needs. I'm not saying Rails is always the wrong choice for an API, but most of the bullet points listed in this guide are covered or unnecessary. If you have tons of sprawling back-end logic that is exposed through your API, Rails makes sense, but time and time again I've seen first-hand how much more quickly Sinatra gets us up and going and it's always less work for new developers to grok the application flow.

Reply on news.ycombinator.com