Comment by jjcm | Hacker News Reader

Comment by jjcm | Hacker News Reader

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.

The statefulness of jQuery is a massive cognitive load.

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

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.

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

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.

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

> Webcomponents once Chrome 77 drops and Firefox matches parity will finally be production worthy, and they're actually quite easy to build.

What's changing in Chrome 77? A caniuse search for "web components" does not turn up anything that's not old news.

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).

Can you link me to a page describing this new functionality in action?

Sure, here's the API proposal that's been approved: https://docs.google.com/document/d/1JO8puctCSpW-ZYGU8lF-h4FW...

As well as the implementation status in chromium: https://www.chromestatus.com/features/4708990554472448

Reply on news.ycombinator.com