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) On Mon, Sep 21, 2015 at 10:45 PM, Max <[email protected]> wrote: > You raise interesting questions. > > 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). > > 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. > > On Mon, 21 Sep 2015 at 10:47 <[email protected]> wrote: > >> 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? >> >> >> On Monday, 21 September 2015 17:25:55 UTC+8, Eric Bidelman wrote: >> >>> Ah, so more stuff going on than meets the eye :) >>> >>> I wouldn't expect scrolling to be a Polymer issue, even in the Shadow >>> DOM polyfill. There might be a bad interaction between meteor and touching >>> scroll properties. Can you point us to the app? >>> >>> 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. >>> >>> On Mon, Sep 21, 2015 at 11:02 AM <[email protected]> wrote: >>> >> 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 :( >>>> >>>> >>>> On Monday, 21 September 2015 16:28:49 UTC+8, Eric Bidelman wrote: >>>> >>>>> This is a long post with a lot of questions :) Can we start by >>>>> addressing performance? What are your concerns? >>>>> >>>>> 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 >>>>> >>>>> http://addyosmani.com/blog/component-interop-with-react-and-custom-elements/ >>>>> >>>>> https://www.accelebrate.com/blog/web-components-angular-polymer-and-react/ >>>>> >>>>> http://programmers.stackexchange.com/questions/225400/pros-and-cons-of-facebooks-react-vs-web-components-polymer >>>>> >>>>> 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. >>>>> >>>> On Mon, Sep 21, 2015 at 6:27 AM <[email protected]> wrote: >>>>> >>>> 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? >>>>>> >>>>>> 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 [email protected]. >>>>> >>>>> >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/polymer-dev/ddf0cefe-5dfa-4187-bdf7-2ad3d91f8602%40googlegroups.com >>>>>> <https://groups.google.com/d/msgid/polymer-dev/ddf0cefe-5dfa-4187-bdf7-2ad3d91f8602%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> 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 [email protected]. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/polymer-dev/13e6fb8d-f6ba-44c0-8702-b2ab2d0c16d1%40googlegroups.com >>>> <https://groups.google.com/d/msgid/polymer-dev/13e6fb8d-f6ba-44c0-8702-b2ab2d0c16d1%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/polymer-dev/77602a50-71c7-4229-b2fe-918f079139d7%40googlegroups.com >> <https://groups.google.com/d/msgid/polymer-dev/77602a50-71c7-4229-b2fe-918f079139d7%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/polymer-dev/CAMZCrPjm5NJjfv5o-400TOO-ckGt8a0tiKSkjjFU9Eh3c6nbNQ%40mail.gmail.com > <https://groups.google.com/d/msgid/polymer-dev/CAMZCrPjm5NJjfv5o-400TOO-ckGt8a0tiKSkjjFU9Eh3c6nbNQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- [image: --] Saurabh Sharma [image: http://]about.me/saurshaz <http://about.me/saurshaz> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CALu-crXeTc-oBtgnS0q1VVGf22TWZ5Khtk1Q6bvhKqgWSNG7RA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
