Web Components could replace frontend frameworks?

Post by newman8r » Fri, Apr 12, 2019, 3:27 PM UTC

Vinnl wrote: post #167

ssorallen wrote: post #11

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…

Yeah, articles that proclaim the end of frameworks due to Web Components always revolve around a misunderstanding of what those frameworks bring. This article, likewise, starts out on the same incorrect premise: > [Frameworks like Angular and React] have enabled us to do what we always wanted but never were able to: creating reusable autonomous frontend components That's not what we always wanted to do, and not why p…

Post by lmorchard » Fri, Apr 12, 2019, 4:30 PM UTC

austincheney wrote: post #26

ssorallen wrote: post #11

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…

> Web Components don’t offer a declarative way of updating the DOM; What does that mean? The methods provided by the web components spec appear declarative as do the methods provided by the DOM spec. Declarative example with nothing like innerHTML: https://developer.mozilla.org/en-US/docs/Web/API/Element/att... Either way this discussion is stupid as updating the DOM is stupid simple even without a framework. The DOM…

Post by RussianCow » Fri, Apr 12, 2019, 4:34 PM UTC

pjmlp wrote: post #134

dfabulich wrote: post #122

Earlier quoted context omitted.

Amen! The core problem now is that Web Components aren't any faster than userland frameworks like Preact. Specifically: 1) First Contentful Paint: Web Components require client-side JS to render, which guarantees that their FCP numbers will be slower than React/Preact server-side rendering solutions, which can render without client-side JS. 2) Time to Interactive: LitElement + lit-html at 4KB is smaller than React (b…

If I need to use server side rendering, there are plenty of server side rendering frameworks more mature than React/Preac. Any JS component library needs JS by definition.

Post by supermatt » Fri, Apr 12, 2019, 4:54 PM UTC

Vinnl wrote: post #177

supermatt wrote: post #168

Earlier quoted context omitted.

I reuse react components ALL the time. I think the problem with the article is that it is just looking at components (as a developer I have wanted the encapsulation this methodology brings), whereas react offers more than that - the virtual DOM, for example.

Ah, yes - within the same applications, components are often re-used. Still, it's a stretch to say code re-use is the main reason people are using React. Rather, its advantage lies in its composability and how easy it makes it to separate view logic from other logic. And probably a few other reasons that other people would name as well; in any case, it's not just the ability to re-use components, and an alternative o…

Post by pjmlp » Fri, Apr 12, 2019, 5:08 PM UTC

jchw wrote: post #205

pjmlp wrote: post #187

Earlier quoted context omitted.

The browsers we target don't need polyfills.

So you aren't targeting Safari, Edge, Firefox ESR or any version of IE?