Live data from Hacker News

Web Components could replace frontend frameworks?

dannymoerkerke.com

61–70 of 248 posts

Re: Web Components could replace frontend frameworks?

#61
post #46
post #42

Ploymer was a crapshow and HTML import a nightmare for load times. Unless some sort of topology bundling is provided for web components I'm out. We tried to do generic components for multiple frameworks based in webcomponets and it was an utter failure in practice especially for low band networks.

Allow me to float ZephJS at you as an example of a Web Component framework with a bundling tool to do what you describe. Simplifies everything about building Web Components. Introduction: https://gist.github.com/arei/8083a6270e704b830c68a2020f3e5e3... Bundling specifically: https://github.com/awesomeeng/zephjs/blob/master/docs/Compon...

This looks pretty cool, thanks for sharing.

Re: Web Components could replace frontend frameworks?

#62
post #20

Earlier quoted context omitted.

what about slots?

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

Shared CSS can be dealt with using @import.

Re: Web Components could replace frontend frameworks?

#63

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…

We have been using a small bit of glue code to write Web Components declaratively with Snabbdom for a couple of years at Mixpanel: https://github.com/mixpanel/panel. Happy to talk further about our experience!

Re: Web Components could replace frontend frameworks?

#64
post #41

Earlier quoted context omitted.

Polymer is deprecated in favor of LitElement which comes with TypeScript decorators.

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.

Re: Web Components could replace frontend frameworks?

#65
post #48

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

This. I feel like an old man yelling at a cloud, but while everyone seems to focus on how awesome shadow DOM and isolated CSS is, I need to deal with using a global theme and styles.

I have the same problem with global styles when using Web Components. Using @import in the components to include the shared style files solve the problem.

Re: Web Components could replace frontend frameworks?

#66
I argued for a similar case last year[1], however the missing piece right now is updating state in a clean way. Web Components definitely won't replace current front-end frameworks, but combined with ES Modules the web is getting to a good place for resuable primitives. :)

[1] https://andrewrabon.com/the-case-for-react-like-web-componen...

Re: Web Components could replace frontend frameworks?

#67
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. 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 they are: progressively enhanced from what's already standardized in browsers. Web components really aren't that complex, and comparing them to React in this way is a disservice.

Re: Web Components could replace frontend frameworks?

#69

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.

Ah yes, the quantum DOM.

Re: Web Components could replace frontend frameworks?

#70
post #66

I argued for a similar case last year[1], however the missing piece right now is updating state in a clean way. Web Components definitely won't replace current front-end frameworks, but combined with ES Modules the web is getting to a good place for resuable primitives. :) [1] https://andrewrabon.com/the-case-for-react-like-web-componen...

Be sure to checkout lit-html and LitElement (https://lit-html.polymer-project.org & https://lit-element.polymer-project.org)...what you've written about here already exists!
Post reply on HN