I don't hate it, I just hate overuse of it
If there's one thing we can all appreciate about the rise of JAMSTACK, is that it brought about renewed vigor even amongst the mainstream for static built and deployed websites.
This is a good thing. The web has become increasingly bloated for various reasons, and along with that we've also seen increasingly complex websites/apps that put ever increasing load on the server, in terms of those that dwell sorely server-side. With static generated websites being back in vogue since, I dunno, 2016 or so, we've seen more and more pure HTML and CSS being deployed that only do (or connect to) server stuff when they have to, instead of the server itself being responsible for spitting out the HTML and CSS. A healthy bit of Separation of Concerns, if you will.
Unfortunately, somehow this has also led to websites being increasingly written in and depending on JavaScript (JS). Entire JavaScript frameworks have risen (almost too many to count nowadays) and become incredibly popular. I wish I were joking, but it's even fairly common to write HTML (or even CSS) inside JavaScript. Even one of the more sane JS driven frameworks, Svelte, tends to save all the HTML and CSS (well, if the CSS is written inline in the HTML anyway) inside the JavaScript bundles. When coupled with it's sister project, Sapper, which allows you to actually generate a static website, this is especially awkward as you have both static pages AND a copy of all the HTML and CSS in the .js bundle files as well. Hello bloat.
For mine, JavaScript has its place. To assist with rudimentary actions or effects on a webpage, or to do a little bit dynamic fetching of data (ala AJAX, as long as it has graceful degraduation). But having a website that could otherwise be written completely statically, instead pulling in hundreds of kilobytes just to "hydrate" the interface and create a kind of "SPA" (Single Page Application) feel...? I don't know, but it seems a little insane.
I know this because I myself once fell victim to the hype and wrote a website that was for all intents and purposes, a normal website. A home page, about section, a few other pages related to the business it was for. I did this with the aforementioned Sapper/Svelte combination. Now, the only really dynamic part of this website was a quotation form, i.e it took user input and generated a quotation of item costs, and then the user could choose to proceed (or not) in which case the system would send an email.
The quotation portion of the site could have been done in, at the very least, just a small Svelte component, accessed only when and IF the user wanted to get a quotation. Instead, no, old mate Andy here decided to build the entire website in Sapper instead. What Sapper does is, at compile time, builds the site and generates the .js bundle files, and also crawls the urls inside the site to generate a static version of the site as well. So you get a combination of good old .html files, that has links to the bundle files in the footer of the HTML which then loads and "hydrates" the interface, therefore handing off routing responsibility etc to the Sapper engine instead of letting the browser follow the URLs and loading say, about.html in it's entirety. This is meant to give that instant loading "app feel". It's nothing new, developers have been using AJAX to achieve similar effects for years, but projects like Sapper/Svelte exist to try make development faster and less fiddly.
Which is noble enough, and I'm not here to bag out Svelte or Sapper. Or even React, even though I find its syntax abhorrent. These projects exist for a reason and can have legitimate use. And of course there is the whole inbuilt "react-ivity" aspect that all three of the projects I just mentioned tout. The problem is impressionable or inexperienced developers, or just plain Soydevs, coming along and using these frameworks for what may be essentially brochure-style websites, instead of say a mobile application. That's pretty crazy, and that's how you get websites pulling in hundreds of kilobytes of JS on top of already existing static HTML/CSS to basically give a slightly faster response and a smooth transition maybe between pages. However, that's after the website potentially takes twice as long to load initially.
Then there's what I'll call technical-debt. That site I mentioned that I made with Sapper? It'll be one heck of a job pulling it apart and converting it to normal HTML/CSS. I essentially created a bit of vendor lock-in for a site that should never have needed to be that complicated or bloated. Lesson learned.
So, TL;DR: If we're going to encourage a more static web, let's write actual static websites rather than deferring it all to JavaScript. Use JS where necessary, but no more than that. if you have to ask yourself, "should I really need JavaScript just to do this?", then you probably don't.