| It seems as if you are a bit misguided about Polymer. I recommend that you take a look at a Polymer 2 element instead of a Polymer 1 element: https://www.polymer-project.org/2.0/start/first-element/step... The reason you have to define what an element 'is' is for backwards-compat reasons. Additionally, the properties definition block is there simply for attribute -> property serialization so that you can set properties declaratively in the HTML as attributes. The property declaration is also used for tooling schema enforcement just as you suggested it should really be there for. You do not need a properties block at all since Polymer uses webcomponents, and as you said, elements can handle arbitrary attributes (and attributes set in JS with the exception of the data- attributes [1]). In Polymer 2, you simply set the function hook just like you wanted. Polymer 3 which is essentially just a refactoring of Polymer 2 introduces JS Modules. An example would be: import {Polymer} from 'pathToPolymer';
export class IconToggle extends Polymer.Element {
static get is() { return 'icon-toggle' }
observedAttributes() { return ['toggleIcon'] }
attributeChangedCallback(name, old, new) { if(name === 'toggleIcon') {...} }
connectedCallback() { super.connectedCallback(); this.addEventListener('pressed', this.onPressed.bind(this)); }
onPressed(evt) { this.pressed = !this.pressed; }
}
customElements.define(IconToggle.is, IconToggle);
This example, does not use the properties but the native attributeChangedCallback [2], it does not explicitly define properties and it can still set this.pressed, and you can easily add a 'cats' attribute if you want which can then be accessed via this.getAttribute('cats') like any other native element. Polymer is written so that all the code is executable in the browser even with the JSX-like template syntax [3]. But with the move to JS modules, a webpack configuration can easily add extra functionality like not even having to define the event listeners or the observed attributes.[1] https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement... [2] https://developer.mozilla.org/en-US/docs/Web/Web_Components/... [3] https://www.youtube.com/watch?v=ruql541T7gc |
Polymer 2 looks better than polymer 1 for sure, but if I'm comparing what I need to write in React vs. Polymer 2, the former still beats out the latter in terms of low effort, high productivity.
And to be clear: the reason I think (and the numbers bear out that) React and Vue etc. beat out Polymer still is because they can do the same things as polymer: the on-page result is identical. Except React and Vue offer a better dev experience... provided you buy into the development model, of course. But this is also true for people who first start with Polymer: they have to buy into the idea that the classic web stack is the best solution to the problem of needing custom components.
And that reveals the major difference, in turn revealing another reason why Polymer is not as popular as one might hope: Polymer is a web presentation and interaction technology, whereas for instance React is a universal UI technology. They're not even remotely the same thing: the latter is effectively a superclass of the former. For example, as long as you call the functions that React tells you need to be used to effect UI updates, you will never have to think about "where this code runs". Web? Mobile? Desktop? Someone's GTK+ application on embedded hardware with JS support? It literally doesn't matter: call the functions, and it will work. The fact that the DOM is used in the browser is pretty much irrelevant to React - it's only relevant to devs who want to explicitly tie their UI to APIs that are only available in a browser. Polymer takes an approach that is diametrically opposite to this: it keeps things as "webby" as possible, making you write DOM, and only DOM, elements.
So that is another reason for the difference in dev experience: React has abstracted as much as possible so as to only expose what you need because it wouldn't be able to do its job as UI technology if it kept exposing platform-specific construct, whereas Polymer can keep things explicitly tied to the browser stack, and thus never got pushed to be as self-contained as possible, with as high a productivity:effort ratio.
(and whether that's a good or bad decision is irrelevant when discussing 'why is one of these more/less popular than the other', even if I certainly have opinions there. I'd love for React to be more webby, like polymer, but if it was, it would be much clunkier)