5 ms·

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 Compon

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 https://github.com/fulcrologic/fulcro

spankalee 7y ago
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)
- arve0 7y ago
  > ... 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
  - spankalee 7y ago
    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.
    - arve0 7y ago
      > 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? :-)
      - spankalee 7y ago
        Huh? I'm not comparing the size of hello world examples.
        arve0 7y ago
        Then I read your first comment wrong, I was referring to my quote in https://news.ycombinator.com/item?id=20236130 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 https://bundlephobia.com/result?p=lit-element@2.2.0 2: https://www.freecodecamp.org/news/a-realworld-comparison-of-front-end-frameworks-with-benchmarks-2019-update-4be0d3c78075/ https://www.freecodecamp.org/news/a-realworld-comparison-of-...
- phpnode 7y ago
  Looks a lot like css in JS to me, have you considered simply using the platform instead?
  - spankalee 7y ago
    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 https://github.com/w3c/webcomponents/issues/759

spankalee 7y ago

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)

arve0 7y ago
> ... 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
- spankalee 7y ago
  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.
  - arve0 7y ago
    > 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? :-)
    - spankalee 7y ago
      Huh? I'm not comparing the size of hello world examples.
      - arve0 7y ago
        Then I read your first comment wrong, I was referring to my quote in https://news.ycombinator.com/item?id=20236130 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 https://bundlephobia.com/result?p=lit-element@2.2.0 2: https://www.freecodecamp.org/news/a-realworld-comparison-of-front-end-frameworks-with-benchmarks-2019-update-4be0d3c78075/ https://www.freecodecamp.org/news/a-realworld-comparison-of-...
phpnode 7y ago
Looks a lot like css in JS to me, have you considered simply using the platform instead?
- spankalee 7y ago
  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 https://github.com/w3c/webcomponents/issues/759