I understand the references, and maybe its that I work in robotics and not web dev. But if the criticism of web dev is that domain knowledge erodes unlike law or medicine, the response shouldn't be that long term stable skills exist such as these two things that have come into prominence in the last decade in go's case, and the last year? in hotwires case
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.
fair, I might give it a look if I ever need to create web project. I think ultimately the critique is still valid though. At least in robotics, new knowledge is typically complimentary of existing knowledge. My ML projects don't negate my knowledge of control theory, physics, operating systems, embedded computer architecture, etc.
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.
I'm pretty up-to-date on front-end developments but Hotwire is barely on my radar, so I had to look up the release date, but it seems to have been released just this year? (I thought it was last year.)
Though my stack has certainly evolved, it's been mostly the same since 2016, with really not that much new to learn. Adopting something released just this year doesn't seem like the most obvious choice when looking for a stable stack.
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.
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.
