What are differences between Polymer and React?
386 views
Skip to first unread message
andreas...@hotmail.de
Sep 21, 2015, 12:27:10 AM9/21/15
to Polymer
Hi guys, I've been using Polymer for a while, pretty much just with the elements from the catalog. In terms of production readiness I don't feel too happy with Polymer in terms of compatibility and performance but I still want to consider it for our next crucial startup project. We currently have a site that's built just on bootstrap because we wanted to quickly get an MVP out to customers. Now we intend to componentize everything and we're looking at two options: React and Polymer.
The thing is, I have no idea how Polymer and React really differ and what the pros and cons are. What I'd like to get an emphasis on is the developer experience and outlook for the next years from now. Eric Bidelman made a public post recently calling React "one of many frameworks" that come and go. I understand the point he was trying to make by saying React is simply one of the currently hot frameworks and it might vanish, whereas Polymer tries to push webcomponents forward so we can all benefit from the same components. But what if React will eventually support webcomponents, what are the differences? Or more so, are we even going to write Polymer components in two years from now? Polymer intend to make webcomponents possible in a time where they are not yet ready to be used in every browser. On top of that it adds sugar coating to make developing webcomponents easier, right? Does that mean Polymer will eventually disappear? If I write webcomponents with Polymer, are those components eventually usable without Polymer?
What are the pros and cons over using Polymer and React? I don't know that much about both in terms of how they keep and transfer states, I just know that React keeps everything in one component and keeps all its states in each component which seems to make it easy to set and retrieve the state of a component. With Polymer it seems to be similar, right? All the states are in the components which I retrieve via selecting the element and checking for a certain property. Is this how it works in React? What are the differences with data binding? There are many things I unfortunately don't understand about both of them. Personally I really like Polymer so far but I am not sure how production ready it really is. That's why React is under consideration, although I've never touched it and I don't know how long it is about to stay. However, React components work reliably in most browsers (without bad performance?)
If you would try to give me an as objective as possible explanation what speaks for and against both Polymer and React, what would it be?
Eric Bidelman
Sep 21, 2015, 4:28:49 AM9/21/15
to Andreas Galster, Polymer, Arthur Evans
This is a long post with a lot of questions :) Can we start by addressing performance? What are your concerns?
Added Arthur to the thread. Some of the 0.5 material is still pretty good. There's not a definitive place on the web where users can learn about the benefits of web components.
Meanwhile, please do some research on the topics. There are a few decent articles comparing the component models, including a couple of 0.5 articles that discuss the benefits of web components:
Understanding Polymer: https://www.polymer-project.org/0.5/docs/start/everything.html
Understanding Web Components: https://www.polymer-project.org/0.5/platform/custom-elements.html
Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/ddf0cefe-5dfa-4187-bdf7-2ad3d91f8602%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
andreas...@hotmail.de
Sep 21, 2015, 5:02:52 AM9/21/15
to Polymer, andreas...@hotmail.de, art...@google.com
Hi Eric, thanks for those links, reading over those. I've read over a few of those before but even the bottom one didn't really clearly let me understand how developing with both differs. Anyway, I'll do some more reading before commenting on this.
As for performance, sadly by having to use the shadow dom polyfill instead of shady dom (due to using meteor) the CPU usage is pretty high. I have a really expensive workstation laptop but using a site with just a few Polymer custom elements really kills the performance. Even just scrolling a site is really sluggish on Firefox or IE (not sure about Safari). The slowdown is far too much to really launch a site completely built with Polymer as the view layer :(
Eric Bidelman
Sep 21, 2015, 5:25:55 AM9/21/15
to andreas...@hotmail.de, Polymer, art...@google.com
Ah, so more stuff going on than meets the eye :)
FWIW, we developed the I/O site (events.google.com/io2015/) in 0.5 this year and didn't experience any scrolling issues. That also used the full shadow dom polyfill.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/13e6fb8d-f6ba-44c0-8702-b2ab2d0c16d1%40googlegroups.com.
andreas...@hotmail.de
Sep 21, 2015, 5:47:20 AM9/21/15
to Polymer, andreas...@hotmail.de, art...@google.com
I don't think scrolling itself is the issue. I think it's just draining the CPU too much. What should I send? Just a small part of the app like one page perhaps?
What's also not really clear now after reading some of the articles: Why would I use Polymer when in the future React will use native webcomponents? It has the virtual dom, so in that sense it should be superior compared to Polymer + React has been used in production for a long time already. Polymer is at the stage that developers from meteor even say they think it's not mature enough which is why they don't consider a tight integration into meteor yet. If both libraries support webcomponents natively, which apparently won't be much longer since shadow dom development is starting with other browsers right now, how are they still different from each other?
Max
Sep 21, 2015, 1:15:39 PM9/21/15
to Polymer
You raise interesting questions.
Anyway, those are my thoughts. I doubt that helped at all, but I've been trying to answer this question too, and this is where I am with the answer :)
I attended the Polymer Summit, and found a few of the talks quite useful, but I suppose this one helped the most with this specific issue :
<https://www.youtube.com/watch?v=ZDjiUmx51y8>
I, too, intend to read the links Eric gave and further refine my own view.
Regards,
I consider Polymer and React different on a rather more fundamental level. I could well be wrong in my thoughts and comments, so please correct me if I am - prefix everything with 'IMO' ;)
React (like all frameworks) is trying to get around deficiencies in the browsers, and does so by drawing the developer into their own world and dictating how things should be done. They make optimisations and do things in such a way that performance is good (excellent even?), essentially by moving functionality from the browser to the framework. There is much validity to doing this, and the rewards are real (so I'm told). However, they do remove the focus from the browser to the framework, and so you become reliant of the framework developers rather than the developers working on the browsers, and the standards they're pushing forwards.
Though Polymer isn't really a framework, it *can* be used that way simply by decomposing an application into bits, and defining what those bits do. It looks a bit like a framework sometimes, but unlike actual frameworks, there's nothing to define how you should do anything on an application architecture level. IINM, the 'recommended' way to use Polymer seems to be to decompose your application into HTML elements, bits that can be used anywhere and are self-contained/independent, much like any of the built-in elements (this also makes them more easily testable). I see it as moving the 'Object Orientation' from JavaScript back into HTML - it seems like most JS frameworks are doing the opposite.
Making HTML elements makes building applications much simpler since you don't really need to know anything more than the base skills (mostly just HTML) and so designers can build whole apps using the elements. To make Polymer elements, of course, you need to use JavaScript, and things can get quite complicated, and that's where the s/w developers come in; but this is, to a large extent, all hidden from the outside behind the API (attributes, events and properties).
So, you seem to suggest that adopting React is a better bet since they will eventually do Web Components too, so will React be the one true framework? It is likely you won't need to make custom elements in Polymer (if that isn't already true), but I doubt everyone will end up using React. I imagine things will be learned from it, of course, but the trend is probably that those things learned will be merged into browsers such that that 'feature' of React will become redundant. With Polymer, though, there is at least the *intention* that they should work anywhere, in any framework, React included, and also with *no* framework (ie the DOM is the framework)..it's not quite there yet, imo, but it's quite a different focus/intent than React. No, not everyone will end up using Polymer, but they should be able to if they want, without it impacting any of the other choices they make.
I can't speak for anyone but myself, but I can see why browsers might not like frameworks such as React, and that is because they take away 'control' from the browser, to varying extents. React takes it away quite a lot, IMO, but some just seem to move control from the HTML and CSS parsers to the JS engine. Doing so might get around slowness in the DOM/etc, but they also mean that improvements made in the browsers have a reduced effect. Instead, all the improvements that have effects are in the framework, and perhaps also in the JS engine (or even server-side).
Though Polymer isn't really a framework, it *can* be used that way simply by decomposing an application into bits, and defining what those bits do. It looks a bit like a framework sometimes, but unlike actual frameworks, there's nothing to define how you should do anything on an application architecture level. IINM, the 'recommended' way to use Polymer seems to be to decompose your application into HTML elements, bits that can be used anywhere and are self-contained/independent, much like any of the built-in elements (this also makes them more easily testable). I see it as moving the 'Object Orientation' from JavaScript back into HTML - it seems like most JS frameworks are doing the opposite.
Making HTML elements makes building applications much simpler since you don't really need to know anything more than the base skills (mostly just HTML) and so designers can build whole apps using the elements. To make Polymer elements, of course, you need to use JavaScript, and things can get quite complicated, and that's where the s/w developers come in; but this is, to a large extent, all hidden from the outside behind the API (attributes, events and properties).
So, you seem to suggest that adopting React is a better bet since they will eventually do Web Components too, so will React be the one true framework? It is likely you won't need to make custom elements in Polymer (if that isn't already true), but I doubt everyone will end up using React. I imagine things will be learned from it, of course, but the trend is probably that those things learned will be merged into browsers such that that 'feature' of React will become redundant. With Polymer, though, there is at least the *intention* that they should work anywhere, in any framework, React included, and also with *no* framework (ie the DOM is the framework)..it's not quite there yet, imo, but it's quite a different focus/intent than React. No, not everyone will end up using Polymer, but they should be able to if they want, without it impacting any of the other choices they make.
I can't speak for anyone but myself, but I can see why browsers might not like frameworks such as React, and that is because they take away 'control' from the browser, to varying extents. React takes it away quite a lot, IMO, but some just seem to move control from the HTML and CSS parsers to the JS engine. Doing so might get around slowness in the DOM/etc, but they also mean that improvements made in the browsers have a reduced effect. Instead, all the improvements that have effects are in the framework, and perhaps also in the JS engine (or even server-side).
One thing I often find myself doing is looking at the html that is output by a framework and seeing how easy it is to understand. Try looking at facebook's html...div..div...div. I can make some sense from a lot of the IDs and classes/etc, but not really very clear at all. Perhaps if I were more familiar with React, and/or I had designed the page, it would be clearer. If you look at the Polymer Summit page's source, yeah, there's a few divs in there too and I need to guess at their purpose from the IDs, but it seems to me to be much easier to read - on the whole, it just looks like a normal web page. Of course, the summit web site is much simpler than facebook, so it's not such a valid comparison (I wonder if there is something more substantial around), but I think it's a valid observation on the whole.
Anyway, those are my thoughts. I doubt that helped at all, but I've been trying to answer this question too, and this is where I am with the answer :)
I attended the Polymer Summit, and found a few of the talks quite useful, but I suppose this one helped the most with this specific issue :
<https://www.youtube.com/watch?v=ZDjiUmx51y8>
I, too, intend to read the links Eric gave and further refine my own view.
Regards,
Max.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/77602a50-71c7-4229-b2fe-918f079139d7%40googlegroups.com.
Sharma, Saurabh
Sep 21, 2015, 3:29:25 PM9/21/15
to Max, polymer-dev
My twenty cents/paise -
Firstly, Thanks Eric for such a good reply.:-)
The good 'common' thing in both React and Polymer for me is the re-usability promise and 'Components'/'Elements'.
The bad thing is the tussle and immensely opposite trajectory approach taken to solve the same fundamental problems of front-end code organization.
I follow both f/ws(if we can call them that) and like things from both. I loved the style encapsulation from Polymer 0.5.5, and hate the way re-learning needs to happen with reactJS wrt styles.
I love the way flux concepts can be put into practice with React at the view layer. But I absolutely don'y get the eagerness in getting away from the DOM for the react folks. What if, what they have done with v-DOM gets adopted into the modern browsers rendering behaviour.
Why shall we be learning an implementation level detail, and not focussing on what we have learnt as web developers all along. (The DOM is 'actually' a standard)
The most ideal scenario (again all this is IMHO) - What if React folks choose to help in developing and making the DOM faster rather than writing(and at the same time not writing) their own browser implementation. :-)
United we may achieve what we aim to.
Absolutely do not get the argument in "React's version of web components".
I do not think that is their aim - 'to bring the web to the Github'
I kept remembering the Object.observe evolution (over Object.watch and similar) and the multifold times performance boost it brought.
Putting simply - React will miss all such benefits - as it's on it's own path of browser improvements.
(Remember the Flipboard canvas based scrolling story also that later on Mozilla's changes proved futile)
So i think the 2 paths are clear -
Either you believe that Browsers will evolve and make all of polymer's proposals as it's native features
or
You believe that will never happen and Browser based working will be limited by a slow DOM, and hence jump on to a faster virtual DOM for better performance and without waiting for changes which might never happen.
It's a tough choice. And It's a good thing to be having such a choice. I for one enjoy having this choice and enjoy being part of both the camps. But believe what is standard will evolve and win with time.
The most interesting part of the battle for me though is going to be not web but the mobile
where a mobile web app (using polymer wrapped in cordova) competes against the react-native app(which looks super sleek and more performant as of now)
Firstly, Thanks Eric for such a good reply.:-)
The good 'common' thing in both React and Polymer for me is the re-usability promise and 'Components'/'Elements'.
The bad thing is the tussle and immensely opposite trajectory approach taken to solve the same fundamental problems of front-end code organization.
I follow both f/ws(if we can call them that) and like things from both. I loved the style encapsulation from Polymer 0.5.5, and hate the way re-learning needs to happen with reactJS wrt styles.
I love the way flux concepts can be put into practice with React at the view layer. But I absolutely don'y get the eagerness in getting away from the DOM for the react folks. What if, what they have done with v-DOM gets adopted into the modern browsers rendering behaviour.
Why shall we be learning an implementation level detail, and not focussing on what we have learnt as web developers all along. (The DOM is 'actually' a standard)
The most ideal scenario (again all this is IMHO) - What if React folks choose to help in developing and making the DOM faster rather than writing(and at the same time not writing) their own browser implementation. :-)
United we may achieve what we aim to.
Absolutely do not get the argument in "React's version of web components".
I do not think that is their aim - 'to bring the web to the Github'
I kept remembering the Object.observe evolution (over Object.watch and similar) and the multifold times performance boost it brought.
Putting simply - React will miss all such benefits - as it's on it's own path of browser improvements.
(Remember the Flipboard canvas based scrolling story also that later on Mozilla's changes proved futile)
So i think the 2 paths are clear -
Either you believe that Browsers will evolve and make all of polymer's proposals as it's native features
or
You believe that will never happen and Browser based working will be limited by a slow DOM, and hence jump on to a faster virtual DOM for better performance and without waiting for changes which might never happen.
It's a tough choice. And It's a good thing to be having such a choice. I for one enjoy having this choice and enjoy being part of both the camps. But believe what is standard will evolve and win with time.
The most interesting part of the battle for me though is going to be not web but the mobile
where a mobile web app (using polymer wrapped in cordova) competes against the react-native app(which looks super sleek and more performant as of now)
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CAMZCrPjm5NJjfv5o-400TOO-ckGt8a0tiKSkjjFU9Eh3c6nbNQ%40mail.gmail.com.
Aleks Totic
Sep 23, 2015, 12:27:59 AM9/23/15
to Polymer, andreas...@hotmail.de
My take (disclosure: met Polymer team, and helped them out). I've looked at React, but never used it in an interesting project.
Major difference is treatment of DOM: Polymer embraces DOM, React treats DOM as a compile target. From this, it follows:
- Polymer is easier to work with if you know DOM (developer productivity is higher)
- React can compile to native apps, Polymer can't.
- Web Components will last as long as browsers. React will not.
React is more mature (stability, bugs), and has been used publicly for a couple of years, Polymer 1.0 has been out for 4 months, there are still bugs in the core/iron. I run into a couple of interesting ones every week.
I've been helping people wrestling with this for a couple of months. My take:
- if you are shipping soon, pick the framework that's easiest to implement your app in. What are your devs happy with? Which one has the components you want? Is there a sample app that looks like what you are doing? Both frameworks will be fast enough.
- if you are writing a classic web app, something that you'll have to maintain for a long time, use Polymer. When both React and Polymer are gone, your migration path to the shiny new web components framework will be a lot easier with Polymer.
Aleks
Max
Sep 23, 2015, 2:59:05 AM9/23/15
to Polymer
> Polymer 1.0 has been out for 4 months, there are still bugs in the core/iron. I run into a couple of interesting ones every week.
Is that a fair comparison? I mean core/iron aren't actually Polymer....they're elements made *using* Polymer (PolymerElements).
Attempting to make this comparison raises additional questions. Do you run into bugs in Polymer *itself* every week? Does React have a similar set of 'official' elements/components that would make the comparison equivalent? Perhaps you're including the core/iron because the equivalent functionality is 'built-in' with React?
The overall point is true, of course - React has been 'tested' in the field more than Polymer and should, presumably, have fewer issues. That difference should reduce as we go forwards, perhaps exponentially as more and more people start using it.
Is that a fair comparison? I mean core/iron aren't actually Polymer....they're elements made *using* Polymer (PolymerElements).
Attempting to make this comparison raises additional questions. Do you run into bugs in Polymer *itself* every week? Does React have a similar set of 'official' elements/components that would make the comparison equivalent? Perhaps you're including the core/iron because the equivalent functionality is 'built-in' with React?
The overall point is true, of course - React has been 'tested' in the field more than Polymer and should, presumably, have fewer issues. That difference should reduce as we go forwards, perhaps exponentially as more and more people start using it.
Max.
Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/343d5bbf-0231-4c8d-a452-33b51089170c%40googlegroups.com.
John Chijioke
Sep 23, 2015, 5:37:17 AM9/23/15
to Polymer
There is a place: https://developer.mozilla.org/en-US/docs/Web/Web_Components
John Chijioke
Sep 23, 2015, 5:53:42 AM9/23/15
to Polymer
They are two very different technologies. And each will stay as long as the web exists.
In short terms:
React offers a virtual dom to your application using a one way data binding flow which makes it easier to reason about the data flow in your application. Polymer does not do this.
Polymer is based on the same reasoning that existed before react was invented only this time it aims for easier component reuse for developers. Polymer is sponsored by Google the same company that is sponsoring web components specification of which you can get the most objective information about from https://developer.mozilla.org/en-US/docs/Web/Web_Components
Over there is states that the specification is divided into 4 parts:
1. Custom Elements
2. HTML Elements
3. Shadow DOM
4. HTML Imports
If you like material design, the best way to get it into your application is to use polymer and it's elements.
At some point in the future you may be the one to take both to the alter and wed them so that react can speak web components and leverage the work polymer has already done in this area.
Just my two cents.
John.
Reply all
Reply to author
Forward
0 new messages