|
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) |