Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Components could replace frontend frameworks?

dannymoerkerke.com

Post reply on HN
Print view View original

81–90 of 248 posts

Re: Web Components could replace frontend frameworks?

#81

Post by austincheney »

striking wrote: post #47
austincheney wrote: post #26

Earlier quoted context omitted.

> 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…

> * stupid - https://github.com/prettydiff/wisdom/blob/master/Delusional_... It seems you wrote this article; have you read it back? You bury the lede under 1230 words explaining some social concepts rather than anything programming-related. Additionally, you use many complex words to describe simple subjects. And you do this knowingly: for example, you felt the need to link the definition of "acquiescence" to the wo…

> If the purpose of this article is to convince people that disagree with your statements

You missed the point. It isn't about disagreement. Its about not throwing away evidence to retain a challenged opinion. The first two thirds of the article was very explicit about this.

> when I haven't been able to find anything indicating this elsewhere on the web.

Then you didn't search very hard. The article specifically mentioned this is in relation to the web assembly host bindings proposal. The first search on any search engine brings me to the spec on github. As far as DOM work you would have to dive into the DOM string portion of JS API integration section: https://github.com/WebAssembly/webidl-bindings/blob/master/p...

If you are confused as to what the article says then submit a pull request with a superior recommendation. It is on github after all.

Re: Web Components could replace frontend frameworks?

#82

Post by roguecoder »

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…

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

Re: Web Components could replace frontend frameworks?

#83

Post by tflinton »

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…

"declarative way of updating the DOM"

Updating is not declarative.

Re: Web Components could replace frontend frameworks?

#84

Post by tflinton »

jchw wrote: 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…

"I don't think we need new complicated technologies to solve the kinds of problems React solves."

Isn't web components the standard, and react is the complicated technology?

Re: Web Components could replace frontend frameworks?

#85

Post by dmitriid »

spankalee wrote: post #64
chmln wrote: post #41

Earlier quoted context omitted.

With LitElement you are still encoding markup in strings and only the interpolated expressions are typechecked [1]. Not to mention that LitElement is far more clunkier and tedious. [1] https://lit-element.polymer-project.org/guide/start#use-lite...

The lit-plugin VS Code extension provides type-checking and code-completion for lit-html temptlates. The approach can be adopted for a tsc plugin.

It’s still opaque string blobs no matter how you try to dress them up.

—-

I should probably edit this:

It’s still string blobs that are totally opaque to the browser, and that are parsed with regular expressions[1] at runtime[2] and dumped into DOM via innerHtml[3].

[1] https://github.com/Polymer/lit-html/blob/61c08a615abadbe58bc...

[2] http://exploringjs.com/es6/ch_template-literals.html

[3] https://github.com/Polymer/lit-html/blob/61c08a615abadbe58bc...

Re: Web Components could replace frontend frameworks?

#86

Post by kccqzy »

roguecoder wrote: post #82
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…

(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.

Re: Web Components could replace frontend frameworks?

#87

Post by zachrose »

I wish the ideas of the Elm Architecture (or React/Redux) could be brought to the browser. Primarily, an atomic single source of truth (serializable data) for window.document and a way to connect that state to the DOM through pure functions so that we can avoid local component state that then has to be orchestrated with references, event buses, etc.

Re: Web Components could replace frontend frameworks?

#88

Post by dmitriid »

spankalee wrote: post #36
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…

There's nothing wrong with using a DOM templating library to give you declarative DOM updating. There are a number of solutions, many even JSX-based, and this is also why I created lit-html, which offers extremely light weight template expressions, similar to JSX but in standard syntax, and very fast updates. There's no requirement that you use web components without helper libraries. That was never their intent.

> That was never their intent.

No one remembers what the intent was. Just two years ago the whole narrative from the proponents of web components was “the future is here, no need for frameworks, get rid of your reacts and angulars and... and...”

But then people actually tried using them.

So, curiously, the narrative quickly shifted to “oh, these are just primitive APIs never intended for direct use, and only intended for library and framework authors”.

Curiously, at the same time the narrative usually keeps going “react is crap, you should drop it in favor of web components”.

A nice recap from Dan Abramov: https://dev.to/dan_abramov/comment/6kh1 and more in the discussion here: https://dev.to/ben/why-the-react-community-is-missing-the-po...

And we are in yhe comments to an article that literally argues that Web Components will replace frameworks. While half of the people in the comments say “yeah, the intent is for them to be used only by library and framework authors”.

There’s a certain hint of schizophrenia in how Web Components are described by their proponents.

Re: Web Components could replace frontend frameworks?

#89

Post by striking »

austincheney wrote: post #81
striking wrote: post #47

Earlier quoted context omitted.

> * stupid - https://github.com/prettydiff/wisdom/blob/master/Delusional_... It seems you wrote this article; have you read it back? You bury the lede under 1230 words explaining some social concepts rather than anything programming-related. Additionally, you use many complex words to describe simple subjects. And you do this knowingly: for example, you felt the need to link the definition of "acquiescence" to the wo…

> If the purpose of this article is to convince people that disagree with your statements You missed the point. It isn't about disagreement. Its about not throwing away evidence to retain a challenged opinion. The first two thirds of the article was very explicit about this. > when I haven't been able to find anything indicating this elsewhere on the web. Then you didn't search very hard. The article specifically men…

> 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.... The first result is https://github.com/WebAssembly/webidl-bindings/blob/master/p..., a 404. If you want someone to find something so badly, link it instead of making claims about how much effort they might have put in. The onus is on you to prove the claims you make, and I wish this were something you took the time to link instead of the definition of "acquiescence".

> As far as DOM work you would have to dive into the DOM string portion of JS API integration section: https://[...]

You don't make clear which part I'm supposed to be looking at, and I don't explicitly see it stated that DOMString will be the only way WASM can interact with the DOM; there's just an example of how a WASM function might take a DOMString and return a DOMString, and how the binding machinery works in that case.

Additionally, after some additional searching, I found https://github.com/WebAssembly/function-references/blob/mast... including "Easier and more efficient exchange of function references between modules and with host environment" and information about closures. I'm not certain about it, but doesn't this run counter to your point about code running against `window.document`? After all, you could (if I'm reading this correctly?) pass in a bunch of closures that directly manipulate `window.document` through something like this.

> If you are confused as to what the article says then submit a pull request with a superior recommendation.

If I don't understand the article (you've just told me I don't), how do I help you make it better?

Re: Web Components could replace frontend frameworks?

#90

Post by dfabulich »

spankalee wrote: post #51
lstamour wrote: post #25

Earlier quoted context omitted.

Slots require shadow DOM which means there can be performance and CSS issues on widgets designed for local use with shared CSS. But I agree they’re also an option. :)

Performance issues? Native Shadow DOM, especially with Constructible Stylesheets, is a perf boost. Limiting style resolution to smaller scopes and less rules is good.

Perf boost compared to what? It can't be a FCP perf boost relative to server-side rendered plain old CSS and HTML, because shadow DOM requires client-side JavaScript.

Plain old CSS is able to parse and render before the JS required to launch web components has even finished.

Post reply on HN