Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Turbolinks are not good for usability.

They appear to make the pages painfully slow on slower connections.

They add a loading bar across the top which can have different meanings depending on the site and browser:

- some browsers add a bar across the top to indicate page loading progress (example: Firefox for Android)

- some websites add a bar across the top to indicate how far you've read in an article

- turbolinks adds yet another bar across the top to also indicate page loading progress

I'm sure that using turbolinks is fine for people with fast Internet connections and certain types of websites/browsers, but it's terrible for usability in some scenarios.

(`rails new app --skip-turbolinks`)



Don't throw the baby out with the bathwater maybe? Here's a fixed version of your statement:

"The default Turbolinks progress bar that can be removed with one line of CSS gives the impression that things are slow on slow connections."

Turbolinks is not perfect and has some drawbacks, but it also makes things faster in 99% (100%?) cases in my experience for almost 0 development effort.


I haven't tried out Turbolinks yet, however wouldn't the developer implementing Turbolinks make sure they don't have a progress bar along the top for another purpose first?

I think users would understand it is a loading bar and not a reading progress bar if it only appears after a link is clicked.

Also, if Turbolinks is implemented will Firefox on Android still display a second progress bar?

I ask these questions as I'm thinking of using Turbolinks myself and your comment does make me doubt.


I've used turbolinks in production and it is great. The progress bar is clunky, but it is optional, and not needed anyway if your pages render in a reasonable amount of time (100ms to 200ms is "instant" to most people). I can't really fathom how the parent to your post saw a slowdown using turbolinks - because the server doesn't know the difference, and the client does less work.


Turbolinks is often a terrible user experience. The user doesn't measure page load in seconds, but in the perceived load in seconds. Turbolinks on slow connections feels painful, including on big sites with fast servers, like YouTube and Github.


Can you define what do you mean by slow connection?


I often work at cafes. Sometimes the connections are slow. I sometimes middle-click the links open (new tab) to avoid having to wait for turbolinks.


You know you'll wait the same amount of time, right?


My comment above mentions that. It's about perceived page load time. There are small tricks that sites do to make UIs appear faster, even if they aren't really faster. Turbolinks has the opposite effect, making the loading appear to be worse on bad connections or when there are other rendering problems.


I doubt that people think much when they implement Turbolinks. It's built into rails by default so you have to go out of your way to disable it (--skip-turbolinks).

I think that a loading bar across the top of a web page shouldn't have multiple meanings. For consistent signaling to the user about what the browser is doing, the browser should take care of telling the user what action is being performed (loading).


I guess that Turbolinks is used by Basecamp 2 and it sucks a lot. Search takes seconds to load for me, without any loading feedback.


Turbolinks is also used by Basecamp 3, I assure you.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: