Hi there ; I'm the author of the talk linked in the article.
Technically you're not missing anything: htmx is nothing more than another turbolinks, maybe more flexible and easier to learn.
What you might be missing is the non-technical implications of these new tools. The idea behind the talk (and behind htmx, and behind turbolinks, or unpoly) is to prove that the usual arguments for Javascript application frameworks are just not valid for 90% of use cases. And *that's* a complete game-changer, even an industry-changer.
Because since 2016, every small-and-not-super-rich company that wants to create a rich UX on the web is told to hire at least 2 developers: one "front-end" (i.e. "JS"), and one "backend-end" (i.e. everything else, from API to hosting through domain stuff and user data). Or one superman with both back-end and React skills, which is, IMO, almost impossible.
From what I've seen, what businesses need is, indeed, 2 devs: one "back-end" (i.e. workers, databases, user data, domain stuff, and even hosting), and one "front-end" (i.e. "the website", from DB queries to CSS). One person should be enough to address this second scope, even with complex UIs and rich UX. And as this is almost impossible with Javascript application frameworks (because they require a lot of work), it becomes possible again, like in 2008, with htmx/hotwired/unpoly (and without the spaghetti code we had in 2008).
One more thing: of course the idea was *never* to do JS-bashing, only people who are too tied to Javascript and not caring about tech cost-effectiveness would see htmx as a thing for JS-haters. In my talk I actually show some Javascript code, because it's useful for handling client-side-only stuff like a custom dropdown, a modal, etc. The whole idea is to put Javascript back at its place: pure client-side advanced interactions.
Technically you're not missing anything: htmx is nothing more than another turbolinks, maybe more flexible and easier to learn.
What you might be missing is the non-technical implications of these new tools. The idea behind the talk (and behind htmx, and behind turbolinks, or unpoly) is to prove that the usual arguments for Javascript application frameworks are just not valid for 90% of use cases. And *that's* a complete game-changer, even an industry-changer.
Because since 2016, every small-and-not-super-rich company that wants to create a rich UX on the web is told to hire at least 2 developers: one "front-end" (i.e. "JS"), and one "backend-end" (i.e. everything else, from API to hosting through domain stuff and user data). Or one superman with both back-end and React skills, which is, IMO, almost impossible.
From what I've seen, what businesses need is, indeed, 2 devs: one "back-end" (i.e. workers, databases, user data, domain stuff, and even hosting), and one "front-end" (i.e. "the website", from DB queries to CSS). One person should be enough to address this second scope, even with complex UIs and rich UX. And as this is almost impossible with Javascript application frameworks (because they require a lot of work), it becomes possible again, like in 2008, with htmx/hotwired/unpoly (and without the spaghetti code we had in 2008).
One more thing: of course the idea was *never* to do JS-bashing, only people who are too tied to Javascript and not caring about tech cost-effectiveness would see htmx as a thing for JS-haters. In my talk I actually show some Javascript code, because it's useful for handling client-side-only stuff like a custom dropdown, a modal, etc. The whole idea is to put Javascript back at its place: pure client-side advanced interactions.