Hacker News Reader

Comment by Natela | Hacker News Reader

I agree very much. However there are two points that make it difficult : - Virtual Dom. It simplifies a lot the creation of components. And components that are made for a VDOM are very different from those made without VDOM in mind. - Data Binding. There are multiple ways to bind data to your components, once again this might influence the way components are made.

Those are not standard, some people like VDOM other not, and not everybody want to bind data the same way. So if we all contributed components in vanilla JS / Web Components, this still doesn't solve what should the API of those webcomponent look like.

View on HN

Try https://github.com/Polymer/lit-element for an alternative to VDOM, without the VDOM part. It's reactive and uses lit-html under the hood.

This is confusing. The only difference between if this were a web component vs a React component is that the consumer would not capitalize the name. Instead of `<Button appearance="primary">` they would do `<evergreen-button appearance="primary">`. That's it.

Not at all true. Where's your onClick? People want their buttons to actually do things, right?

With Web Components you're back in the land of saving element references, querySelector, addEventListener, and string-only attributes. It sucks. If you want something more like what React provides, where attributes (props) can be objects, functions, other React elements, etc. then you need to use a library (e.g. Polymer) that's just as non-standard as React is.

Nope, you're wrong. onClick works with web components just the same way as it does with any other element. Proof: https://codesandbox.io/s/j3jmkr98pw

That uses React to attach onClick, so obviously yes. I'm saying without React. You said:

> The only difference between if this were a web component vs a React component is that the consumer would not capitalize the name. Instead of `<Button appearance="primary">` they would do `<evergreen-button appearance="primary">`.

If you're not using React, you obviously can't do `onClick={...some function here...}` with Web Components, you have to use the shitty DOM APIs.

I guess I see what you're saying that web components can seem be consumed as expected from a React app. I thought we were talking about not using React at all.

But I would expect this still would not work as expected with props like `children` or other props that accept React elements. It seems like the web component would be expecting Node instances, not React elements. Since components can decide whether or not to render their children, they wouldn't be backed by Nodes yet when the web component received them. So it seems like it'd have to know whether it's dealing with React and use ReactDOM.render directly.

Of course you can set props on a WC, it's just a DOM node. You can do everything you can do with any other standard node + exposed API. You could use jsx/vdom any other solution to set up props/events.

IMO saying 60kb of react+vdom code vs 6kb of templating library that builds on top of template literals is equally non-standard is not a fair comparison.

https://custom-elements-everywhere.com/

I realize you can set properties, obviously. Those are not the same as using attributes, which is what React's props are more equivalent to. e.g. you can't do <my-button onClick={...some function here...} />. So using it does indeed suck the same way using normal DOM elements sucks: you need a reference to the created node, addEventListener, etc.

That's what makes the grandparent's statement incorrect:

^ wrong.

You can with lit-html/stencil, but yes you need something to take care of that for you, which is very small dependancy. WC's are NOT supposed to be consumed directly unless you do very simple things.

Reply on news.ycombinator.com