Compatability with Ember.JS

[Christopher Dumas]

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!

[Eric Bidelman]

Theoretically, custom elements are compatible with any framework.

https://www.polymer-project.org/docs/start/customelements.html#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.

[Rob Eisenberg]

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.

[cletusw]

I would counter again and say that yes, out of the box, they are compatible with other frameworks as far as normal DOM operations go: reading/writing properties and attributes, receiving events, etc. You did mention databinding, and you're right, *that's* where things get tricky. Libraries that implement two-way databinding (to an <input>'s value property, for example) often have hard-coded logic for those few built-in elements that support that sort of thing, so no, they won't magically work with web components for databinding. There is absolutely nothing prevent their use with web components that stick to the normal DOM patterns, though: attributes/properties in, events out. 

[Scott Miles]

>> 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

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/6fd8b32c-975f-4f65-89bd-5128db29d8bd%40googlegroups.com.

[Rob Eisenberg]

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.

[Matthew McNulty]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/f4da903e-e2df-4c3a-96f8-9bd3cddb666a%40googlegroups.com.

[Igor Minar]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CAKrkLHpQtsD9d8fqkmBqpBZzBavPBt%2B1wekJW7cD02wX97KBVA%40mail.gmail.com.

[Christopher Dumas]

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> 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!!

[Rob Eisenberg]

"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.