Will MDV become a standard?

[Patrick Aljord]

Hi,

First, congrats for polymer, it looks really awesome. Does anyone know what's the status of MDV or if there's a draft somewhere? Some people (from Emberjs) say it's just a Google thing and that they're the only one pushing for it. As an Angular dev I'm very interested to know what's the status of MDV and what are the chance of it becoming an official standard and if others such as Mozilla are interested in it.

Thanks,

Pat

[Rafael Weinstein]

Hi Patrick,

[Note that I'm cc'ing Yehuda, Misko & Steve -- who have invested
critical time and energy helping to shape the future of MVC patterns
on the web -- and Jonas, Olli, Tony, Luke and Brendan -- our partners
at Microsoft & Mozilla who have championed work towards the web
platform fully supporting these patterns].

Our friends at Ember have the truth of it: Google is currently the
only vendor pursuing a standard for HTML templating & databinding
(i.e. MDV).

However, the full story is (as usual) more interesting:

It's more *complete* to say that the other browser vendors care deeply
about templating and databinding and have been very supportive of the
goal, but that the focus up till now has been on delivering the
primitives required to implement a fully-realized databinding solution
in script.

In June 2011, we proposed MDV to the W3C WebApps working group:

http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0309.html

The response of the working group was that we should break MDV down
into primitives. This lead to productive collaborations between the
major browser vendors and produced the following primitives (very
useful in their own right) --- all of which have been accepted as
standards and are at various stages of implementation:

-DOM Mutation Observers:
(https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver)
-The HTML Template
Element(http://www.html5rocks.com/en/tutorials/webcomponents/template/)
-Object.observe
(http://updates.html5rocks.com/2012/11/Respond-to-change-with-Object-observ)

Web standards move (sometimes frustratingly) slowly, and it's still
early. The current design of MDV is really two additional primitives:

-Node.bind: which allows nodes to be dependent on JS heap values
-Template iteration: which tasks the template element with maintaining
"instances" in the DOM and specifies what it means to have DOM being
automatically generated while still allowing page script to operate
directly on the nodes.

Our goal is to demonstrate that:

1) MDV is independently useful for an interesting set of use-cases
2) The remaining two primitives are sane, succinct and complete
3) The "extension points" MDV provides allows it to concern itself
*only* with being responsible for producing and modifying DOM, while
allowing frameworks to implement their full set of sophisticated
behaviors and syntax via script delegation points.
4) There are clear technical advantages to native implementations in browsers.

Obviously, there's much work to do, but we believe that MDV (as
demonstrated through its use in Polymer) is now at an inflection point
where it's utility is clear and it's ready for frameworks to start
evaluating how they can benefit form the services it provides.

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

[Yehuda Katz]

For internal circulation, Ember's plan for iterating towards Web Components and Data Bindings might be useful: https://gist.github.com/wycats/9144666b0c606d1838be

It's not private per sé, but we haven't publicly announced our plans, and I'm still collecting internal feedback from the core team before I make this public.

Note that this plan doesn't strictly require MDV to succeed, as it borrows the patterns for Ember's View system without directly polyfilling DOM nodes. It does assume that something like the Web Components spec work will succeed.

In general, Ember plans to continue iterating our architecture towards where we imagine the web platform is going, without getting prematurely attached to a particular high-fidelity implementation of APIs that will almost certainly still churn.

Thanks so much, and I'd love to hear people's thoughts on this,

-- Yehuda

Yehuda Katz
(ph) 718.877.1325

[Patrick Aljord]

Hey Yehuda,

You say that Ember will eventually be able re-use web components as is, this is cool, but will other frameworks be able to re-use Ember's? Or will they depend too much on EmberView and co?

Pat

[Patrick Aljord]

Yehuda's answer: (I think you forgot to Reply all):

"In the short term, Ember components will be as coupled to Ember as Angular components are to Angular.

However, by decoupling data bindings via Raf's bind proposal, and using Ember Views mostly to fill in gaps where poly fills would be too cumbersome, I could easily imagine an Ember component being relatively portable with a bit of work once more of the pieces are in the platform.

That seems less true about Angular components at present, which rely heavily on Angular's data binding system (which supports binding to the results of expressions) and the compile and link hooks, which rely on the particular flow of Angular bootstrapping.

Do you know of any plans to move the semantics of Angular directives to be closer to web components and MDV? If so, we should seriously consider what a medium-term interop story could look like."

Me (Pat):

I think Angular is going the way of following MDV, for example at I/O they announced that vars can be defined in controllers without using the $scope object but directly in pure JS using this.model = "foo" so I would except that directives will mimic web components too but I think Miško could enlighten you better than me on this. Miško? :)

[Yehuda Katz]

Yehuda Katz
(ph) 718.877.1325

On Mon, May 20, 2013 at 10:28 PM, Patrick Aljord <pat...@gmail.com> wrote:

Yehuda's answer: (I think you forgot to Reply all):

"In the short term, Ember components will be as coupled to Ember as Angular components are to Angular.

However, by decoupling data bindings via Raf's bind proposal, and using Ember Views mostly to fill in gaps where poly fills would be too cumbersome, I could easily imagine an Ember component being relatively portable with a bit of work once more of the pieces are in the platform.

That seems less true about Angular components at present, which rely heavily on Angular's data binding system (which supports binding to the results of expressions) and the compile and link hooks, which rely on the particular flow of Angular bootstrapping.

Do you know of any plans to move the semantics of Angular directives to be closer to web components and MDV? If so, we should seriously consider what a medium-term interop story could look like."

Me (Pat):

I think Angular is going the way of following MDV, for example at I/O they announced that vars can be defined in controllers without using the $scope object but directly in pure JS using this.model = "foo" so I would except that directives will mimic web components too but I think Miško could enlighten you better than me on this. Miško? :)

I think that's a little different. That approach makes Angular directives more spiritually similar to MDV, but it doesn't really embrace the specifics of the MDV approach.

Angular's approach is actually quite different from web components in a number of important ways:

• It supports multiple "directives" per element, sort of like souped-up jQuery initializers, while Web Components focus on the ability to define custom elements that may be subclasses of HTMLElement. Angular supports "custom elements" via restrict: "E", but supports other A directives also being applied to components. This ends up meaning that directives aren't really element classes, but rather a series of instructions to apply to matching elements.
• It supports binding to arbitrary expressions, while Object.observe only supports binding to properties. This approach works fine in a world where dirty-checking is the implementation strategy, but doesn't work as well when trying to use Object.observe. It might be possible to try to find scope dependencies in an expression and insist that all such functions are "pure", but the jury is out on whether that strategy will be understandable to framework users.
• Angular has a number of binding syntaxes for different situations (=, @, &), while MDV supports just attr="{{foo}}" that triggers bind on an element or text node. And Angular's usage of the syntax MDV uses for bindings (attr="{{foo}}") does something different from what MDV does (Angular resolves the value automatically, while MDV leaves it up to the element's implementation of bind to deal with it).

I would love to see Angular adopt the MDV approach, but its current API is only spiritually similar to web components. Ironically, while Ember's syntax is quite different, its semantics map closely onto Web Components and MDV, which is why our plan to simply offer up a new HTML-based syntax will work well without breaking existing Ember semantics (or Ember applications).

[Miško Hevery]

We're in early stages of designing Angular 2.0, but some of our goals are:

- Angular will use the underlying web platform features available to it (e.g. Node.bind, template integration, Custom Elements, etc...)

- Web Components (Polymer, Ember, or any other framework/library) will work seamlessly within Angular apps and directives.

- Components written in Angular will export to Web Components (to be used by Polymer, Ember, or any other framework/library) .

We're working actively with the MDV, Web Components, and Polymer teams to make sure that our approaches remain compatible as all these projects evolve (and they will still evolve).

-- Misko & the Angular team

[Jim Lyndon]

Oh this is excellent.  Great work!  Are the Angular 2.0 prelim designs available to check out?

[arunag...@gmail.com]

nice content

[arunag...@gmail.com]

 hi nice data