Hacker News Reader

Comment by codingdave | Hacker News Reader

I'm not sure I buy the "React is replacement, not augmentation" argument. At the end of the day/render, React still renders HTML elements... with javascript event handlers. Wrapping an '<img />' in a React component doesn't mean I've taken away any functionality of 'img'. I just add to it -- augmentation.

Maybe the author has worked in different React codebases than I have, but in my experience, we use built-in browser functionality unless we have a reason not to. Maybe I've just been lucky?

View on HN

Surely every single web architecture ultimately renders HTML elements, that wasn't the point.

The point is that the flavor "HTML Web Component" does not rely on JS to start rendering, unlike React.

You’re right for the large majority of cases, but there are exceptions. These days some use canvas or WebGL, in the past some have used Flash or Java Applets/Swing.

A popular app that some web developers here may use day-to-day recently is Figma, which uses WebGL for rendering.

Where does the data come from, if not JS? How then do HTML Web Components start rendering, without data?

The data would come as part of the server response in most cases.

A variation could be the rendering of a partial UI whilst you then fetch data client-side. Even in this case the web component has the advantage as no JS is needed to render the initial UI.

As long as you're not shoving everything into the shadow dom, then you've got a fallback HTML element that can render before JS is read (and even if the JS is completely broken)...

<special-image>

  <img src="/example.png" />

</special-image>

This image will render before the JS is executed, so you've got no blockers and a perfectly fine fallback, then with the web component you enhance your image with whatever JS you want.

I believe Flutter doesn't (or didn't use to) - it rendered to canvas, and then in parallel built a hidden DOM structure so an accessibility tree could be derived and made available to screen readers.

I could be wrong, but it seems like the article is saying that the core difference would be this:

React (rendering in the browser, not server side): Page Load -> Component Load

vs.

Web Component Page Load -> Default Render -> Component Load

So if someone has JS disabled they would still see SOMETHING for the web component vs. nothing in React. And with JS they could get to some further render state.

In some cases, react seems to go out of its way to make the built-in functionality harder to access. For instance, if you assign "onchange" to an <input>, react will give you the "input" event, not the "change" event. (Actually, it gives a neither. It gives you a "synthetic" event that's closer to input than change) What if you know what you're doing, and you actually wanted "change"? You have to use an element ref an attach the handler using an effect.

You can access the `nativeEvent` property on the event object[0] if you prefer

[0]: https://react.dev/reference/react-dom/components/common#reac...

Doesn't solve this problem. "change" fires at different times from "input". `nativeEvent` is useful if you want the real event data object for the event that actually fired. In this case, it's a whole other event.

it's a well known thing in react (preact does it well https://preactjs.com/guide/v10/differences-to-react/#use-oni...), and probaly a design mistake on their side (now too late to change), I can't think of other cases like that

They could still expose a `nativeChange` event without breaking backward compatibility.

It depends on the architecture of your app. If you're using React to return HTML from the server, then indeed wrapping an <img /> in a React component means you're augmenting an existing element. But if you're rendering the entire thing on the client side, then the <img /> is ultimately inseparable from the React component.

When I read that I thought about the reverse: putting React inside other HTML. In my experience React works wonderfully when you’re using it from top to bottom (replacing your entire page structure) but it can be difficult to fit into an existing structure when you’re trying to do things like server side rendering.

Reply on news.ycombinator.com