8 ms·

"Specifically, they’d like you to use Polymer. The problem is that the Web Component API is really unpleasant to use directly, especially compared to React. Tha

"Specifically, they’d like you to use Polymer. The problem is that the Web Component API is really unpleasant to use directly, especially compared to React. That’s really holding Polymer back in the framework marketplace. Other WC-based frameworks like Svelte, Skate, and Stencil abstract away from WCs, treating them as a compilation target." That argument feels like a non-sequitur. Polymer's API is different from the Web Component API, so even if the Web Component API would be unpleasant to use directly, that is not a criticism of a different API (in this case the Polymer API). Polymer's API is "similar" to the native Web Component API though, but it's designed to be easier to use than the native API.

spankalee 9y ago
Polymer's API _is_ the Web Components API, with some helpers added for reacting to property changes, augmenting templating and a few others. Polymer is simply a base class for your elements that sits between HTMLElement and your component class. But I don't really get the "Web Components APIs are unpleasant" line of criticism. The WC APIs are just the element constructor, connectedCallback, disconnectedCallback, attributeChangedCallback and what methods and properties you define on your component. These lifecycle methods are nearly identical to what you get in React and just about every other framework. If those don't have unpleasant APIs, Web Components don't.
- dfabulich 9y ago
  Author here. It's not just me saying that Web Components are unpleasant. In the article, I linked to Sam Saccone of Google saying that the WC developer experience is significantly worse than React's developer experience. https://twitter.com/samccone/status/914528725852663808 https://twitter.com/samccone/status/914528725852663808 "This of course is coming from someone who has used web components every work day for the last 2 years. Hard to ignore the DX gap that exists." To which Alex Russell, also of Google and one of the architects of the WC API, replies, "Who's ignoring it?" There are certainly some developers who compare and contrast Polymer and React and prefer Polymer, but it's fair to say that the vast majority of developers who have made this comparison have preferred React's developer experience. Even Polymer's advocates seem to be holding their nose and using it because they appreciate the long-term promise of Web Components interop. Why? It's hard to say exactly, but I think it has to do with React's guarantees that the UI will be a pure function of state. Lots of nifty React features emerge from that. Polymer components make no such guarantees. I'm actually pretty enthusiastic about lit-HTML as a way to close the gap. We'll see how it goes.
  - spankalee 9y ago
    Sam's tweet has no specifics, neither does your article, about which APIs are painful. Care to add any?
    - dmitriid 9y ago
      This article: https://medium.com/@emilrmoeller/grow-with-the-browser-learn-web-component-fundamentals-86c2b1c8ac08 https://medium.com/@emilrmoeller/grow-with-the-browser-learn... “To do this automatically” is followed by dosens of lines of tedious bolierplate. And that’s for a single most common use case of adding a property, and an attribute that are synced. It’s then followed by yet more boilerplate for adding a custom event. A lot of stuff here: https://jeremenichelli.io/2017/10/the-web-components-experience/ https://jeremenichelli.io/2017/10/the-web-components-experie... To quote: To achieve pretty basic mutations on small components, children references and data manipulation there’s a lot of heavy lifting that really compromises the developer experience. And it’s a big deal, since developer experience is one of the reasons why React or Vue are widely used in production. Also, web components being included in a magical global store difficults declarative and deterministic views or any other concept which hangs on a visual map of dependencies like code splitting. UNFORTUNATELY THE DEVELOPER EXPERIENCE OF BUILDING AN APPLICATION WITH WEB COMPONENTS TODAY IS QUITE PAINFUL SAM SACCONE —- end quote —-
      - spankalee 9y ago
        I replied in general below, but I'll take some extra time to respond to the complaint about getters and setters. Any JavaScript class that wants to define observable properties has to define a getter/setter pair. Manually, this usually looks like this: class C { get foo() { return this._foo; } set (foo(v) { this._foo = v; this._somethingChanged(); } } From the part of the article you reference, you're complaining that Web Components don't "solve" observable properties. This is because in JavaScript there are already ways to do this with with getters, setters, Object.defineProperty, and while that does involve some amount of "boilerplate" there are helpers for both Web Components and plain classes that will create these properties for you. I really don't see why it's a valid criticism of Web Components that they don't magically solve this problem when it's just the way JavaScript works. Of course frameworks like Angular solve this problem by generating accessors for you - but so does every major Web Components library. They all include some way of letting an author declare observable properties and syncing them with attributes. Given that the end result in DX is exactly the same as with other frameworks, why the ding on Web Components? Why are Web Components held to a higher standard and expected to "fix" JavaScript? To show how absolutely easy this is, and how off-base the DX complain is, here's how easy a Polymer 2 + TypeScript element is (TypeScript just to use decorators, which will be standards JS someday...) class MyElement extends Polymer.Element { @property({notify: true, reflect: true}) foo: number; } That will create an observable property, fire a "foo-changed" event and set the "foo" attribute when it changes, and listen for the "foo" attribute and deserialize it to the foo property when the attribute is set. Even without decorators, this is pretty damn easy to do, and the first thing any Polymer developer learns: class MyElement extends Polymer.Element { properties = { foo: {type: Number, notify: true, reflect: true} } } Other Web Components libraries like Skate and Stencil include their own way of declaring properties, just like other frameworks like Angular and Ember do. The second article is also comparing raw Web Components with no helpers to a framework that's full of helpers. You could just as easily saw JavaScript has a broken DX if you tried to do React-style components without React. The higher expectation for Web Components here is kind of ridiculous, to be honest.
- dmitriid 9y ago
  > But I don't really get the "Web Components APIs are unpleasant" line of criticism. The WC APIs are just ... dozens of lines of tedious boilerplate for the most basic things like “create a property, and an attribute, and a custom event” The sad thing is that WebComponents proponents are absolutely blind to the fact that WebComponents API is complete and utter crap. Well, most proponents don’t propose WebComponents. They propose Polymer.
  - spankalee 9y ago
    > create a property This is a criticism of Objects, not Web Components, and most framework/component libraries out there assists in creating properties that can be observed, from Ember to Angular to Polymer. That Web Components don't solve a problem that applies to the whole of JavaScript, but Web Components libraries do, does not seem like a very serious criticism to me. > and an attribute Adding an attribute name to `observedAttributes` and listening for the change in `attributeChanged` callback is not very onerous, and similar to frameworks that have attributes callbacks. How else do you propose listening to an attribute? Regardless, and again, libraries help do this small bit for you, and combine it with a property for a single, declarative property/attribute definition. > and a custom event "Defining" a custom event is as simple as firing it, and since they're standard DOM events, if you find the CustomEvent/dispatchEvent API too difficult to use, you could write or use a small helper. I'm not totally sure what it would do, since those APIs are so simple. And yet again, libraries like Polymer include firing events when properties change as a declarative option, to make it even simpler. I know you have a major axe to grind with Web Components on Twitter. I'm not sure what set you off about them, and I know I won't change your mind. I only responded for other readers here.
- nawitus 9y ago
  "Polymer's API _is_ the Web Components API, with some helpers added for reacting to property changes, augmenting templating and a few others." For that reason I think they're different APIs, even though Polymer's API can be considered a superset of the Web Components API.
nobleach 9y ago
What's the download tariff on Polymer vs React (I'll admit, I haven't checked library sizes for polymer since 2014) Do they allow for this 150k initial bundle?
- floatboth 9y ago
  It's pretty small. I'm working on an internal application using Polymer 3.0-rc1 currently, with some basic Paper elements (button, input, icon, spinner, tabs, app-route). The whole app bundle (made with rollup + babel-minify) is ~90k gzipped, ~200k uncompressed.

spankalee 9y ago

Polymer's API _is_ the Web Components API, with some helpers added for reacting to property changes, augmenting templating and a few others. Polymer is simply a base class for your elements that sits between HTMLElement and your component class. But I don't really get the "Web Components APIs are unpleasant" line of criticism. The WC APIs are just the element constructor, connectedCallback, disconnectedCallback, attributeChangedCallback and what methods and properties you define on your component. These lifecycle methods are nearly identical to what you get in React and just about every other framework. If those don't have unpleasant APIs, Web Components don't.

dfabulich 9y ago
Author here. It's not just me saying that Web Components are unpleasant. In the article, I linked to Sam Saccone of Google saying that the WC developer experience is significantly worse than React's developer experience. https://twitter.com/samccone/status/914528725852663808 https://twitter.com/samccone/status/914528725852663808 "This of course is coming from someone who has used web components every work day for the last 2 years. Hard to ignore the DX gap that exists." To which Alex Russell, also of Google and one of the architects of the WC API, replies, "Who's ignoring it?" There are certainly some developers who compare and contrast Polymer and React and prefer Polymer, but it's fair to say that the vast majority of developers who have made this comparison have preferred React's developer experience. Even Polymer's advocates seem to be holding their nose and using it because they appreciate the long-term promise of Web Components interop. Why? It's hard to say exactly, but I think it has to do with React's guarantees that the UI will be a pure function of state. Lots of nifty React features emerge from that. Polymer components make no such guarantees. I'm actually pretty enthusiastic about lit-HTML as a way to close the gap. We'll see how it goes.
- spankalee 9y ago
  Sam's tweet has no specifics, neither does your article, about which APIs are painful. Care to add any?
  - dmitriid 9y ago
    This article: https://medium.com/@emilrmoeller/grow-with-the-browser-learn-web-component-fundamentals-86c2b1c8ac08 https://medium.com/@emilrmoeller/grow-with-the-browser-learn... “To do this automatically” is followed by dosens of lines of tedious bolierplate. And that’s for a single most common use case of adding a property, and an attribute that are synced. It’s then followed by yet more boilerplate for adding a custom event. A lot of stuff here: https://jeremenichelli.io/2017/10/the-web-components-experience/ https://jeremenichelli.io/2017/10/the-web-components-experie... To quote: To achieve pretty basic mutations on small components, children references and data manipulation there’s a lot of heavy lifting that really compromises the developer experience. And it’s a big deal, since developer experience is one of the reasons why React or Vue are widely used in production. Also, web components being included in a magical global store difficults declarative and deterministic views or any other concept which hangs on a visual map of dependencies like code splitting. UNFORTUNATELY THE DEVELOPER EXPERIENCE OF BUILDING AN APPLICATION WITH WEB COMPONENTS TODAY IS QUITE PAINFUL SAM SACCONE —- end quote —-
    - spankalee 9y ago
      I replied in general below, but I'll take some extra time to respond to the complaint about getters and setters. Any JavaScript class that wants to define observable properties has to define a getter/setter pair. Manually, this usually looks like this: class C { get foo() { return this._foo; } set (foo(v) { this._foo = v; this._somethingChanged(); } } From the part of the article you reference, you're complaining that Web Components don't "solve" observable properties. This is because in JavaScript there are already ways to do this with with getters, setters, Object.defineProperty, and while that does involve some amount of "boilerplate" there are helpers for both Web Components and plain classes that will create these properties for you. I really don't see why it's a valid criticism of Web Components that they don't magically solve this problem when it's just the way JavaScript works. Of course frameworks like Angular solve this problem by generating accessors for you - but so does every major Web Components library. They all include some way of letting an author declare observable properties and syncing them with attributes. Given that the end result in DX is exactly the same as with other frameworks, why the ding on Web Components? Why are Web Components held to a higher standard and expected to "fix" JavaScript? To show how absolutely easy this is, and how off-base the DX complain is, here's how easy a Polymer 2 + TypeScript element is (TypeScript just to use decorators, which will be standards JS someday...) class MyElement extends Polymer.Element { @property({notify: true, reflect: true}) foo: number; } That will create an observable property, fire a "foo-changed" event and set the "foo" attribute when it changes, and listen for the "foo" attribute and deserialize it to the foo property when the attribute is set. Even without decorators, this is pretty damn easy to do, and the first thing any Polymer developer learns: class MyElement extends Polymer.Element { properties = { foo: {type: Number, notify: true, reflect: true} } } Other Web Components libraries like Skate and Stencil include their own way of declaring properties, just like other frameworks like Angular and Ember do. The second article is also comparing raw Web Components with no helpers to a framework that's full of helpers. You could just as easily saw JavaScript has a broken DX if you tried to do React-style components without React. The higher expectation for Web Components here is kind of ridiculous, to be honest.
dmitriid 9y ago
> But I don't really get the "Web Components APIs are unpleasant" line of criticism. The WC APIs are just ... dozens of lines of tedious boilerplate for the most basic things like “create a property, and an attribute, and a custom event” The sad thing is that WebComponents proponents are absolutely blind to the fact that WebComponents API is complete and utter crap. Well, most proponents don’t propose WebComponents. They propose Polymer.
- spankalee 9y ago
  > create a property This is a criticism of Objects, not Web Components, and most framework/component libraries out there assists in creating properties that can be observed, from Ember to Angular to Polymer. That Web Components don't solve a problem that applies to the whole of JavaScript, but Web Components libraries do, does not seem like a very serious criticism to me. > and an attribute Adding an attribute name to `observedAttributes` and listening for the change in `attributeChanged` callback is not very onerous, and similar to frameworks that have attributes callbacks. How else do you propose listening to an attribute? Regardless, and again, libraries help do this small bit for you, and combine it with a property for a single, declarative property/attribute definition. > and a custom event "Defining" a custom event is as simple as firing it, and since they're standard DOM events, if you find the CustomEvent/dispatchEvent API too difficult to use, you could write or use a small helper. I'm not totally sure what it would do, since those APIs are so simple. And yet again, libraries like Polymer include firing events when properties change as a declarative option, to make it even simpler. I know you have a major axe to grind with Web Components on Twitter. I'm not sure what set you off about them, and I know I won't change your mind. I only responded for other readers here.
nawitus 9y ago
"Polymer's API _is_ the Web Components API, with some helpers added for reacting to property changes, augmenting templating and a few others." For that reason I think they're different APIs, even though Polymer's API can be considered a superset of the Web Components API.

nobleach 9y ago

What's the download tariff on Polymer vs React (I'll admit, I haven't checked library sizes for polymer since 2014) Do they allow for this 150k initial bundle?

floatboth 9y ago
It's pretty small. I'm working on an internal application using Polymer 3.0-rc1 currently, with some basic Paper elements (button, input, icon, spinner, tabs, app-route). The whole app bundle (made with rollup + babel-minify) is ~90k gzipped, ~200k uncompressed.