There are many JS libraries that are wonderfully simple. I think the problem is:

- Too much choice; it's insane how much you have to decide before you get started: React or Vue? SSR or SPA? REST, GraphQL, or RPC? PostCSS or Sass? CSS-in-JS? What router? Redux or stateful components? Axios or Fetch API? Client-side rendering/routing or server-side rendering/routing? Webpack, Parcel, Create-react-app, Next.js, or Gastby? And the list goes on... I mean that's just nuts.

- State management is inherently complicated; people don't realize that 90% of the case you don't need interactive / stateful views to build a product. People implement bunch of useless interactive "niceness" that are overkill because React allows them to. If you use React as an HTML template engine then React is actually super simple and super neat.

How awesome would it be to have a framework that has sensible defaults for all these questions. And that educates how to decide certain crucial aspects.

For example:

- Use plain old HTML instead of interactive views if you can.

- Don't start with Redux. Instead, use Redux only after you know exactly why you need Redux.

- Use a RPC-like API (e.g. https://github.com/reframejs/wildcard-api) and only use REST/GraphQL if you need to expose your data to third parties.

- Use server-side rendering/routing if your app is mainly about content (a blog, a newspaper, a e-commerce shop, ...).

- Use client-side rendering/routing if your app is mainly about user interactions (a music player, an email app, a graphical editor, ...).

That's what I'm trying with Reframe: https://github.com/reframejs/reframe

I'm not sure comparison is correct. If you want routing in jQuery app - you will have some similar concept to routers. Using packers is also not required. And if you want some good automating module splitting in jQuery app - you'll probably pick up some packer as well. So it's more like HTML5/jQuery can be compared to just React without additions.

Most of these things that bring cognitive load have some purpose. It looks from time to time that developers start making tools in the sake of tools, but most of the time there's some sane reasoning behind.

The statefulness of jQuery is a massive cognitive load.

This is far from obvious and is almost never convincingly exemplified.

It should be totally obvious if you have written or tried to reason about a jQuery codebase that is larger than, say, one thousand lines of code, especially with multiple event listeners reading from and writing to the same pieces of state.

Having done this many times, my main takeaway is that storing state is what the DOM was designed to do and it’s faster than a virtual DOM.

Try two way binding on nested form elements with jQuery.

My philosophy in those days was that the DOM is the data store, with accessors that are only used during queries. Done this way, I'd never experienced the headaches people complain about.

Perhaps for an SPA, though lots of what I see React used for doesn't need to be, or isn't, an SPA.

If you use a framework (like Angular) rather than a library (like React), things become WAY less complicated.