Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Web components are useless, you can't pass values around without converting them to string or employing a non-native mechanism, and of course you need to do all DOM updating by hand - which is both way worse than just using React from various perspectives.


Web Components are HTMLEelement instances, which are ordinary JavaScript objects on which you can set properties without any "non-native mechanisms":

`document.querySelector('div').someProperty = {some: 'value'};`

For DOM updates you will generally use a declarative DOM rendering engine like lit-html, just like how you use React's VirtualDOM. In fact, the most popular Web Component "library" [LitElement](https://lit-element.polymer-project.org/) uses very simlar vernacular as React (like the `render()` method), and from a developer perspective feels exactly like using React, except it relies more on builtin platform features.


Only from the point of view of React devs with their anti-WebComponents agenda.

Everyone else is just embracing them.


There are no tools to embrace them, there is no way to make an universal web component like you can do with a React component without severely limiting what you can do and how you can develop it and how it performs. It's very sad, I'd love to use native Web Components but it's so bad it hurts (or you end up reimplementing incompatible React).


You're not understanding what web components are.

They alone are not a replacement for the entirety of frameworks, they are low level hooks that standardize the more fundamental level of frameworks: component instantiation, component lifecycle, and style and DOM encapsulation.

Higher level features like DOM rendering are left to libraries, and there are some really good libraries for that. And I'm not sure what you even mean by the libraries limiting what you can do how you can develop. There's way more choice in the web components ecosystem than within any single framework.


I think the biggest difference is that I consider DOM rendering a low level feature that should be abstracted away lowest as possible.


Yep, again the anti-WebComponents message.

Angular, Vue, Polymer, Svelte and a couple of Web based RAD editors look like tooling to embrace them to me.

Since I don't have any plans to ever use React, how does your magical component work with my tooling?


My component is "magical" thanks to the React ecosystem and because it uses the tools the React platform provides to greatly integrate with said ecosystem. The tools you suggested are not comparable to React - React Hooks and Contexts are the part I'm most interested in.

If you use different tooling, then it doesn't work, and that's okay. You don't need to care about React and I don't need to care about Web Components. It was suggested that React is useless and should be replaced with Web Components, and I'm simply saying that Web Components are not sufficient to replace React, not that you should switch.


Naturally my tools are not comparable to React, because by targeting WebComponents they support everyone on the browser instead of the React developers silo.

And best of all, they are even usable from React.


Ofcourse you can pass properties, I'm afraid your information is wrong in both cases.

A small demo https://jsfiddle.net/zu52o7bq/.


Sorry but this is in no way comparable to what React Hooks, React Contexts and React component props offer, plus the non-existent component lifecycle. I even have to render it myself! Inside the component!!! Where is separation of concerns? And why do I need to register it? I just want a class/function that behaves like a component (with a lifecycle and managed rendering), no registration whatsoever.

These are not React-like components - independent reusable universal blocks that can be used without any knowledge of the component other than that it uses React.


You stated one can't pass props around and you have to resort to strings (this incorrect statement is posted to HN so often I'm curious where does this knowledge comes from).

I just proved you wrong with this simple demo, so you waved that away and pulled out hooks argument.

How is that related is beyond me (not to mentioned hooks are fresh in react world too). If you want to have a discussion at least have decency to not change subject randomly, it is annoying.

BTW. You can use both hooks (via haunted project) or redux (lots of people do that) with WC's just fine. In fact I wrote code that looks almost the same in react and lit-element.


I think we misunderstand each other because of terminology. You understood me as class props, but what I meant is component props: <Component prop={something} />. In React world this is different from class props because if the prop changes it also causes the component to update. React separates the component "template" (class or function) and "node" placed in the component tree, the props are updating the node contrary to WebComponents where you have a class instance directly. In WebComponents I have to catch the underlying HTMLEntity and then set the props on the class (in React we're not setting the props on the class itself, it's separated for the ability to handle updates) and then handle all updates myself instead of just passing the complex object as a prop.

Hooks are an extension of that - it is a different way to pass values around, a very powerful one.


Yes what you need to do as a workaround is a BUG in react, not a problem with WC's - and I think Dan Abramov tweeted that this will be solved eventually (I can't find the exact tweet) - In Vue, svelte, Angular or even preact you would be able to do <my-component prop={something} /> just fine, no need to mess with HTMLEntity. If this is fixed this should be transparent to you and work the same way, you should be able to mix and match both kinds of components.

See here https://custom-elements-everywhere.com/ a list of popular libraries and how they handle events and props.


I meant when I'm not using react


I have no idea what you meant by that statement.


I didn't talk about React-WC cooperation, I was talking about passing props around WebComponents when using WebComponents alone - it allows you to pass only plain values, otherwise you need the underlying HTMLEntity


I still have no idea what you mean by that, implementation detail? I have passed props using WC's alone in a declarative way via LitElement - all other popular solutions allow that too.


This is just so wrong. Where did you hear these things? You've obviously never actually tried web components.


So I can pass a complex value as a prop without needing to convert it or catching the underlying HTMLEntity? The tree will update once a property updates?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: