3 ms·

In what messier way exactly? Do you have any specifics? The component models are largely analogous. React and Vue could use custom elements if they chose to.

TheRealPomax 9y ago
Developer usability: the fact that they're largely analogous is literally why the implementations that stick to one language, taking advantage of new language features as they pop up, and abstract away all the bindings, win out over something like Polymer, which sticks to the separation of HTML, CSS, and JS. React, for instance, has changed a lot since its first release, mostly to do what devs need it to do with a bare minimum of coding on their part. That is in stark contrast to Polymer, which requires devs to write out a lot of the logic that you simply get "for free" with React. Writing a pure JS class that "just works" just because it has the two words "extends Component" is a hugely winning benefit, for example. Take something like https://codelabs.developers.google.com/codelabs/polymer-first-elements/index.html?index=..%2F..%2Findex#5 https://codelabs.developers.google.com/codelabs/polymer-firs... - it certainly does the job, the code is clean, and the separation of concern follows the traditional HTML/CSS/JS model. But as a developer, what I see is an inefficient implementation that requires me to put loads of stuff in that should be taken care of for me: "Why would you need to say what my component 'is'? Tooling should see that already.". Also, all browsers already handle arbitrary properties, so "Why would you need say which properties can be used, except for schema enforcement". (if I say <div cats="yes"> then every browser already sets that attribute key:value correctly). And of course: "Why would you need to specify which events to listen to instead of just implementing the relevant function hook? Tooling should take care of the rest". So what I _want_ to write as a developer who's used to efficient web-component-like libraries is something like: import { register, Component } from 'polymer' register('icon-toggle', class IconToggle extends Component { onAttributeChange(attr) { if (attr.name === 'toggleIcon') { ... } } onPressed(evt) { this.pressed = !this.pressed; } }); And we're done, that should tell the library everything it needs to know. It really is just a matter of "what lets me do the most while saying the least". Polymer requires me to write a book where React or Vue let me write a memo. Does it make it harder for a search engine to index my site? Sure. But that's what seo/og is for. Does it make it harder for a user to inspect-element? Sure, but that's their problem, not mine. Does it make it harder for someone else to learn how I did something if I don't host the code on github or something? Sure, but I am under no obligation to write code that, in production, is easy to debug and replicate. So while Polymer is super strong for all of those, realistically: I only care at the academic level, because that's not where my time and efforts lie.
- e111077 9y ago
  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-4 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/dataset https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement... [2] https://developer.mozilla.org/en-US/docs/Web/Web_Components/Custom_Elements#Observed_attributes https://developer.mozilla.org/en-US/docs/Web/Web_Components/... [3] https://www.youtube.com/watch?v=ruql541T7gc https://www.youtube.com/watch?v=ruql541T7gc
  - TheRealPomax 9y ago
    As a dev, comparing technologies given that I've already used Vue and React, I still see lots of code that I've become accustomed to not needing to specify, making even Polymer 2 still feel clunky and bloated: there is still no reason for that "is()" or "observedAttributes()" (tooling should take care of that), and the fact that you manually need to initiate the super chain in connectedCallback instead of having a side call to a function with a name that indicates what it's actually for, with the chain taken care of by the super class (if your callback function has the word "callback" in it, that's already a wasted 8 characters that could have been used to actually name the function after what it does) still makes me go "this is silly, why would I go back to such a verbose technology?". 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)

TheRealPomax 9y ago

Developer usability: the fact that they're largely analogous is literally why the implementations that stick to one language, taking advantage of new language features as they pop up, and abstract away all the bindings, win out over something like Polymer, which sticks to the separation of HTML, CSS, and JS. React, for instance, has changed a lot since its first release, mostly to do what devs need it to do with a bare minimum of coding on their part. That is in stark contrast to Polymer, which requires devs to write out a lot of the logic that you simply get "for free" with React. Writing a pure JS class that "just works" just because it has the two words "extends Component" is a hugely winning benefit, for example. Take something like https://codelabs.developers.google.com/codelabs/polymer-first-elements/index.html?index=..%2F..%2Findex#5 https://codelabs.developers.google.com/codelabs/polymer-firs... - it certainly does the job, the code is clean, and the separation of concern follows the traditional HTML/CSS/JS model. But as a developer, what I see is an inefficient implementation that requires me to put loads of stuff in that should be taken care of for me: "Why would you need to say what my component 'is'? Tooling should see that already.". Also, all browsers already handle arbitrary properties, so "Why would you need say which properties can be used, except for schema enforcement". (if I say <div cats="yes"> then every browser already sets that attribute key:value correctly). And of course: "Why would you need to specify which events to listen to instead of just implementing the relevant function hook? Tooling should take care of the rest". So what I _want_ to write as a developer who's used to efficient web-component-like libraries is something like: import { register, Component } from 'polymer' register('icon-toggle', class IconToggle extends Component { onAttributeChange(attr) { if (attr.name === 'toggleIcon') { ... } } onPressed(evt) { this.pressed = !this.pressed; } }); And we're done, that should tell the library everything it needs to know. It really is just a matter of "what lets me do the most while saying the least". Polymer requires me to write a book where React or Vue let me write a memo. Does it make it harder for a search engine to index my site? Sure. But that's what seo/og is for. Does it make it harder for a user to inspect-element? Sure, but that's their problem, not mine. Does it make it harder for someone else to learn how I did something if I don't host the code on github or something? Sure, but I am under no obligation to write code that, in production, is easy to debug and replicate. So while Polymer is super strong for all of those, realistically: I only care at the academic level, because that's not where my time and efforts lie.

e111077 9y ago
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-4 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/dataset https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement... [2] https://developer.mozilla.org/en-US/docs/Web/Web_Components/Custom_Elements#Observed_attributes https://developer.mozilla.org/en-US/docs/Web/Web_Components/... [3] https://www.youtube.com/watch?v=ruql541T7gc https://www.youtube.com/watch?v=ruql541T7gc
- TheRealPomax 9y ago
  As a dev, comparing technologies given that I've already used Vue and React, I still see lots of code that I've become accustomed to not needing to specify, making even Polymer 2 still feel clunky and bloated: there is still no reason for that "is()" or "observedAttributes()" (tooling should take care of that), and the fact that you manually need to initiate the super chain in connectedCallback instead of having a side call to a function with a name that indicates what it's actually for, with the chain taken care of by the super class (if your callback function has the word "callback" in it, that's already a wasted 8 characters that could have been used to actually name the function after what it does) still makes me go "this is silly, why would I go back to such a verbose technology?". 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)