Hotwire and a few analogues (e.g. LiveView for Phoenix) are an emerging design pattern.

I think for a lot of business cases they are going to replace js frameworks. They are domain specific (Rails, Phoenix, etc..), but they allow you to essentially replace a lot of SPA functionality with a library that takes an afternoon to grok for a back-end dev.

They won't replace React, Vue, etc... But they can replace it in places where a full js framework is overkill (which is probably a majority of the places that I see it).

As a backend dev, I think that they have incredible promise. They make interactivity MUCH easier.

Hotwire is just a name for a bunch of tech that has been around for a while. The components of Hotwire - Turbo and stimulus - have improved over time, for sure, but the core ideas haven't changed much, if at all. I worked on a hotwire side project recently and described it to a friend as "writing Rails like it was 2009." It feels really good because I've always found it hard to grok SPAs and the like, but could generate tolerable server-side generated webapps.

Old wine in a new bottle, basically.

It's a tiny lib that replaced turbolinks from DHH and the gang. It's used for many prod deployments and it's pretty convenient for people who do not enjoy FE SPA style dev. There are obviously other options.

Hotwire is not really a skill. It's a tiny lib that lets your old school server rendered app feel like an SPA. There are obviously other options for your serverside code you can use c if it's up your alley.

To be fair in Go's case, it came to prominence at or before the time many of us started. And the Go I learned at the very start of my career (10 years ago) is still usable today.