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

Turbolinks: SPA-like Experience without the SPA-framework Hassle

goiabada.blog

Post reply on HN
Print view View original

81–90 of 97 posts

Re: Turbolinks: SPA-like Experience without the SPA-framework Hassle

#81

Post by bruncun »

dcwca wrote: post #80
bruncun wrote: post #66

Earlier quoted context omitted.

Turbolinks evolved from Pjax (4 yrs old) and is part of Ruby on Rails (11 yrs old). Not only does it respect back/reload out of the box, but it also supports native. Its as mature as it is supported as it is powerful. It really just works - drop it into a project and you instantly have a SPA. Its far from a framework - its API has less surface area than even React. The above comment couldn't apply less to Turbolinks.…

The only true caveat is you can’t have multiple dynamic elements per view.

It allows you to do partial updates, but indeed it doesn’t support view transitions out of the box. :/ That said, the native wrappers offer built-in transitions, and you could probably hack web transitions with some modding and a component library.

Re: Turbolinks: SPA-like Experience without the SPA-framework Hassle

#82

Post by the_gastropod »

bruncun wrote: post #66
disconnected wrote: post #19

I know they are trying to promote their own Front-End Framework (while trying to pretend that it isn't one), but with regards to the question on the title, my experience is: you can, but please, don't. It actually isn't THAT hard, but what will happen is that you'll end up reinventing the wheel badly, and you'll be chasing bugs and fixing platform inconsistencies for months. It won't be optimized and it won't work in…

Turbolinks evolved from Pjax (4 yrs old) and is part of Ruby on Rails (11 yrs old). Not only does it respect back/reload out of the box, but it also supports native. Its as mature as it is supported as it is powerful. It really just works - drop it into a project and you instantly have a SPA. Its far from a framework - its API has less surface area than even React. The above comment couldn't apply less to Turbolinks.…

Just to be pedantic: pjax is nearly 7 years old. https://github.com/defunkt/jquery-pjax/commit/3efcc3c968c18c...

Re: Turbolinks: SPA-like Experience without the SPA-framework Hassle

#83

Post by triskweline »

quantumofmalice wrote: post #69

Turbolinks is OK, but I prefer intercooler for HTML-based apps because it gives me a lot more control: https://github.com/LeadDyno/intercooler-js/ I don't use it for everything, but it's great for a lot of my work.

If you're looking for a little more control but don't want to go all-in SPA, also check out Unpoly:

https://unpoly.com/

Re: Turbolinks: SPA-like Experience without the SPA-framework Hassle

#84

Post by sebringj »

libria wrote: post #16

Downvoting everyone answering the title question and not reading the article. You guys should be better than this. It's not about cowboying or NIH. It's about using a library called Turbolinks https://github.com/turbolinks/turbolinks to render static pages server-side and swap the content out with js.

What about click-bait titles?

Re: Turbolinks: SPA-like Experience without the SPA-framework Hassle

#85

Post by owens99 »

dcwca wrote: post #80
bruncun wrote: post #66

Earlier quoted context omitted.

Turbolinks evolved from Pjax (4 yrs old) and is part of Ruby on Rails (11 yrs old). Not only does it respect back/reload out of the box, but it also supports native. Its as mature as it is supported as it is powerful. It really just works - drop it into a project and you instantly have a SPA. Its far from a framework - its API has less surface area than even React. The above comment couldn't apply less to Turbolinks.…

The only true caveat is you can’t have multiple dynamic elements per view.

This is easy to do in Rails on your own. Turbolinks is irrelevant to this.

Re: Turbolinks: SPA-like Experience without the SPA-framework Hassle

#86

Post by owens99 »

deckar01 wrote: post #73
the_gastropod wrote: post #36

Earlier quoted context omitted.

Turbolinks is not a front-end framework. It is a library that has been in Rails for ~5 years. And before that, pjax did basically the same exact thing. This is a pretty battle-tested way of building web applications.

GitLab removed TurboLinks from their site not that long ago. It was the source of a lot of bugs, crufty code, and flakey tests. If you have any JavaScript that modifies the DOM or ever plan to don’t use TurboLinks.

> GitLab removed TurboLinks from their site not that long ago. It was the source of a lot of bugs, crufty code, and flakey tests.

An anecdote is not data.

Re: Turbolinks: SPA-like Experience without the SPA-framework Hassle

#87

Post by owens99 »

cocktailpeanuts wrote: post #68

Actually the first thing I do nowadays when I start a new project using rails is turn off turbolinks. Rails has so many "magic" hidden underneath and Turbolinks is the epitome of this problem. I have no idea how it works, but all I know is it breaks my apps too often if I ever make use of a lot of JavaScript code. Nowadays I do: 1. Pure old school websites with no SPA approach (Surprisingly, most web apps work just f…

Turbolinks isn't that complicated. You should spend a day or two to learn it. Definitely useful in for #1. Depends on what you want to do for #2.

Re: Turbolinks: SPA-like Experience without the SPA-framework Hassle

#88

Post by deckar01 »

pbreit wrote: post #77
deckar01 wrote: post #73

Earlier quoted context omitted.

GitLab removed TurboLinks from their site not that long ago. It was the source of a lot of bugs, crufty code, and flakey tests. If you have any JavaScript that modifies the DOM or ever plan to don’t use TurboLinks.

Shopify went back to Turbolinks: https://shopifyengineering.myshopify.com/blogs/engineering/r...

That article is from 2014, the golden age of TurboLinks. As far as I can tell they are not using it on their main site or any of their white labeled sites anymore.

https://github.com/shopify-graveyard/turbolinks/

Re: Turbolinks: SPA-like Experience without the SPA-framework Hassle

#89

Post by deckar01 »

owens99 wrote: post #86
deckar01 wrote: post #73

Earlier quoted context omitted.

GitLab removed TurboLinks from their site not that long ago. It was the source of a lot of bugs, crufty code, and flakey tests. If you have any JavaScript that modifies the DOM or ever plan to don’t use TurboLinks.

> GitLab removed TurboLinks from their site not that long ago. It was the source of a lot of bugs, crufty code, and flakey tests. An anecdote is not data.

> Turbolinks.clearCache() Removes all entries from the Turbolinks page cache. Call this when state has changed on the server that may affect cached pages.

https://github.com/turbolinks/turbolinks#turbolinksclearcach...

This is a nightmare. You will eventually miss a cache invalidation and break browser navigation or invalidate the cache so aggressively that TurboLinks is serving no purpose.

You don't need lots of negative testimonials to see that managing your own client side cache with JavaScript is a bad idea.

Re: Turbolinks: SPA-like Experience without the SPA-framework Hassle

#90

Post by cocktailpeanuts »

toasterlovin wrote: post #75
cocktailpeanuts wrote: post #68

Actually the first thing I do nowadays when I start a new project using rails is turn off turbolinks. Rails has so many "magic" hidden underneath and Turbolinks is the epitome of this problem. I have no idea how it works, but all I know is it breaks my apps too often if I ever make use of a lot of JavaScript code. Nowadays I do: 1. Pure old school websites with no SPA approach (Surprisingly, most web apps work just f…

As a counterpoint, Turbolinks has been an unmitigated success for a huge app that I work on. 80% of the performance and responsiveness of an SPA with about 5% of the work. Granted, the app is very vanilla-Rails. I can see Turbolinks getting in the way if you have a bunch of other "complicated" Javascript, but if your app is mostly standard Rails views plus some jQuery, Turbolinks is an amazing hack.

Yes, but my point was that if I want my app to be "vanilla rails with jQuery" (which actually is all you need for most web apps), I actually WANT it to behave like a "website", meaning I DON'T want it to behave like a single page app because it's confusing both for users and the developer (myself), which is where turbolinks comes in.
Post reply on HN