"Ember can two-way data bind with any HTML element" I would just caution you against making that assumption. A quick search hasn't turned up anyone writing about actually using Ember and Web Components. The only thing I could find was this: https://gist.github.com/wycats/9144666b0c606d1838be#interop-with-polymer-elements which seems to indicate there may be a problem. For example it states "We will need to figure out the precise semantics of custom elements integrating with Ember's data binding system."
Please try it out and let us know if Ember's databinding and Polymer elements work seamlessly. On Friday, November 14, 2014 4:33:47 PM UTC-5, Christopher Dumas wrote: > > I was asking wether polymer's custom elements are indistinguishable from > normal elements, making them comparable with Ember, or wether there was > something else going on that makes the different. If I was not clear, I > apologize. I wasn't asking about data binding, because Ember can two-way > data bind with any HTML element. Thanks for Answering my question!! > > On Nov 14, 2014, at 1:31 PM, Christopher Dumas <christop...@me.com > <javascript:>> wrote: > > I was asking wether polymer's custom elements are indistinguishable from > normal elements, making them comparable with Ember, or wether there was > something else going on that makes the different. If I was not clear, I > apologize. I wasn't asking about data binding, because Ember can two-way > data bind with any HTML element. Thanks for Answering my question!! > > On Nov 12, 2014, at 2:52 PM, Igor Minar <imi...@google.com <javascript:>> > wrote: > > It's not quite that simple but I think that both of you are right. > > In an ideal case, the custom element should be indistinguishable from a > native element. > > The problems start when frameworks and libraries make assumptions about > DOM that were true before custom elements, but are no longer valid now. > > For example, in the past creating an element could have been done without > worrying about any side effects because most of the html elements are > lightweight. With custom elements, nobody knows what happens when an > element is instantiated and bad things might happen if the framework > creates an element just for bookkeeping purposes, creates it too early, > pools elements or does other things where the were harmless with native > elements, but with custom elements could result in bad side-effects. > > Another issue are assumptions about behavior of global and boolean > attributes in DOM. Something that was not an issue before custom elements, > but as we've already seen is an issue now. > > The data-binding aspect of interop is a completely different story and > just as before the issue is that in the past it was sufficient to bind to > attributes, but with custom elements you quickly start hitting walls if you > go down this path. > > I expect that if they haven't already, sooner or later Ember will come > across similar issues as those that Angular came across already. > > \i > > On Wed Nov 12 2014 at 2:35:19 PM 'Matthew McNulty' via Polymer < > polym...@googlegroups.com <javascript:>> wrote: > >> If your framework allows for the use of standard HTML elements, it will >> also work with custom elements in supported browsers, modulo bugs or >> optimizations that don't take the very existence of new HTML tags into >> account. >> >> If your framework requires coordination from within the boundaries of an >> element to an outside orchestrator via non-standard APIs (read: not >> properties, attributes, events, and children), it's not that simple. >> >> Custom elements have the same API surface area as native elements. >> >> Having some sort of component system that could describe a non-standard >> API such that any component could work with some non-standard orchestration >> system that isn't the DOM is a completely separate question. >> >> -Matt >> >> On Wed, Nov 12, 2014 at 2:16 PM, Rob Eisenberg < >> r...@bluespireconsulting.com <javascript:>> wrote: >> >>> Once again, I restate what I said before: custom elements are not >>> necessarily compatible with any framework. >>> >>> The original poster is asking about Ember and Handlebars. He's not >>> asking about basic DOM capabilities like attributes, properties, etc. The >>> fact that there is no standard for data-binding is an important part of the >>> "any framework" aspect of the question. The poster wants to know if he can >>> use custom elements with any framework and have it all work correctly, >>> especially frameworks that support databinding like Ember. The answer to >>> that question is no. Some things might work, others might not. It will >>> probably depend on the framework. As I said, it won't work correctly with >>> Angular 1.x. If that isn't a concrete example, I'm not sure what is. Now, >>> I'm less familiar with Ember, so I'm not sure if they have that problem as >>> well. Maybe not. >>> >>> Incidentally, the problem isn't a lack of a databinding standard. The >>> problem is that the web components spec doesn't include any notion of >>> metadata or self-describing components. Many would say that is an essential >>> aspect of any component system. I've worked with many component systems >>> over the years and web components is the first that seems to be missing >>> that piece. If that were added to HTML, then it would be much easier to >>> build binding systems like Angular's and Ember's and to ensure they work >>> properly with anything. A lot of other interesting things would also be >>> possible, of course. >>> >>> On Wednesday, November 12, 2014 4:56:08 PM UTC-5, Scott Miles wrote: >>>> >>>> >> Actually, no, custom elements are most definitely not theoretically >>>> compatible with any framework >>>> >>>> This is not accurate from our perspective. Custom elements are >>>> fundamentally indistinguishable from native elements and therefore work in >>>> any DOM context. >>>> >>>> >> This is one of several reasons that Angular has to make big breaking >>>> changes in 2.0 and why other libraries with databinding support will >>>> probably follow in some fashion or another. >>>> >>>> There is no standard for data-binding. >>>> >>>> One can say, Angular doesn't support data-binding to Custom Elements, >>>> but this is no fault of Custom Elements. >>>> >>>> It might also be true to say, Polymer's data-binding doesn't support >>>> framework X. This also has nothing to do with Custom Elements, and again >>>> reflects only the lack of a data-binding standard. >>>> >>>> Custom Elements support attributes, properties, events, and children, >>>> the same as native elements. >>>> >>>> Scott >>>> >>>> On Wed, Nov 12, 2014 at 5:26 AM, Rob Eisenberg < >>>> r...@bluespireconsulting.com> wrote: >>>> >>>>> Actually, no, custom elements are most definitely not theoretically >>>>> compatible with any framework. Not out of the box at least. This is one >>>>> of >>>>> several reasons that Angular has to make big breaking changes in 2.0 and >>>>> why other libraries with databinding support will probably follow in some >>>>> fashion or another. >>>>> >>>>> On Tuesday, November 11, 2014 5:49:31 PM UTC-5, Eric Bidelman wrote: >>>>>> >>>>>> Theoretically, custom elements are compatible with any framework. >>>>>> >>>>>> https://www.polymer-project.org/docs/start/customelements.ht >>>>>> ml#interop >>>>>> >>>>>> On Wed, Nov 12, 2014 at 9:18 AM, Christopher Dumas < >>>>>> christop...@me.com> wrote: >>>>>> >>>>>>> I am a huge fan of Google's Material Design (and I think >>>>>>> Polymer is really cool), and also of Ember.JS. I was interested to know >>>>>>> whether you plan to have compatibility with Ember.JS. To clarify: I was >>>>>>> hoping that Polymer might at least play nicely with Ember and >>>>>>> Handlebars. >>>>>>> Keep up the good work! >>>>>>> >>>>>>> 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/CD4C3C6E-FA6D- >>>>>>> 466E-ADAA-A3732FDBFE42%40me.com. >>>>>>> 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 polymer-dev...@googlegroups.com. >>>>> To view this discussion on the web visit https://groups.google.com/d/ >>>>> msgid/polymer-dev/6fd8b32c-975f-4f65-89bd-5128db29d8bd% >>>>> 40googlegroups.com >>>>> <https://groups.google.com/d/msgid/polymer-dev/6fd8b32c-975f-4f65-89bd-5128db29d8bd%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 polymer-dev...@googlegroups.com <javascript:>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/polymer-dev/f4da903e-e2df-4c3a-96f8-9bd3cddb666a%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/polymer-dev/f4da903e-e2df-4c3a-96f8-9bd3cddb666a%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 polymer-dev...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/polymer-dev/CAKrkLHpQtsD9d8fqkmBqpBZzBavPBt%2B1wekJW7cD02wX97KBVA%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/polymer-dev/CAKrkLHpQtsD9d8fqkmBqpBZzBavPBt%2B1wekJW7cD02wX97KBVA%40mail.gmail.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 polymer-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/568def31-6c68-48bc-b48d-3880f76e5940%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
