Live data from Hacker News

Web Components could replace frontend frameworks?

dannymoerkerke.com

141–150 of 248 posts

Re: Web Components could replace frontend frameworks?

#141

Web Components don’t offer a declarative way of updating the DOM; it’s still `innerHTML` and using DOM APIs to edit the state of the live DOM. Backbone was a hassle to manage in any sizeable app because updating the view was left up to every dev to figure out themselves. React brought a declarative wrapper around the statefulness of the DOM, and that is the killer feature that Web Components does not offer at all. Vu…

There is lit-html and lit-element, though you can get tripped up by the difference between props and attributes coming from React JSX where everything is props because it’s all native JS until the DOM render... It’s tricky to recommend them because I’m using web components at work and find the transition from React especially rocky. But they are native and standard, and other frameworks are slowly moving in that dire…

But at that point the headline is "framework x could replace framework y"?

Web Components are great for reusable components like date pickers that you might want to re-use regardless of framework. If they're just the technology backing the implementation of some framework, than that framework is only worth switching to if it provides something fundamentally better than the framework you and many others already know, because the mere fact that it's built on Web Components no longer provides a significant advantage...

Re: Web Components could replace frontend frameworks?

#142

Web Components don’t offer a declarative way of updating the DOM; it’s still `innerHTML` and using DOM APIs to edit the state of the live DOM. Backbone was a hassle to manage in any sizeable app because updating the view was left up to every dev to figure out themselves. React brought a declarative wrapper around the statefulness of the DOM, and that is the killer feature that Web Components does not offer at all. Vu…

"declarative way of updating the DOM" Updating is not declarative.

It's React that does the updating, the programmer only writes declarative code.

Re: Web Components could replace frontend frameworks?

#144

Web Components don’t offer a declarative way of updating the DOM; it’s still `innerHTML` and using DOM APIs to edit the state of the live DOM. Backbone was a hassle to manage in any sizeable app because updating the view was left up to every dev to figure out themselves. React brought a declarative wrapper around the statefulness of the DOM, and that is the killer feature that Web Components does not offer at all. Vu…

There is lit-html and lit-element, though you can get tripped up by the difference between props and attributes coming from React JSX where everything is props because it’s all native JS until the DOM render... It’s tricky to recommend them because I’m using web components at work and find the transition from React especially rocky. But they are native and standard, and other frameworks are slowly moving in that dire…

Well I like stencil for its typescript and jsx but I haven't dug into it hard enough yet to discover its agony points. Its just that when it compiles its all native code calls, no framework to ship but you still benefit from jsx and typescript in development.

Re: Web Components could replace frontend frameworks?

#145
post #137

Earlier quoted context omitted.

Yeah, React is pretty much anti-browser standard APIs. Vue.js, Angular or vanilaJS are our JS frameworks, exactly because supporting Web Components is part of the culture.

On the contrary, the React team has had a bunch of discussions with the Chrome team recently about adding new scheduling APIs to the browser platform, specifically to support the kinds of things that React (and other frameworks) need to do.

Were those discussions public?

Yet another Chrome specific API?

Re: Web Components could replace frontend frameworks?

#146

Earlier quoted context omitted.

> You missed the point. [explanation of the point] If it's that simple, could you consider replacing the first 1k words with this instead? I'm entirely serious. > Then you didn't search very hard. Okay, I'll bite. I searched for the phrase "host bindings extension to WASM" (the literal phrase included in your treatise) on DuckDuckGo, which brings me to https://duckduckgo.com/?q=host+bindings+extension+to+WASM&ia... .…

> If it's that simple, could you consider replacing the first 1k words with this instead? No. I am not going to change anything because strangers online cannot read. If you have a better approach submit a pull request.

One does wonder what the point is of trying to communicate something, if the speaker does not care about whether the listener understands their message...

Re: Web Components could replace frontend frameworks?

#147
post #117

Web Components don’t offer a declarative way of updating the DOM; it’s still `innerHTML` and using DOM APIs to edit the state of the live DOM. Backbone was a hassle to manage in any sizeable app because updating the view was left up to every dev to figure out themselves. React brought a declarative wrapper around the statefulness of the DOM, and that is the killer feature that Web Components does not offer at all. Vu…

Never use .innerHTML! Instead use .appendChild, .removeChild, and .innerText. Using .innerHTML is like having a program patch itself during runtime.

textContent is usually better than innerText.

Re: Web Components could replace frontend frameworks?

#148
post #9

>Web Components will replace your frontend framework Yeah, I very much doubt that. Web Components is basically a suite of browser technologies. It's actually particularly heavy and I kind of hope it doesn't catch on personally, since it pushes so much to already giant monolithic web browsers. Frameworks and libraries like React and Angular are tools for developing applications first and foremost. The actual technolog…

How do you feel that web components are heavy? They're a pretty small set of low level APIs, and being native they have no download cost. They're also pretty unopinionated. They only let you define an HTML element and hook it's lifecycle. They let you know where to render (the element instance and it's shadow root), and when to do things (lifecycle). The rest is up to developers, and there are lots of helper librarie…

> And much better performance and bundle sizes.

I understand that you're the author of lit-html - would you say that the above is the main selling point of it?

Re: Web Components could replace frontend frameworks?

#149
post #86

Earlier quoted context omitted.

(For security purposes, in vanilla js we should all be using textContent, not innerHTML, and creating dom nodes directly.)

When you control the data, innerHTML is fine. It's only untrusted data coming from the user that's the problem.

Only if you can, with absolute certainty, keep track of which of those is which, and never have it change, or have some offline process polute data that was supposed to be clean.

There is almost never a reason to use innerHTML, and by avoiding it you reduce the surface that could be attacked.

Post reply on HN