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

131–140 of 248 posts

Re: Web Components could replace frontend frameworks?

#131

Post by fergie »

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…

"React brought a declarative wrapper around the statefulness of the DOM, and that is the killer feature"...

Yes, If there was a native standard for watching and manipulating state then frontend frameworks would be largely unnecessary.

Re: Web Components could replace frontend frameworks?

#132

Post by dmitriid »

cletusw wrote: post #125
dmitriid wrote: post #85

Earlier quoted context omitted.

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

Honest question: How is React/vue/etc. different in this regard?

React is pure JS, no string parsing is involved at runtime (JSX is just function calls [1]).

Vue has its own templating language that gets compiled to function calls that are very similar to React’s [2]. I have my fair share of criticisms against Vue (as any templating system, it’s quite inconsistent[3]).

I don’t think any of them just dump string blobs via innerHtml. And I doubt any of them parse strings with regexps at runtime.

[1] https://reactjs.org/docs/react-without-jsx.html and https://overreacted.io/react-as-a-ui-runtime/ (specifically section on React elements)

[2] https://vuejs-tips.github.io/compiler/#v-else

[3] https://news.ycombinator.com/item?id=19199423

Re: Web Components could replace frontend frameworks?

#133

Post by austincheney »

striking wrote: post #89
austincheney wrote: post #81

Earlier quoted context omitted.

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

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

Re: Web Components could replace frontend frameworks?

#134

Post by pjmlp »

dfabulich wrote: post #122
dmitriid wrote: post #88

Earlier quoted context omitted.

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

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.

Re: Web Components could replace frontend frameworks?

#135

Post by dmitriid »

jchw wrote: post #28
davidjnelson wrote: post #13

Earlier quoted context omitted.

Curious what you think about React Canvas https://github.com/Flipboard/react-canvas

I don't necessarily think everything should be Canvas, but rethinking the way pages render wouldn't be a bad idea. The issue I take with Canvas in particular is that it's poor for accessibility, password managers, and other services. I think part of the reason why the DOM and layout engines are so slow and complicated is just because of years of cruft and whatnot. A minimal layout engine with most the abilities of Fl…

We could have had it, but alas: https://terrainformatica.com/2018/12/11/10-years-of-flexboxi... (and also a comparison: https://terrainformatica.com/w3/flex-layout/flex-vs-flexbox....)

Re: Web Components could replace frontend frameworks?

#136

Post by nitrogen »

kccqzy wrote: post #86
roguecoder wrote: post #82

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.

innerHTML has to parse the html, so won't it be a bit slower?

Re: Web Components could replace frontend frameworks?

#137

Post by pjmlp »

jchw wrote: post #95
BinaryIdiot wrote: post #80

Earlier quoted context omitted.

> It's actually particularly heavy Huh? It's a very small API built _into_ the web browser. What's heavy about it? It's kinda similar to how JSX works just with less bells and whistles, more standard web stuff. > It disagrees with many of the (much more popular) frontend frameworks far too much. Ember, React and others plan to eventually support them. So, I am unconvinced that it disagrees with them at all. In fact I…

>Huh? It's a very small API built _into_ the web browser. Being built into the browser doesn't make it lightweight. I mean, if you look in terms of functions that WebComponents adds, it's a relatively small API surface. However those APIs encompass an awful lot of different functions that imo bloat basic concepts by introducing complexity into HTML elements and the DOM. >Ember, React and others plan to eventually sup…

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.

Re: Web Components could replace frontend frameworks?

#138

Post by augustl »

_bxg1 wrote: post #118
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…

What I don't get is why there isn't a native, declarative DOM templating API yet. It would be so much faster and would mostly eliminate the need for React and the like. Instead of a "virtual dom", a native "dom buffer".

I have high hopes for Flutter/Hummingbird in that regard. When their renderer is implemented using web APIs, this is basically what we'll be getting.

Re: Web Components could replace frontend frameworks?

#139

Post by pjmlp »

jchw wrote: post #104
Andrex wrote: post #67

Earlier quoted context omitted.

> "I don't think we need new complicated technologies to solve the kinds of problems React solves. If anything, we need less, like an alternative to the current DOM model." It seems to me as if you're saying: "We don't need new complicated technologies." "Also, we need a new, complicated replacement to the time-tested DOM." This probably wasn't the intent but it exposes the need for web components to be built the way…

Yeah, the DOM the web layout engine isn't complicated at all ... display: block; display: inline; display: run-in; display: flow; display: flow-root; display: table; display: flex; display: grid; display: ruby; display: block flow; display: inline table; display: flex run-in; display: list-item; display: list-item block; display: list-item inline; display: list-item flow; display: list-item flow-root; display: list-i…

Those file sizes miss the dependencies that are native to the browser.

Web Components: 0 kb

Re: Web Components could replace frontend frameworks?

#140

Post by acemarke »

pjmlp wrote: post #137
jchw wrote: post #95

Earlier quoted context omitted.

>Huh? It's a very small API built _into_ the web browser. Being built into the browser doesn't make it lightweight. I mean, if you look in terms of functions that WebComponents adds, it's a relatively small API surface. However those APIs encompass an awful lot of different functions that imo bloat basic concepts by introducing complexity into HTML elements and the DOM. >Ember, React and others plan to eventually sup…

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.
Post reply on HN