I'd love to see what this is like using https://mrujs.com .  I've migrated some projects over to it and aside from event handlers it's been a no-brains drop-in for RailsUJS.

I'm very much a beginner so maybe I'm not seeing the advantages; but I don't see how this is better. Lots of code in lots of places to accomplish what is a given in standard rails.

 ☒ Turbo is essentially the replacement for Turbolinks so changes will be coming in the future. We don't know what that quite looks like yet, but there will be changes coming. As time goes on, I don't know what will become of Rails UJS either. There's a lot of unknowns right now, but this episode was looking to help demystify some of the issues with creating a new Rails application without Webpacker and seeing how things work with Hotwire.

David Kimura First of all I should thank you for your videos and for pushing the envelope so the issues can be understood. Also helps to know not to jump into shiny new toys too quickly, particularly since Rails seems to be transitioning.

I have a small app that had sat for a year and then about two years ago I took it up again and decided to update to Rails 6 and Webpacker. Which was probably a mistake (particularly in hind sight).

Thanks again

I've devoted countless hours to understand Webpacker and migrate most of my projects. 
Now, I'm comfortable with it. 
But, when need to change something (maybe 10 minutes of work in the backend-ruby part) in a project not touched in months, there is a lot of problems in the "yarn part": Lots of deprecation complaints, need to investigate which part is failing ... one or two hours later, project is working again.
When looking to rails 4 happy times with Coffeescript and sprockets where asset pipeline just worked ... I'm not sure if we have better or worst framework nowadays.

I feel your pain  ☒ . It is especially frustrating when all of this is getting ran in a docker container where the same version of things (ruby, node, yarn) haven't changed. I agree with the whole Rails 4 aspect of things where it was just simple and works, but at the same time, I feel like my JS was in a much worse way in terms of organization. It wouldn't be uncommon that one js file would end up conflicting with another. To mitigate that we did page specific javascript, but that had its own complications. I don't know what the right solution will be, but I'd love something that gave us best of both worlds.

Another option that mimics the HTML response is to send the same format.html redirect within the turbo_stream block, along with a status of "303 See other". (Of course, you'll give up the magic of removing the DOM element in place and you'll reload the entire page.)

Here are the relevant threads:

https://github.com/hotwired/turbo/issues/84
https://github.com/hotwired/turbo/issues/320

So, just copy the format.html and add status: 303, which will remove the DELETE verb from the redirect ...

  respond_to do |format|
    format.html { redirect_to products_url, notice: "Product was successfully destroyed." }
    format.json { head :no_content }
    format.turbo_stream { redirect_to products_url, notice: "Product was successfully destroyed.", status: 303 }
  end

This is a small thing, but ... if you always want the destroy link to perform the #confirm action every time (and I do), you can instead set the action in the Stimulus controller  with:

// confirmation_controller.js
  connect() {
    this.element.dataset.action = "confirmation#confirm"
  }

That allows us to drop the one line from the link in views/products/index.html.erb, so the data looks like:

data: {
        "turbo-method": :delete,
        controller: "confirmation",
        "confirmation-message-value": 'Are you sure?'
      }

Thanks for sharing  ☒ 

The confirm pop-up doesn't work for me

For the confirm, data-tubo-confirm is now supported so:

data: { "turbo-method": :delete, "turbo-confirm": "Are you sure?" }