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

121–130 of 248 posts

Re: Web Components could replace frontend frameworks?

#121

Post by benforreal »

winterthedeep wrote: post #114
benforreal wrote: post #106

Earlier quoted context omitted.

In the instance of Predix (I peripherally worked on that during my time at GE) and likely EA and every other large Web Component ecosystem you're thinking of, that's desired behavior. The real want is a design system such that things look consistent, but as design systems are CSS only, they aren't smart enough for interactions that require JS. So then the need for a design system becomes a need for components of some…

"styling a background" is just an example - I admit it is a bad one (glad I don't work in frontend anymore). I will read about CSS Modules and the other stuff you mentioned. Thank you.

Sure thing! Those things are def up and coming, and I'll admit I haven't looked into them so much yet, but they are being designed to solve this very problem. I don't think that Web Components are the tool to solve every problem, but I've been a fan for a while (so much so that I'm writing a book)

Re: Web Components could replace frontend frameworks?

#122

Post by dfabulich »

dmitriid wrote: post #88
spankalee wrote: post #36

Earlier quoted context omitted.

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…

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 (but not if you include WC polyfills), though it's not smaller than Preact (3KB).

3) Efficient Updates: lit-html might be able to beat out React/Preact here if you have a large page and you don't use shouldComponentUpdate or React.memo, but lit-html doesn't use Web Components (custom elements, shadow DOM). Haunted "virtual components" (lit-html + React-ish hooks) look pretty cool, but that's still not WC.

Without a credible performance advantage, Web Components are a zombie standard, walking dead.

Re: Web Components could replace frontend frameworks?

#123

Post by JackuB »

ricardobeat wrote: post #22

As expected, no mention of server-side rendering.

This was exactly the reason I’ve abandoned them. As mentioned in other comments, they look like a good way to create a design/component system in them, because of the interop with any frontend JS framework (who doesn’t want that?!). So you deal with clunky CSS sharing and theming capabilities and there might be some solutions on the horizon. But now you want to build a static website with it (landing page, docs, blog…) and you can’t pre-render them, because there is no declarative Shadow DOM element https://github.com/w3c/webcomponents/blob/gh-pages/proposals... (rejected https://github.com/whatwg/dom/issues/510). Yeah, you can pre-render them without the Shadow DOM. Then if you want to make those chunks of HTML into WCT on load (sort of rehydration), it will trigger repaints, as you have to remove the chunk of HTML, put it into WCT and parse everything again. Or you don’t put it into Shadow Root, to prevent repaint - but at that point, if your components can work this way, why even use WCT?

Re: Web Components could replace frontend frameworks?

#124

Post by johncolanduoni »

austincheney wrote: post #38
johncolanduoni wrote: post #34

Earlier quoted context omitted.

I would argue that for what the OP was discussing `textContent` (From the linked example) is very much like `innerHTML` (As it’s a safer version of the former). I’m not sure what you mean by the DOM being neither stateful or stateless, or describing an implementation of logic. Could you clarify?

The DOM is a model of a markup language instance plus access methods. State describes memory of properties resulting from a change. For example HTTP is stateless. The DOM can be both stateful and stateless, neither, or one of. The statefulness depends on your application logic rather than any intrinsic quality of the DOM itself.

Any stateful data structure is stateless if it’s not changed. That doesn’t seem to me to be a particularly deep revelation about the DOM.

Back to your original point, that code example you linked attatches a shadow dom, creates an element in it and then puts text in it. I fail to see how that’s declarative or stateless, and AFAIK that’s the only way to populate a shadow DOM (the original HTML of the document cannot put elements there).

Re: Web Components could replace frontend frameworks?

#125

Post by cletusw »

dmitriid wrote: post #85
spankalee wrote: post #64

Earlier quoted context omitted.

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

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

Re: Web Components could replace frontend frameworks?

#126

Post by tobyhinloopen »

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.

Frameset / iframe?

Re: Web Components could replace frontend frameworks?

#127

Post by colordrops »

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.

There are html "includes" in Chrome, used as such:

But alas, Google was not able to convince other browser vendors to adopt them, and they will be removed from Chrome 75.

Re: Web Components could replace frontend frameworks?

#128

Post by colordrops »

aphextron wrote: post #2

I love writing Web Components, but they're never going to really be a thing. The promise was that we could create native components without any dependencies at all but it just hasn't worked out that way. Shadow DOM support, the real killer feature, is patchy at best without polyfills. Orchestrating them into any kind of complex app still requires some kind of framework to handle things like passing down props and eve…

Shadow DOM is now supported across all major browsers.

Also, don't understand your padding comment. Web Components are style-able.

Re: Web Components could replace frontend frameworks?

#129

Post by cletusw »

hesarenu wrote: post #76
yesimahuman wrote: post #19

Earlier quoted context omitted.

They aren't trying to solve the same problems. The main problem they solve, that no other userland framework solves, is that I can now share a collection of my rich JavaScript components with every single web developer in the world regardless of the technology they build web apps with.

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

Re: Web Components could replace frontend frameworks?

#130

Post by ernsheong »

ernsheong wrote: post #112

Web Components did replace frameworks for me. I built KanRails ( https://www.kanrails.com/ ) with LitElement, without React/Vue/etc. The alpha is at https://app.kanrails.com/signup . Again, it's in alpha. It is essentially a Trello + Google Forms + Workflow wannable. How? Stick to patterns, not libraries. Check out https://pwa-starter-kit.polymer-project.org/ for LitElement starter kits. And just use Webpack, rip out…

Just to elaborate a bit further to help fellow sojourners:

1) I use Webpack to bundle, still practically indispensable.

2) Redux state management. I use Redux-ORM to denormalize data but it has its own quirks.

3) Shadow DOM is on by default (both a curse and a great thing), which can be a problem with styling because your global CSS can't penetrate everywhere. What I do is have lots of CSS utils files (ala TailwindCSS), and import the utils as I need on demand. Drawback: Browser is parsing a lot more CSS than it needs to, as each component imports it's own CSS utils. Happy to hear about other approaches, but the browser really didn't break a sweat.

4) With Shadow DOM, you can use to compose components.

5) Routing, see the starter kit for patterns, essentially it's a router pattern, not a router library.

6) DOM event bubbling is very useful (CustomEvent), I even threw in a small Pub/Sub library somewhere for sibling communication

7) You could use some sort of DI (dependency injection), currently using di-ninja which seems a bit overkill

Essentially, nothing much changed. Use the browser. Use JS. Use patterns. Use libraries as you see fit (watch that bloat).

Post reply on HN