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.
- 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
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.
What's changing in Chrome 77? A caniuse search for "web components" does not turn up anything that's not old news.
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).
As well as the implementation status in chromium: https://www.chromestatus.com/features/4708990554472448
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.