4 ms·

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.
  - dfabulich 9y ago
    > 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. IMO, React feels better and more productive in part because it doesn't have/need observables. It's the difference between a UI in "retained mode" and "immediate mode."
  - dmitriid 9y ago
    > Javascript > you complain about objects > don't magically solve > raw WCs vs helpers etc. etc. etc. And then you wonder why I'm so set against WebComponents. Because you (and Rob Dodson and other WebComponent proponents) are entirely blind to how bad WebComponent APIs are. I dunno, maybe your goal isn't to "sell" WebComponents, but to sell Polymer. WebComponent API is bad not because "we complain about how Javascript objects are". We complain because WebComponents API is horrendously bad, and that was a deliberate design choice. Current line of defence is "oh, it's just low level API" or "oh, it's just how Javascript is", both of which are at best patently false. Here's code to create one single property with one single synced attribute. One. single. property/attribute pair. One. set transitionDuration(value) { this.setAttribute('transition-duration', value); } get transitionDuration() { return this.getAttribute('transition-duration'); } static get observedAttributes() { return ['transition-duration']; } attributeChangedCallback(name, oldVal, newVal) { if (name === 'transition-duration') { // do something } } There is no reality where this is good API design. There is no reality where "this is how objects work in Javascript" is an excuse. This is objectivly bad API design. Bad developer experience. However, you and all other webcomponent proponents completely ignore this fact, and dismiss any and all complaints out of hand. Of course you do. You've got Polymer to promote [1]. If WebComponents had better APIs, there would be no need for Polymer, would there. Because here's how Polymer solves the problem, despite this being "oh, that's how Javascript works". static get properties() { return { transitionDuration: { type: Number, readOnly: false, reflectToAttribute: true, observer: 'methodName' } } } Oh. My. God. This is doable without any excuses about how Javascript works? Really? Who would've thunk it? [1] Hell, even in your "rebuttal" of criticism towards WebComponents here's what you write: > 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 Were we talking about the bad DX of Polymer? No. You are totally entirely absolutely blind to the fact though. Because in your mind WebComponents === Polymer. And, sadly, for all intents and purposes it's true. edit: removed some erroneously pasted code

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.
- dfabulich 9y ago
  > 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. IMO, React feels better and more productive in part because it doesn't have/need observables. It's the difference between a UI in "retained mode" and "immediate mode."
- dmitriid 9y ago
  > Javascript > you complain about objects > don't magically solve > raw WCs vs helpers etc. etc. etc. And then you wonder why I'm so set against WebComponents. Because you (and Rob Dodson and other WebComponent proponents) are entirely blind to how bad WebComponent APIs are. I dunno, maybe your goal isn't to "sell" WebComponents, but to sell Polymer. WebComponent API is bad not because "we complain about how Javascript objects are". We complain because WebComponents API is horrendously bad, and that was a deliberate design choice. Current line of defence is "oh, it's just low level API" or "oh, it's just how Javascript is", both of which are at best patently false. Here's code to create one single property with one single synced attribute. One. single. property/attribute pair. One. set transitionDuration(value) { this.setAttribute('transition-duration', value); } get transitionDuration() { return this.getAttribute('transition-duration'); } static get observedAttributes() { return ['transition-duration']; } attributeChangedCallback(name, oldVal, newVal) { if (name === 'transition-duration') { // do something } } There is no reality where this is good API design. There is no reality where "this is how objects work in Javascript" is an excuse. This is objectivly bad API design. Bad developer experience. However, you and all other webcomponent proponents completely ignore this fact, and dismiss any and all complaints out of hand. Of course you do. You've got Polymer to promote [1]. If WebComponents had better APIs, there would be no need for Polymer, would there. Because here's how Polymer solves the problem, despite this being "oh, that's how Javascript works". static get properties() { return { transitionDuration: { type: Number, readOnly: false, reflectToAttribute: true, observer: 'methodName' } } } Oh. My. God. This is doable without any excuses about how Javascript works? Really? Who would've thunk it? [1] Hell, even in your "rebuttal" of criticism towards WebComponents here's what you write: > 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 Were we talking about the bad DX of Polymer? No. You are totally entirely absolutely blind to the fact though. Because in your mind WebComponents === Polymer. And, sadly, for all intents and purposes it's true. edit: removed some erroneously pasted code