Genuine question from an "old school" web developer: can someone please give me an example of where these new frontend technologies are actually better than just using HTML, CSS, and vanilla JavaScript or jQuery?
I have honestly yet to see an example where using something like React doesn't just look like it's adding unnecessary complexity.
These tools are absolutely nothing like React. Take a look at what htmx does, which is even simpler from a spec standpoint. There are actual on-going efforts to get it into the actual HTML spec. htmx and the like are basically built for us old-skool types (and thankfully many youngins are catching on).
Glad I'm not the only one. Ever since the first HTMX article, I felt like I was kidding myself. I had/have this thought in my head that "no way that we were that close to having all this right 25 years ago." I'm coming around and seeing that this tech gets the job done by doing one thing really well, and the whole API around it is dead-simple and bulletproof because of it. It's that good-old UNIX philosophy that's the enabling tech here.
While I can't say for certain that IE6 or early Firefox could have handled DOM swaps gracefully without real shadow DOM support, early Ajax provided the basic nuts-and-bolts to do all of this. So, why haven't we seen partial page updates as a formalism, sooner?
Not sure what you mean by so much more code. Datastar seems to do more than htmx. Otherwise, there are less features because React and friends over-complicate things for the vast majority of use-cases.
Ohhhhh I thought you meant simpler than React, lol. Gotcha. I was going by what it does, not line of code of the implementation, which is what matters in this context (a skeptic looking to check something out quickly).
I think Datastar back when I was learning web programming and the dawn of AJAX would be Xajax [1]. I didn't even learn JavaScript back then because Xajax would generate a JS shim that you could call to trigger server side functions, and the function replace page fragments with new, server-generated content.
While htmx reminds me of Adobe Spry Data [2] enough that I did a research into htmx and realize that Spry Data's equivalent is a htmx plugin and htmx itself is more similar to Basecamp's Hotwire. I assume there should be a late 2000 era AJAX library that do something similar to htmx, but I didn't use one as jQuery is easy enough anyway.
Anyway as other commenters has said, the idea of htmx is basically for some common use cases that you used jQuery, you might as well use no JavaScript at all to achieve the same tasks. But that is not possible today, so think of htmx as a polyfill for future HTML features.
Personally I still believe in progressive enhancements (a website should work 100% without JavaScript, but you'll lose all the syntactic sugar - for example Hashcash-style proof of work captcha may just give you the inputs and you'll have to do the exact same proof of work manually then submit the form), but I've yet to see any library that is able to offer that with complex interface, without code duplication at all. (Maybe ASP.NET can do that but I don't like the somewhat commercialized .NET ecosystem)
The UI I think would require React is a wizard-style form with clientside rendered widgets (eg. tabs). If you can't download a library to implement that, it is a lot of work to implement it on backend especially in modern websites where your session is now JWT instead of $_SESSION that requires a shared global session storage engine. I'd imagine that if you don't use React when the user go back to the tabbed page you'd need to either implement tab switching code on the backend side as well, or cheat and emit a JS code to switch the active tab to whatever the backend wants.
> The UI I think would require React is a wizard-style form with clientside rendered widgets (eg. tabs).
Can you think of any example sites/web apps which illustrate what you mean? I'm imagining something like VSCode, but AFAIK it's built with a custom JS framework and not React.
Try the EC2 creation page. There are tabs for advanced options, widgets like images selection that you can choose from AWS-managed, Community, your own AMI, etc. And then the next page is confirmation of similar widget which you can go back and edit. I'd imagine that if you render it in backend first and one of the tabs has error your backend form library has to know how to rerender all the widgets that you already implement in JavaScript once. If the page is done in SPA the backend just send the data back and the existing frontend widget just have to rehydrate itself.
I have honestly yet to see an example where using something like React doesn't just look like it's adding unnecessary complexity.