Live data from Hacker News

Web Components could replace frontend frameworks?

dannymoerkerke.com

31–40 of 248 posts

Re: Web Components could replace frontend frameworks?

#31
post #14

It's insane to me that everything Polymer was got reduced to LitElement which is basically a complete copy of React without React and without the immeasurable support of typescript, VSCode support IN the view and debugging directly in the TSX.

The lit-element package comes with typescript decorators.

Re: Web Components could replace frontend frameworks?

#32

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…

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

> The DOM is neither stateful or stateless, but rather that describes the implementation of your application logic.

One of the bizarre realities with those forced to write their own "virtual DOM" library, as I have done, is to deal with all the so-called hidden state. Form field values, the user's current text selection, scrolling position. Without a virtual DOM, simply replacing existing nodes with innerHTML or replaceChild will stomp this away. I'm not of the opinion that you need a full framework to handle this state (I wrote my own 10-line helper function which works in most cases I care about [0]), but you do need something more structured than just replacing nodes wholesale.

[0] https://github.com/magcius/noclip.website/blob/master/src/ui...

Re: Web Components could replace frontend frameworks?

#33

The tooling is woefully inadequate, and the premiere Web Component tool is stringly typed to all heck which makes it a non-starter for me. I don't want giant blobs of runtime parsed text with no validation, syntax highlighting, and obviously no type checking. But yet, here's Polymer 3: static get template() { return html` .response { margin-top: 10px; } I like web components. Web components like you, too. `; } Cool.…

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

Re: Web Components could replace frontend frameworks?

#34

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…

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

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?

Re: Web Components could replace frontend frameworks?

#36

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.

Re: Web Components could replace frontend frameworks?

#38

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…

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.

Re: Web Components could replace frontend frameworks?

#39
post #32

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…

> The DOM is neither stateful or stateless, but rather that describes the implementation of your application logic. One of the bizarre realities with those forced to write their own "virtual DOM" library, as I have done, is to deal with all the so-called hidden state. Form field values, the user's current text selection, scrolling position. Without a virtual DOM, simply replacing existing nodes with innerHTML or repl…

What about with using appendChild or insertBefore instead of innerHTML?

Re: Web Components could replace frontend frameworks?

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

How do you feel that web components are heavy? They're a pretty small set of low level APIs, and being native they have no download cost.

They're also pretty unopinionated. They only let you define an HTML element and hook it's lifecycle. They let you know where to render (the element instance and it's shadow root), and when to do things (lifecycle). The rest is up to developers, and there are lots of helper libraries with different opinions on how to implement a full element.

I think you'll find that some of them, like lit-html, LitElement, and Haunted, have very similar ergonomics and models to React. And much better performance and bundle sizes.

Post reply on HN