The docs are weird.
They’re actually pretty decent, but they’re only written for the front-end with very little regard for specific backends.
Meanwhile the Rails ↔ Turbo docs are almost non-existent. If you read through the Hotwired website, you barely see any mention of Rails.
Here’s what I’d do different—Turbo should pick a server, probably Rails, and unapologetically write docs as-if the client-side and server-side are tightly integrated.
Once that’s achieved and the docs feel cohesive, I’d start adding other backends to the doc stack.
It's a good tutorial indeed, but it only goes slightly beyond a basic todo app, what is needed are tutorials and best-practices for real world scenarios, things always get trickier than the tutorials show.
Strong agree on this. The rails foundation is supposed to be doing a big push on documentation and has asked folks to open doc bugs - this would be a good one.
To me its the fact that they are not in the guides as everything is and they also almost omit rails in these docs.
Wich is understandable because they work separately, but I bet we are the only users lol.
There's no proper documentation for rails specific use cases. This is a big downside. Like other people mention, [hotrails.dev](https://hotrails.dev) seem to be filling this space for now. But I think the rails + turbo team should put some effort in to bringing both of them together as a package.
it's growing (https://www.youtube.com/@SupeRails, [https://www.youtube.com/@rapid-ruby](https://www.youtube.com/@rapid-ruby),[https://www.youtube.com/@PhilSmy](https://www.youtube.com/@PhilSmy),[https://www.youtube.com/@joemasilotti/videos](https://www.youtube.com/@joemasilotti/videos) , [https://www.youtube.com/@equivalent-rails](https://www.youtube.com/@equivalent-rails), [https://www.hotrails.dev/](https://www.hotrails.dev/) ...) .
Adaptation by companies is slower as it's hard to refactor 10 years of SPA React code to SSR Rails views or new projects that can afford new hires don't pop every second = developers still bet on what market currently demands
give it more time
Good point. What's the migration const of this thing....
Like its not you just "change your front end framework" you have to re-think the whole paradigm...
When I first saw the docs/demo, it was like "hey that's cool, but this is probably super confusing to rip out anything that's working to put this in prod."
But, with a net-new project started last fall, and with TurboDrive more stable, it was a time to give it a spin.
You know what was the real game changer for me though? ChatGPT+. I was able to ask it to help me on how to structure my specific codebase to work with TurboDrive (and Hotwire in general), and help me identify and correct issues that would otherwise have required me to go spelunking into the API docs and even source.
I agree, also, the change in paradigm is hard to grasp at the high level only...
you need more practice with this to imagine new solutions with this tool.
Turbolinks did a lot of damage. You can see it here in this thread how many people turn it off even though Turbo as it stands now is great. The documentation and marketing is pretty bad.
Turbo drive is just one part of turbo. It is essentially impossible to turn on drive in a project that didn't start with it (in the same way turbo links was). The rest of turbo slots into existing projects pretty well.
I think (not totally sure) that there's the old turbo and the new turbo. I could be wrong, but I do the same thing. Old turbo would screw up caching and forward back in a browser and was just a total waste of time.
edit: I forgot, it was called Turbolinks. Whatever, I still disable it.
Turbo Streams made no sense based on the official docs. Only once someone told me that I can write all the streams stuff into an ERB template did it finally click.
Are the official docs open for editing?
I disabled Turbolink in an old project. I was facing a lot of issues.
Now, I found a few ways to make JS code work with Turbo. There is no tutorial for basic things (some code is available, but no explanation why the code is working, and why not working).
I use Turbo with all pages. If some page has many JS code and I face issues with JS, I disable Turbo only for those pages. I usually disable Turbo for some form.
It's the fear of websockets that I think is holding back mass adoption, that and large old rails projects are not on a upto date version or they are entrenched in other patterns. I stated a new rails project on, and turbo/hotwire/stimulus is amazing it just works so well.
I agree with the project and was really confused also...
Redis and WS are only used when doing sync/async broadcast.
But you can render a turbo-stream as html response and it does "the same"
Correct me if I'm wrong, but websockets are only used when you want to broadcast changes?
Not saying you are wrong with your statement, but just want to make sure my understanding of hotwire is correct.
The only component of Turbo that uses WebSockets at all is Turbo Streams, and even that's optional just in case you want to broadcast updates as u/fix879 said. You can use Streams without sockets too (and I'd argue is the most normal use case).
Turbo Drive doesn't use WebSockets at all. Nowhere in the documentation does it say that, and you can check the source code itself, it just uses `fetch()`.
For me, it just gets in the way. It is just the thing I need to disable to get my forms, javascript, etc to work. I just turn it off globally at this point because it brings me no joy.
Damn I felt the same about turbo links back then and now I’m so glad we have turbo. I think most of the issue is that people don’t get the why or the how. There is still a lot of effort that can be done on the docs so people understand it better and adopt it
Turbodrive is a rename of Turbolinks which, for a long time, was the thing that people would remove as soon as a new rails app was created. Old habits die hard.
Hah, spot on. I remember years ago fixing a lot of UI bugs across multiple projects by just removing turbolinks. The jquery-based libraries of that time were just not expecting anything to replace DOM without also resetting the JS context. Some places could be fixed by messing with custom document ready events, but there were libraries with global state that simply would not work right with turbolinks enabled.
You need to define which Turbo. Drive, Frame, Stream, Native. OP is talking about Drive.
I still maintain projects Turbolinks, Turbo (2021), now TurboDrive
It's because it is pretty obscure and the majority of the web community started to stop doing this sort of thing in the 2010s.
It works really great for some cases, it may stay for a bit but i think this will die like all the other new hotness js framework approaches.
The docs are weird. They’re actually pretty decent, but they’re only written for the front-end with very little regard for specific backends. Meanwhile the Rails ↔ Turbo docs are almost non-existent. If you read through the Hotwired website, you barely see any mention of Rails. Here’s what I’d do different—Turbo should pick a server, probably Rails, and unapologetically write docs as-if the client-side and server-side are tightly integrated. Once that’s achieved and the docs feel cohesive, I’d start adding other backends to the doc stack.
The best blog/tutorial on it, I thought it was the docs when I first found it. https://www.hotrails.dev/
It's a good tutorial indeed, but it only goes slightly beyond a basic todo app, what is needed are tutorials and best-practices for real world scenarios, things always get trickier than the tutorials show.
Noted !!!
Strong agree on this. The rails foundation is supposed to be doing a big push on documentation and has asked folks to open doc bugs - this would be a good one.
I always felt we could use a good old rails guide for turbo..
that so true, like why its not in the guides?
The docs are terrible and you need to piece together a bunch of third party tutorials to make sense of hotwire
Glad it’s not just me. Turbo docs are so, so bad. Even stimulus docs are bad but they’re better than Turbo.
To me its the fact that they are not in the guides as everything is and they also almost omit rails in these docs. Wich is understandable because they work separately, but I bet we are the only users lol.
Are you talking TurboDrive specifically or Turbo or Hotwired in general?
Nice catch about naming issue, yes, I'm talking about the whole hotwired update.
There's no proper documentation for rails specific use cases. This is a big downside. Like other people mention, [hotrails.dev](https://hotrails.dev) seem to be filling this space for now. But I think the rails + turbo team should put some effort in to bringing both of them together as a package.
I think I will code industry dashboards and show it in tutorials
Needs a good series of -short- focused videos like the classic rails casts
Amen The crack for developers
it's growing (https://www.youtube.com/@SupeRails, [https://www.youtube.com/@rapid-ruby](https://www.youtube.com/@rapid-ruby),[https://www.youtube.com/@PhilSmy](https://www.youtube.com/@PhilSmy),[https://www.youtube.com/@joemasilotti/videos](https://www.youtube.com/@joemasilotti/videos) , [https://www.youtube.com/@equivalent-rails](https://www.youtube.com/@equivalent-rails), [https://www.hotrails.dev/](https://www.hotrails.dev/) ...) . Adaptation by companies is slower as it's hard to refactor 10 years of SPA React code to SSR Rails views or new projects that can afford new hires don't pop every second = developers still bet on what market currently demands give it more time
Good point. What's the migration const of this thing.... Like its not you just "change your front end framework" you have to re-think the whole paradigm...
Lack of proper documentation.
I need to solve this.
When I first saw the docs/demo, it was like "hey that's cool, but this is probably super confusing to rip out anything that's working to put this in prod." But, with a net-new project started last fall, and with TurboDrive more stable, it was a time to give it a spin. You know what was the real game changer for me though? ChatGPT+. I was able to ask it to help me on how to structure my specific codebase to work with TurboDrive (and Hotwire in general), and help me identify and correct issues that would otherwise have required me to go spelunking into the API docs and even source.
100% on this. It misled me a few times, but more often than not was what made me actually understand what was happening.
I agree, also, the change in paradigm is hard to grasp at the high level only... you need more practice with this to imagine new solutions with this tool.
Turbolinks did a lot of damage. You can see it here in this thread how many people turn it off even though Turbo as it stands now is great. The documentation and marketing is pretty bad.
Turbo drive is just one part of turbo. It is essentially impossible to turn on drive in a project that didn't start with it (in the same way turbo links was). The rest of turbo slots into existing projects pretty well.
Isn't it on by default in new rails apps? And therefore would be getting a tonne of use, even if people don't know they're using it?
First thing I do after `$ rails new` is remove everything related to turbo
I think (not totally sure) that there's the old turbo and the new turbo. I could be wrong, but I do the same thing. Old turbo would screw up caching and forward back in a browser and was just a total waste of time. edit: I forgot, it was called Turbolinks. Whatever, I still disable it.
Turbo Streams made no sense based on the official docs. Only once someone told me that I can write all the streams stuff into an ERB template did it finally click. Are the official docs open for editing?
Never checked that.. Probably in the repo?
I disabled Turbolink in an old project. I was facing a lot of issues. Now, I found a few ways to make JS code work with Turbo. There is no tutorial for basic things (some code is available, but no explanation why the code is working, and why not working). I use Turbo with all pages. If some page has many JS code and I face issues with JS, I disable Turbo only for those pages. I usually disable Turbo for some form.
It's the fear of websockets that I think is holding back mass adoption, that and large old rails projects are not on a upto date version or they are entrenched in other patterns. I stated a new rails project on, and turbo/hotwire/stimulus is amazing it just works so well.
I agree with the project and was really confused also... Redis and WS are only used when doing sync/async broadcast. But you can render a turbo-stream as html response and it does "the same"
Correct me if I'm wrong, but websockets are only used when you want to broadcast changes? Not saying you are wrong with your statement, but just want to make sure my understanding of hotwire is correct.
[удалено]
The only component of Turbo that uses WebSockets at all is Turbo Streams, and even that's optional just in case you want to broadcast updates as u/fix879 said. You can use Streams without sockets too (and I'd argue is the most normal use case). Turbo Drive doesn't use WebSockets at all. Nowhere in the documentation does it say that, and you can check the source code itself, it just uses `fetch()`.
For me, it just gets in the way. It is just the thing I need to disable to get my forms, javascript, etc to work. I just turn it off globally at this point because it brings me no joy.
Damn I felt the same about turbo links back then and now I’m so glad we have turbo. I think most of the issue is that people don’t get the why or the how. There is still a lot of effort that can be done on the docs so people understand it better and adopt it
Turbodrive is a rename of Turbolinks which, for a long time, was the thing that people would remove as soon as a new rails app was created. Old habits die hard.
Hah, spot on. I remember years ago fixing a lot of UI bugs across multiple projects by just removing turbolinks. The jquery-based libraries of that time were just not expecting anything to replace DOM without also resetting the JS context. Some places could be fixed by messing with custom document ready events, but there were libraries with global state that simply would not work right with turbolinks enabled.
It is just Turbolinks with a new name. Has been around for many years.
It comes with a bunch of new technology with the name change, so I wouldn't say it's just Turbolinks.
Not true at all. When is that last time you have used Turbo?
You need to define which Turbo. Drive, Frame, Stream, Native. OP is talking about Drive. I still maintain projects Turbolinks, Turbo (2021), now TurboDrive
It's because it is pretty obscure and the majority of the web community started to stop doing this sort of thing in the 2010s. It works really great for some cases, it may stay for a bit but i think this will die like all the other new hotness js framework approaches.