Re:Ask HN: What are the cons of Google Polymer?
by danabramov on Sunday May 08, 2016 @08:13PM
(#11656725)
>Unlike [my perception of] React or Angular, you can use Polymer a bit without going all in.
For what it’s worth, you can integrate React in your existing Backbone/Ember/Angular/etc app one component at a time. At my previous company, we have been doing this over the course of a year while shipping new features thanks to the interactivity React enabled.
Ryan Florence gave a talk about integrating React into an existing app: https://www.youtube.com/watch?v=BF58ZJ1ZQxY
Re:Ask HN: What are the cons of Google Polymer?
by PixelsCommander on Tuesday May 10, 2016 @05:48AM
(#11666064)
This is even easier with polymer or web components since you can use them in any template or jsx as simple as you put there regular HTML tags
A few commenters mentioned poor browser support, but we haven't experienced any problems other than IE<=10.
In many ways Polymer is just a shim for the WebComponents spec with data binding added in, along with a standard library of web components. The resulting framework-style is basically plain-JS/HTML with a la carte use of Web Components where appropriate. Unlike [my perception of] React or Angular, you can use Polymer a bit without going all in. (Ironically the one thing you can't currently do is mix Polymer Elements from Source A with Polymer Elements from Source B at runtime if they have common, but separately hosted, dependencies).
WebComponents feel a bit like Java swing, in that making HelloWorld is high overhead, but once you've got a nice toolbox of components going, you can pull them out and use them flexibly. This is not unlike React components, except Polymer/WebComponents use an HTML-centric definition format while React uses a JS-centric definition format.