It Depends 
.
I very much think that the particular scenario dictates what approach is most well-suited. There are many web-applications that can nowadays exist without any JavaScript at all (since many transitions and effects that used to require JS can now be accomplished by solely using CSS). I tend to use tiny snippets of JavaScript, often without requiring any library at all (‘vanilla’) when things like e.g. tabs or expanding/contracting elements are required.
At the other end of the spectrum are full-blown interfaces with custom form-elements, WYSIWYG-editors or immersive single-page-applications. For those it makes sense to use a lot more scripting. In that case I recommend using one of the SPA-frameworks.
Personally I would recommend a framework that is batteries-included and has a single clear way of accomplishing things (examples are Svelte, Elm, LiveView) over something that solves only part of the problem and requires you to add other libraries to make it a full solution (e.g. React and friends):
I have worked on quite a few React-based projects and I have never seen two of these whose architectures were alike. This makes the learning curve of understanding such a project much higher, as well as having the risk of discussing a lot about which particular set of libraries is most suited for what you are currently building, rather than focusing at the problem at hand.
Don’t get me wrong; freedom is nice and one of the main drawbacks of Elm is that certain design choices it makes are (arguably overly) restrictive. However, I much prefer (in programming in general) freedom (to drop to a lower level of abstraction) be opt-in rather than the default.