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.
For more options, visit https://groups.google.com/d/optout.

Reply via email to