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

181–190 of 248 posts

Re: Web Components could replace frontend frameworks?

#181

Post by madeofpalk »

augustl wrote: post #138
_bxg1 wrote: post #118

Earlier quoted context omitted.

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.

this is just replacing framework a with framework b. It's not a "native, declarative DOM templating API yet"

Re: Web Components could replace frontend frameworks?

#182

Post by aitchnyu »

jchw wrote: post #179
pjmlp wrote: post #139

Earlier quoted context omitted.

Those file sizes miss the dependencies that are native to the browser. Web Components: 0 kb

You forgot the polyfills.

Cynical me saw Youtube in Chrome loading instantly while Firefox was served a build with the high parsing cost of Polymer polyfills. And starry-eyed developers importing if and for statements and writing imperative dom updates, while running some JS transpiler just like a React guy does. Never mind two major versions made Googling impossible, or debugging methods available to only geniuses.

Re: Web Components could replace frontend frameworks?

#184

Post by founderling »

zarzz wrote: post #174
founderling wrote: post #119

I wonder why HTML never got includes. It would be so nice to just write: On Hacker News, for the first pageview, this would load the whole "Guidelines | FAQ | Support ..." section. On all other pageloads, the browser would already have it in the cache. So it does not have to be loaded again. Building complex websites would become so much nicer. Because each part of a page would be an include.

If you are looking for just a simple load some html and replace this where my tag is kind of thing you are right, nothing does that because it’s more complicated then that... what about the styles of the included html? What about the behaviors (JavaScript) for it. How does that translate with the include? But, if you use Web Components, organize your code, and plan ahead, this is very doable today with Web Components…

    It’s clean and simple
How so? What is the Web Components equivalent of ?

Re: Web Components could replace frontend frameworks?

#185

Post by ssorallen »

deanclatworthy wrote: post #157

I think a lot of you are missing the point of Web Components here. They're not going to replace React et. al for huge frontend applications. But they are a great solution to drop in for a lot of projects where you need things like: - Sliders - Lazy loading images - Complex select dropdowns Rather than having to import a js file, css file, and use some weird wrapper around the existing DOM we have, we can import one f…

I agree, your examples seem to be prime use cases of Web Components. The original post though makes the claim that WCs are ready to replace your entire framework.

Re: Web Components could replace frontend frameworks?

#186

Post by dmitriid »

cletusw wrote: post #129
hesarenu wrote: post #76

Earlier quoted context omitted.

I would rather have browser provide rich components then rely on third party.

That's one of the huge benefits of web components -- third parties can iterate quickly to find useful patterns, then browsers can just standardize the best/most popular ones. The old way of discussing ad nauseam in committee then implementing straight in the browser gave much less useful elements. (And it's much less straightforward to convert a popular React component into something browsers could implement natively…

> hird parties can iterate quickly to find useful patterns, then browsers can just standardize the best/most popular ones.

I'm looking at hundreds of date pickers, carousels, autocompletes, customizable selects, data tables, modals (e.g. for media previews). They've been around for as long as there have been browsers (so, thrity years or so).

Can you point at any standardisation effort around any of these commonly repeated patterns?

input type="date" and input type="color" are only now barely making it into the browser.

Re: Web Components could replace frontend frameworks?

#188

Post by winterthedeep »

zarzz wrote: post #170
winterthedeep wrote: post #100

I worked with Polymer-based components ~2 years ago (an eternity in frontend-land), and I want to share my biggest pain point: you may want to integrate a ` `, but it does not "look right" in your design (eg white website, but the carousel has a black background). If the author did not set up CSS variables, you have to either try overriding stuff, or fork it. This problem is why every organization (eg GE with Predix…

As others have already answered styling into Components is still hard, but there are answers coming soon with part/theme and Scoped Stylesheets. Also, ZephJS, the Web Components library I am championing, has the ability to inherit from another ZephJS element which allows one to add to or even completely replace the styles for the new element without any special css magic. So if I want to style I simply inherit from i…

ZephJS looks cool, will try it soon. Thank you!

Re: Web Components could replace frontend frameworks?

#189

Post by zaphar »

lstamour wrote: post #93
spankalee wrote: post #51

Earlier quoted context omitted.

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

True, I don’t have benchmarks, but there was a time period where shadow DOM was popularly disabled due to performance hits, but perhaps it was all the performance hit of polyfills and less efficient implementations in browsers. https://github.com/WICG/construct-stylesheets/blob/gh-pages/... is interesting, though Sass still looks unlikely to be added to the browser so we’ll always need some amount of CSS compilation…

Very early ShadowDom had worse performance, but the major browsers have been hard at work improving it for a while now. I haven't benchmarked in several years but I wouldn't be surprised to find that it is now a boost in many cases.

Re: Web Components could replace frontend frameworks?

#190

Post by ravenstine »

z3t4 wrote: post #117
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…

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

While I know what you're getting at, the word "never" really isn't helpful or useful. There are certain times where innerHTML(or insertAdjacentHTML) is the best approach. It's really not that slow that it can't be the most clear and concise solution.
Post reply on HN