Question: why is v3.0 not out yet?

[rstacruz]

It seems very useful and long-overdue especially with the changes to the progressbar and Turbolinks.replace.

[Thibaut]

The plan is to release Turbolinks 3 at the same time as Rails 5. @rafaelfranca is that still correct?

There are a couple more things I want to add/change before we cut a release. I'll try to get them done in the coming weeks.

[rafaelfranca]

We don't need to tie Turbolinks 3 with Rails 5. If it is feature done and stable enough we can release it before Rails 5.

A problem would be a change to Rails that could break turbolinks like was the change in the response that I fixed last week. I don't believe we are using any more internal method that could break but if we want to be safe, better to wait the Rails 5 beta

[dhh]

I think we should just release Turbolinks 3 now. Turbolinks 5 is a complete rewrite and will be the version we'll be bundling with Rails 5. There are some backwards compatibility issues, though, so we shouldn't hardcode a 5+ dependency. Very likely that someone upgrading an existing app to Rails 5 will want to continue using TL3. But new, from-scratch, apps should use TL5.

We'll finish the extraction from Basecamp 3 along with the native wrappers for iOS and Android. That was the big driver for TL5. Needing more hooks and more control to make the native experience perfect.

[javan]

For reference, TL5: https://github.com/basecamp/turbolinks

@Thibaut, hoping we can set up a time to chat about it in the near future.

[jeremy]

TL3 offers major new features that TL5 immediately removes. That's a rocky road that doesn't offer clear landmarks. Where are we headed? Should we release TL3 or revise it to point toward TL5?

[rafaelfranca]

Should we release TL3 or revise it to point toward TL5?

If that is the case I'd say we should revise it to point toward TL5

[Thibaut]

If TL5 is to be included in Rails 5 then I agree there's no point in releasing TL3, except maybe as a separate gem (if there's demand for it).

It's a bit unfortunate that TL5 diverged significantly from TL3 without a heads up here — there are bug fixes in TL3 that I don't see in TL5, no test suite in TL5, and many people will be disappointed that partial replacement is gone :/

Looking forward to seeing the iOS/Android integration, though.

@javan happy to chat on BC3, or Hangout on the weekends.

[jeremy]

@Thibaut Yes indeed. Best to huddle up and discuss the motivation behind the ground-up rework. It was driven by pressures exposed by iOS/Android integration.

/cc @sstephenson @packagethief

[justin808]

FWIW, I really need the 3.x version of Turbolinks due to the need for the script option of data-turbolinks-eval=always.

I need it for this PR: https://github.com/shakacode/react_on_rails/pull/104

I'm guessing there is no simple workaround without going to v3 for this functionality.

So here's my vote for releasing v3!

[rstacruz]

I guess at the very least, the current state can be released as v3.0.0-pre1.

[dhh]

I think there's a compelling argument that 3.0 isn't going to be released, given that 5.0 is close at hand, and it changes the API in significant ways.

But, hey, it's just code. If the current state of this repo serves your needs, you don't need any official blessing from anyone to use it. You can use it as-is, you can fork, you can do whatever you want. MIT baby!

On Tue, Nov 17, 2015 at 12:03 PM, Rico Sta. Cruz notifications@github.com wrote:

I guess at the very least, the current state can be released as v3.0.0-pre1.

— Reply to this email directly or view it on GitHub https://github.com/rails/turbolinks/issues/628#issuecomment-157338292.

[TheNeikos]

So if I understood correctly partial replacement will not be included in the official release (with Rails 5)?

[gregblass]

Blah. Hopefully Rails 5 drops soon because it seems like some good issues that I've opened here are being ignored (I understand why now).

[nateberkopec]

https://github.com/basecamp/turbolinks looks fairly up-to-date. Now that Rails 5.0.0.beta1 is out, is there any update on the release plans or schedule for Turbolinks 5?

FWIW, I think it would be nice if TL3 was forked and released. I think a lot of people would find it useful, and the fork should live on for at least as long as it's feature set (like partial replacement) can be added to TL5.

[dhh]

We are working on getting TL5 ready for release. Since it changes a lot of things we need new documentation and more.

We don't have a current plan to add partial replacement from TL3 to TL5. It may be possible in the future but its not in the cards now. So releasing TL3 with a feature set that's not available in TL5 doesn't make a lot of sense. On Dec 30, 2015 02:48, "Nate Berkopec" notifications@github.com wrote:

https://github.com/basecamp/turbolinks looks fairly up-to-date. Now that Rails 5.0.0.beta1 is out, is there any update on the release plans or schedule for Turbolinks 5?

FWIW, I think it would be nice if TL3 was forked and released. I think a lot of people would find it useful, and the fork should live on for at least as long as it's feature set (like partial replacement) can be added to TL5.

— Reply to this email directly or view it on GitHub https://github.com/rails/turbolinks/issues/628#issuecomment-167915897.

[mintuhouse]

We are just getting started with adding turbolinks back to our rails 4.1 application. Is it recommended to use the TL5 or TL3 ? If we go ahead with TL5, can I safely use the 2.5-stable README for supported API or has the underlying core API changed after adding the hybrid support?

[dhh]

Hasan, I would start with TL5 if you're working on something new. The core API has changed entirely, though (hence the big version leap). We're working on adding that documentation now.

On Thu, Jan 14, 2016 at 10:12 AM, Hasan Kumar Reddy A < notifications@github.com> wrote:

We are just getting started with adding turbolinks back to our rails 4.1 application. Is it recommended to use the TL5 https://github.com/basecamp/turbolinks/tree/v5 or TL3 https://github.com/rails/turbolinks/tree/master ? If we go ahead with TL5, can I safely use the 2.5-stable https://github.com/basecamp/turbolinks/tree/2-5-stable README for supported API or has the underlying core API changed after adding the hybrid support?

— Reply to this email directly or view it on GitHub https://github.com/rails/turbolinks/issues/628#issuecomment-171580925.

[mintuhouse]

Thanks DHH for taking time to respond immediately. Using turbolinks v5 then.

[inchr]

Honestly I don't like the idea that many contributors here has worked for free on TL3 and now TL5(that will be default in rails5) has a totally different API. Btw @dhh : what is changed in TL5 ? where we can see the new APIs ? what are the advantages ? In what is better than TL3 ?

Why the choice of remove the partials ? (technocally speaking...the partial changes were very useful for change only little pieaces of the app, how you can get the same performances with TL5 ?)

PS: I really appreciate the work done on TL3/5 - I'm only a bit worried that in this way(TL5 that has a totally different API, when TL3 is still not released), people will think that turbolinks is not a valid/solid project for a new webapp. PS2: Any links/guide for turbolinks5 new api ?

[inchr]

@dhh It's still possible do something like this: render :index, change: "todos" in turbolinks5 ?

[dhh]

TL3 still exists in this repo. The work isn't being burned at the stake. If you want to use this version of Turbolinks, you're completely free to do so. The work is even MIT, so if you want to further develop this branch, that's also possible. That's the wonder of OSS!

TL5 is a rewrite for two reasons: 1) To better accommodate native iOS and Android wrappers by giving them access to the relevant points in the lifecycle of a request. This was the driving use case. 2) To facilitate #1, it turned out to be easier to do a rewrite rather than a patch. And to be frank, the code base needed it anyway. The new code base is far cleaner. TL isn't an enormous framework, so does this as a rewrite as completely feasible.

TL3 was never released, so the only people who've used it were those active involved with the development or extra adventurous souls. A small group compared to the people using TL2!

Partial replacement turned out to be a feature I didn't really think lived up to the promise, at least not with the current implementation. data-permanent was, imo, 95% of the value, and that feature is present in TL5. For other cases where you just need to change a small part of the page, doing things via ajax is in my opinion the better way for now. But that just describes our use case. There may well be other use cases where it works better.

So TL5 is going to ship without partial replacement, beyond the permanent marker, and we can consider adding that back in via a plugin or directly, but that's a secondary priority.

We're working on wrapping up documentation, testing, and the native wrappers for TL5 to coincide with Rails 5 final.

[inchr]

Just to be clear: I really appreciate the work that you/rails core team/basecamp team do with rails/turbolinks. I appreciate also the work of the contributors of this branch.

Btw: few comments above, you've suggested to use turbolinks5+rails5 for a new project...but there is any doc/readme/example/blog post about turbolinks5 ? I'm really interested to try it for a new project.

I was justing thinking that a good alternative for partial replacement, is do a simple ajax request, and reply with a create.js.coffee for example(RJS) and from there, render the new partials, where you want. What you think ? it's a good idea ?

[dhh]

Yes, at this time, you're going to have to dig into the source of Turbolinks 5. It really isn't too bad. It's not that long. But it's a bigger hill to climb than reading a baked tutorial.

That's exactly what I'd recommend. Use SJR when you just need to change one little part of the page. Use Turbolinks with the permanent tag for the majority of page changes where you want to change everything except a stable navigation bar or shopping cart or whatever.

Best of luck!

On Mon, Jan 18, 2016 at 3:52 PM, inchr notifications@github.com wrote:

Just to be clear: I really appreciate the work that you/rails core team/basecamp team do with rails/turbolinks. I appreciate also the work of the contributors of this branch.

Btw: few comments above, you've suggested to use turbolinks5+rails5 for a new project...but there is any doc/readme/example/blog post about turbolinks5 ? I'm really interested to try it for a new project.

I was justing thinking that a good alternative for partial replacement, is do a simple ajax request, and reply with a create.js.coffee for example(RJS) and from there, render the new partials, where you want. What you think ? it's a good idea ?

— Reply to this email directly or view it on GitHub https://github.com/rails/turbolinks/issues/628#issuecomment-172550209.

[inchr]

Ok! I will read the turbolinks5 code!

You're right...with SJR, it's not a big deal don't have partials replacement from controllers.

Thanks!

[gregblass]

Makes sense to me @dhh!

I think I speak for a large part of the Rails community in that we'd love to hear more about how basecamp implemented native iOS and Android wrappers (@sstephenson - https://twitter.com/sstephenson/status/687667917341642752).

I've been searching for resources on how to learn about something like this, but have found nothing. I think the fact that you guys pulled that off is a huge deal and would be a game changer for tons of people.

To get truly native feeling navigation for my rails app for mobile, I've been learning Ionic/Angular and how to use Rails as an API. It does the job but its an incredible amount of work for a small team. Angular seems like overkill to me. I am not looking forward to rewriting my whole Rails codebase to use an API.

Maybe a youtube demonstration like you did for ActionCable, or a Signal vs. Noise post? Or, were there any resources that helped your team understand how to build it?

My gut instinct tells me this isn't something that can be explained in a blog post, and that is why you hire swift and java guys :( But I really don't know!

[dhh]

Greg, that's exactly the motivation for Turbolinks 5! To provide an alternative path to client-side (native or JS) implementations for that which can be just as well served by Turbolinks. Which in the case of Basecamp 3 turned out to be most of it! That's why we're so excited about the TL5 approach. It really is a major breakthrough in productivity for people who have to build apps that do both web and native at the same time.

We're readying the documentation for TL5. We're getting the native wrappers polished. Sam is intending to deliver a presentation at RailsConf about it all. We'll get all the information out there!

On Mon, Jan 18, 2016 at 4:56 PM, Greg Blass notifications@github.com wrote:

Makes sense to me @dhh https://github.com/dhh!

I think I speak for a large part of the Rails community in that we'd love to hear more about how basecamp implemented your native iOS and Android wrappers (@sstephenson https://github.com/sstephenson - https://twitter.com/sstephenson/status/687667917341642752).

I've been searching for resources on how to learn about something like this, but have found nothing. I think the fact that you guys pulled that off is a huge deal and would be a game changer for tons of people.

To get truly native feeling navigation for my rails app for mobile, I've been learning Ionic/Angular and how to use Rails as an API. It does the job but its an incredible amount of work for a small team. Angular seems like overkill to me. I am not looking forward to rewriting my whole Rails codebase to use an API.

Maybe a quick youtube like you did for ActionCable, or a Signal vs. Noise post? Or, do you have any resources you could offer that helped your team understand what was required to roll that out?

My gut instinct tells me this isn't something that can be explained in a blog post, and that is why you hire swift and java guys :( But I really don't know!

— Reply to this email directly or view it on GitHub https://github.com/rails/turbolinks/issues/628#issuecomment-172568846.

[aantix]

@dhh Are you planning on open sourcing a generic version of the iOS and Android apps that wrap these web views?

[dhh]

Jim, yep! We want to supply the whole toolkit that enables people to build hybrid apps like Basecamp 3 with Turbolinks.

On Mon, Jan 18, 2016 at 5:06 PM, Jim Jones notifications@github.com wrote:

@dhh https://github.com/dhh Are you planning on open sourcing a generic version of the iOS and Android apps that wrap these web views?

— Reply to this email directly or view it on GitHub https://github.com/rails/turbolinks/issues/628#issuecomment-172571196.

[gregblass]

Amazing. This is a huge game changer. Very excited! Thanks @dhh!

[dhh]

Lest I over-promise: What we've developed is a wrapper around the web views for both Android and iOS that makes them work well with Turbolinks. Including all the animations for back/forward etc. This does not mean you'll get an app like Basecamp 3 without knowing how to do iOS or Android development.

On Mon, Jan 18, 2016 at 5:10 PM, Greg Blass notifications@github.com wrote:

Amazing. This is a huge game changer. Very excited! Thanks @dhh https://github.com/dhh!

— Reply to this email directly or view it on GitHub https://github.com/rails/turbolinks/issues/628#issuecomment-172572866.

[gregblass]

Gotcha, understood - I'm definitely looking forward to learning, and understand that native wrappers means actually writing swift and java. This doesn't scare me, and it still seems like a better approach than refactoring an entire app to use an API and a JS framework. I think an overview of how you guys did it would be tremendous for the community and will open up tons of blog posts and support around the concept. Should make for some really interesting twitter arguments to say the least.

[dhh]

I've blogged about the general approach in the past: https://blogcabin.37signals.com/posts/3743-hybrid-sweet-spot-native-navigation-web-content

But yeah, still a bunch of work to do to outline the technical aspects in detail.

On Mon, Jan 18, 2016 at 5:24 PM, Greg Blass notifications@github.com wrote:

Gotcha, understood - I'm definitely looking forward to learning, and understand that native wrappers means actually writing swift and java. This doesn't scare me, and it still seems like a better approach than refactoring an entire app to use an API and a JS framework. I think an overview of how you guys did it would be tremendous for the community and will open up tons of blog posts and support around the concept. Should make for some really interesting twitter arguments to say the least.

— Reply to this email directly or view it on GitHub https://github.com/rails/turbolinks/issues/628#issuecomment-172576467.

[dhh]

We'll be releasing Turbolinks 5.0.0.beta1 today. Along with it is a new organization on GitHub to hold all the repos as well as a FAQ answering why the rewrite. Have a look: https://github.com/turbolinks/turbolinks

[dhh]

Plan remains to release Turbolinks 5.0.0.final alongside Rails 5.0.0.final together with the iOS and Android wrappers and documentation.

[dhh]

Note: As part of Turbolinks 5, we're going to move this repo to turbolinks/turbolinks-classic. So all the work is still available. It'll just live within the new turbolinks organization on GitHub.

[sgrif]

Should this issue be closed? It sounds like turbolinks 3 isn't being released

[dhh]

Correct. Was just keeping it open to inform everyone what was going on until we had the repos setup.

[inchr]

Just for information: @dhh is right(again). I'm developing a new project(for now it's still rails4+turbolinks3...but I guess, it will be very easy to migrate to rails5+turbolinks5) with turbolinks and SJR and it's great!

The partial replacement done from controllers was totally useless and I don't miss it! So don't worry for losing this feature and embrace SJR!