Hacker News Reader

Comment by namelosw | Hacker News Reader

The Web Component API is too imperative. It's hard to composite, and too easy to let data out of sync (not being reactive).

For a broader meaning of Web Component (plain React, Vue, etc), they provide good encapsulation and some degree of local reasoning. But harder to communicate and stay sync with other components/server.

For Web Component with a centralized store approach (Redux, Mobx Vuex, etc), it breaks local reasoning, and it requires the user to manage the life cycle of data instead of just reuse the life cycle of components.

So there is still quite some space to improve. I found the idea of GraphQL co-location is pretty interesting. And I also found there's a ClojureScript library named Fulcro[0] specifically trying to provide the ability to have a global data store while keeping the ability to local reasoning.

[0] https://github.com/fulcrologic/fulcro

View on HN

Web components APIs are low level. They allow code to know where to do things (the element instance, the shadow root) and when to do them (constructor, the lifecycle callbacks).

They are not a direct analog to modern frameworks, and it's completely expected that developers will use helper libraries to get better DX like declarative and reactive components.

I work on two such libraries: lit-html and LitELement. Combined they give you just as much declarative and reactive power as frameworks, much better DOM and style isolation, better performance, and smaller size than just about anything else out there.

Compare a styled Hello World example to React or any other framework:

    import {LitElement, html, css, property, customElement} from 'lit-element';

    @customElement('hello-world')
    class HelloElement extends LitElement {

      static styles = css`
        :host {
          display: block;
        }
        p {
          background: pink;
        }
      `;

      @property() name;

      render() {
        return html`<p>Hello ${this.name}!</p>`;
      }
    }

(this example uses decorators because I think it's clearer, but we support plain JS as well)

> ... and smaller size than just about anything else out there. Compare a styled Hello World example to React or any other framework:

Compared with svelte from the article:

    <script>
        export let name;
    </script>

    <style>
        p {
            background: pink;
        }
    </style>

    <p>Hello {name}!</p>

# Size comparison

## lit-element

lit-element.js?module: 8421 bytes

lit-hello.js: 340 bytes

## svelte

bundle.js: 2628 bytes

bundle.css: 72 bytes

1) That's the raw unbundled module source from unpkg. Bundled, minified, and gzipped lit-element + lit-html is about 6.7K.

2) Svelte bundles the runtime operations that each component uses directly into every component. HelloWorld doesn't use much, so it'll be small, but most component are not HelloWorld and most applications will not have only a single component. The cost of the common dependency on LitElement is amortized over all the elements that use it.

> Bundled, minified, and gzipped

Why gzipped? Bytes of source is a fairer comparison. Parsed source code should be the comparison, not transfer time.

> HelloWorld doesn't use much, so it'll be small, but most component are not HelloWorld and most applications will not have only a single component.

Then why dare other to compare sizes of a Hello world example? :-)

Huh? I'm not comparing the size of hello world examples.

Then I read your first comment wrong, I was referring to my quote in https://news.ycombinator.com/item?id=20236130

Regarding the comparison in source bytes, here it is:

minified lit-(element + html)[1]: 21.4k

I'm not sure it "amortizes" svelte when having more components, when runtime in hello world example is less then 8x size. Would love to see an example. Tried finding lit-element in "Real World Example" [2], but did not find it. Maybe you have some pointers?

1: https://bundlephobia.com/result?p=lit-element@2.2.0

2: https://www.freecodecamp.org/news/a-realworld-comparison-of-...

Looks a lot like css in JS to me, have you considered simply using the platform instead?

This passes the CSS text to CSSStyleSheet.replace(), so it very much is using the platform.

CSS Modules will make it possible to directly import a Stylesheet: https://github.com/w3c/webcomponents/issues/759

Reply on news.ycombinator.com