Because it had to play catch up to native apps feature wise due to demand, while building upon a base that wasn't intended for that, while serving the same app to literally thousands of different environments and expecting it to work perfectly.
Thus, growing pains and overly complicated frameworks/plugins/other bits slapped together to address the core issues which ballooned the complexity. But we all knew that.
What's more impressive is that things are getting less complicated. Browser monoculture, while bad for the freedom of the web, is going to simplify things radically. Only having to target rolling releases for Firefox and Webkit? That's a dream from a cross-plat support side. Also javascript is actually pretty good now. Webcomponents once Chrome 77 drops and Firefox matches parity will finally be production worthy, and they're actually quite easy to build. I've been making static sites with them recently and it feels so much cleaner than going with a React or other component library approach that uses a vdom. The HTML is readable again, and there isn't any needed compilation step or crazy npm dependencies.
While it will never be as easy as it was back in the mosaic days, web dev is simplifying.
"What's more impressive is that things are getting less complicated."
Over what timeframe? While it certainly had its own issues, the HTML5/jQuery pairing easily fit into your head. Notwithstanding the benefits, React, packers, routers, and the 10 other things you bundle, is a cognitive load. Doesn't help that the routers and 10 other things don't come with React, and so, choices vary across teams.
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.
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.
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.
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.
Form registration for webcomponents is coming. Personally when trying to create a component system it's been the number one blocker I've had. Your work arounds were not great - either you'd have to mirror an input in the lightdom (not good if you're using a library that strictly enforces a vdom), or you have to use a forked form component (not good as few people will know to use it and will wonder why the x-input isn't sending its data to the form).
Once form registration is in place you'll be able to create component libraries that should truly work no matter the environment or libraries being used alongside them (as long as you have an up to date browser).
Thus, growing pains and overly complicated frameworks/plugins/other bits slapped together to address the core issues which ballooned the complexity. But we all knew that.
What's more impressive is that things are getting less complicated. Browser monoculture, while bad for the freedom of the web, is going to simplify things radically. Only having to target rolling releases for Firefox and Webkit? That's a dream from a cross-plat support side. Also javascript is actually pretty good now. Webcomponents once Chrome 77 drops and Firefox matches parity will finally be production worthy, and they're actually quite easy to build. I've been making static sites with them recently and it feels so much cleaner than going with a React or other component library approach that uses a vdom. The HTML is readable again, and there isn't any needed compilation step or crazy npm dependencies.
While it will never be as easy as it was back in the mosaic days, web dev is simplifying.