Question: why is v3.0 not out yet? #628

Closed
rstacruz opened this Issue Nov 2, 2015 · 38 comments

Projects

None yet
@rstacruz
rstacruz commented Nov 2, 2015

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

@Thibaut
Collaborator
Thibaut commented Nov 2, 2015

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
Contributor

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
Contributor
dhh commented Nov 2, 2015

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
Member
javan commented Nov 2, 2015

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
Member
jeremy commented Nov 3, 2015

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
Contributor

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
Collaborator
Thibaut commented Nov 4, 2015

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
Member
jeremy commented Nov 4, 2015

@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

@glennfu glennfu referenced this issue in ssorallen/turbo-react Nov 7, 2015
Closed

Edge Turbolinks disables turbo-react #24

@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: shakacode/react_on_rails#104

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

So here's my vote for releasing v3!

@justin808 justin808 referenced this issue in shakacode/react_on_rails Nov 17, 2015
Closed

Add data-turbolinks-eval always to script tags #104

@rstacruz

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

@dhh
Contributor
dhh commented Nov 17, 2015

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
#628 (comment).

@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
Contributor
dhh commented Dec 30, 2015

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
#628 (comment).

@markets markets referenced this issue in coopdevs/timeoverflow Jan 11, 2016
Merged

New Tagging system #181

@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?

@mintuhouse mintuhouse referenced this issue in rstacruz/onmount Jan 14, 2016
Closed

Doesn't work with latest turbolinks #47

@dhh
Contributor
dhh commented Jan 14, 2016

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
#628 (comment).

@mintuhouse

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

@inchr
inchr commented Jan 18, 2016

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
inchr commented Jan 18, 2016

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

@dhh
Contributor
dhh commented Jan 18, 2016

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
inchr commented Jan 18, 2016

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
Contributor
dhh commented Jan 18, 2016

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
#628 (comment).

@inchr
inchr commented Jan 18, 2016

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
Contributor
dhh commented Jan 18, 2016

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
#628 (comment).

@aantix
aantix commented Jan 18, 2016

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

@dhh
Contributor
dhh commented Jan 18, 2016

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
#628 (comment).

@gregblass

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

@dhh
Contributor
dhh commented Jan 18, 2016

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
#628 (comment).

@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
Contributor
dhh commented Jan 18, 2016

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
#628 (comment).

@dhh
Contributor
dhh commented Feb 2, 2016

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
Contributor
dhh commented Feb 2, 2016

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
Contributor
dhh commented Feb 2, 2016

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
sgrif commented Feb 5, 2016

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

@dhh
Contributor
dhh commented Feb 5, 2016

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

@dhh dhh closed this Feb 5, 2016
@inchr
inchr commented Feb 9, 2016

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment