8 ms·

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 experien

• 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.
      • dfabulich 9y ago
• floatboth 9y ago
  > Even Polymer's advocates seem to be holding their nose and using it because they appreciate the long-term promise of Web Components interop. Bullshit. Polymer's developer experience is absolutely my favorite, since version 1.0. Importantly, Polymer does not require any build tools. lit-html is neat but there's nothing wrong with the current Polymer.Templatizer system in terms of developer experience.