3 ms·
You're disingenuous, so this will be my only response: In your first example you have code for using raw Web Components, and presumably it's "bad" user experie
by spankalee 9y ago
You're disingenuous, so this will be my only response:
In your first example you have code for using raw Web Components, and presumably it's "bad" user experience compared to a framework that generates this code for you. It's not a valid comparison.
Either compare a Web Components library, like Polymer, Skate, or Stencil, that generates this code for you against a framework, or compare raw Web Components against raw JavaScript without a framework. You'll find that making state observable and syncing it across attributes will require even more code than Web Components.
In your second example you're showing a high-level declarative API, that has opinions about property name to attribute name to event name mapping, includes a format for per-property meta-data, options for triggering observer methods, whether or not to sync attributes, and how to deserialize from attributes.
There's no way that level of API and opinion are appropriate for the underlying platform, which has to be responsible first for the capabilities of the system, the low-level hooks, and how the components interoperate with the host and other components. Higher-level libraries can automatically implement the hooks with opinions.
Even in raw JavaScript, it takes boilerplate to make an observable property, and libraries can generate that for you. Why are you holding Web Components to a higher standard than JavaScript?
- dmitriid 9y ago> Even in raw JavaScript, it takes boilerplate to make an observable property, and libraries can generate that for you. Why are you holding Web Components to a higher standard than JavaScript? Because WebComponents are not raw Javascript. It’s an API. There’s nothing stopping you from providing an API with good DX. Except one fact: you are entirely blind to the fact that WebComponent API is bad. It’s also funny how you call me disingenuous when your line of defence is “DX criticism is invalid because see how easy it is with Polymer”. If for every single point your answer is “use polymer/helper”, it only means one thing: the API is bad, and you don’t care.
- rictic 9y agoI think ya'll are kinda talking past each other, and you may agree more than it appears. The DX for raw web components, without any library, is awkward and verbose to handle observing changes well. I think the point of departure is that we (Polymer) see this as a problem that's true of all JS, not just Web Components, and it would be better to solve it for all JS through a mechanism like decorators, which is going through the standards process now and we're big supporters of it. So, yes, creating getters and setters and observing changes is awkward. Yes we should fix it for web components, but the best place to do that is to fix it is actually at the javascript level, which is in process! :D