Does WebApps want to do work in Model-driven Views area?
Hi All, Pardon the interruption here to digress a bit to look at Rafael's proposal from the process perspective ... [Charter] defines WebApps' scope and explicit deliverables. Depending on how the proposal is viewed, (perhaps) at least part of it could be rationalized by being related to XBL templates. Nevertheless, I would appreciate feedback on - should WebApps start new work in this area? * If yes - why should WebApps take on this new deliverable? * If no - would some other group be a better place to do work in this area? Options here would include: a new Incubator Group [XG] that would have its own mail list to build consensus on the UCs, requirements and to start preliminary spec work; a new WG; some existing WG (Chaals mentioned some related work done in XForms); added to the new WG Dave Raggett mentioned; other options? -Art Barstow [Charter] http://www.w3.org/2010/webapps/charter/ [XG] http://www.w3.org/2005/Incubator/about.html Original Message Subject:Re: Model-driven Views Resent-Date:Tue, 3 May 2011 01:08:53 + Resent-From:public-webapps@w3.org Date: Mon, 2 May 2011 18:05:17 -0700 From: ext Rafael Weinstein rafa...@google.com To: Maciej Stachowiak m...@apple.com CC: o...@pettay.fi, public-webapps@w3.org Apologies. I feel like I have failed to properly contextualize this issue. Let me back up and see if I can't help create a different frame of reference. This email is already too long so I've avoided examples. Please let me know what isn't apparent and I'll explain further. 1) Imperative templating (JSP, jQuery, Closure, a load of others) is the problem. Declarative templating (Angular, Knockout, JSTemplate, Spry) is the solution. -Imperative approaches reduce to a function that spits out a string containing markup. -They are destructive in updating an existing view. Re-rendering trashes transient state and thus they are fundamentally unsuitable for dynamic web applications. -They aren't performant because they require destruction and re-creation of all instances in a collection when any item is added or removed. -Use of innerHTML for parsing tends to create XSS attack surface. 2) There's very little new in our design. This isn't a question of validating a new approach. Its a question of doing the hard work of making a successful pattern fit well into the rest of the web platform. -We've simply taken the basic design aspects of existing declarative approaches and attempted to explain their behavior with respect to the rest of the platform APIs. Further, we've attempted to give the pattern direct support for missing capabilities which currently require fairly ugly hacks. -Declarative approaches are heavily deployment tested and shown to be robust. -Declarative templating is a subset of the expressiveness of imperative. Generally speaking it's the subset that people use. [An imperative-declarative compiler is possible. It would need to enforce certain things. e.g. code blocks must contain balanced HTML, loops must not exit early, conditionals must be deterministic, etc...]. 3) The diversity in templating systems doesn't represent diversity in approaches or semantics. The differences are mostly superficial. The expressive requirements can be summarized quickly: a) Insert, assign (and possibly transform) a data value into an attribute, property or textContent. b) Conditionally include/show a bit of DOM. c) Produce a sub-template once for every item in a collection. d) Sub-iteration support is required e) Recursion (producing unknown depth trees) support is required f) Some mechanism for scoping is specifically required inside iterations, and more generally, so that full paths to data items don't need to be typed. 4) The lack of a standard blocks economies of scale that generally lead to many terrific things I don't have to list for this group, but most importantly: -Automation: Complexity kills. Non-trivial applications need tooling support. The automation and tooling support for Windows, MacOS and even Linux dwarfs that of web applications. Without a standard, there's little chance that we'll get good tools (inspecting/debugging, authoring, validation, optimization) inside or outside the browser. 5) We can create a feature which is fast by default. Libraries almost never do. -Our design is such that it fully delays all DOM work until the script event exits and then hands the instructions to the renderer as a batch. -UAs try to be lazy about doing work in order to only do expensive things minimally. This is the lazy nuclear option. All DOM work can be fully lazy. We're hopeful that there are big perf gains to be had here, but experimental implementations are the only way to prove this. -At minimum, the typical case can be assured to only incur one layout/style resolution. 6) Libraries can't hit the latency goals that we'd like to. -Libraries cannot render incrementally during page load. Leaving this
Re: Does WebApps want to do work in Model-driven Views area?
On 05/03/2011 02:38 PM, Arthur Barstow wrote: Hi All, Pardon the interruption here to digress a bit to look at Rafael's proposal from the process perspective ... [Charter] defines WebApps' scope and explicit deliverables. Depending on how the proposal is viewed, (perhaps) at least part of it could be rationalized by being related to XBL templates. Well, to me XBL templates are still quite different to MDV templates. XBL needs to handle all sort of attribute value and text value copying/forwarding and building the actual instance data in anonymous DOM and special event handling in the anonymous DOM etc. Nevertheless, I would appreciate feedback on - should WebApps start new work in this area? * If yes - why should WebApps take on this new deliverable? * If no - would some other group be a better place to do work in this area? Options here would include: a new Incubator Group [XG] that would have its own mail list to build consensus on the UCs, requirements and to start preliminary spec work; a new WG; some existing WG (Chaals mentioned some related work done in XForms); added to the new WG Dave Raggett mentioned; other options? I think I'm still missing some information before I could say yes or no. Basically I don't know what kinds of requirements led to the current design of MDV and why exactly it can't be implemented as a js library if some rather small primitives were added to the web platform. (Those small primitives should be defined either in webapps or whatwg, I think.) -Olli -Art Barstow [Charter] http://www.w3.org/2010/webapps/charter/ [XG] http://www.w3.org/2005/Incubator/about.html Original Message Subject: Re: Model-driven Views Resent-Date: Tue, 3 May 2011 01:08:53 + Resent-From: public-webapps@w3.org Date: Mon, 2 May 2011 18:05:17 -0700 From: ext Rafael Weinstein rafa...@google.com To: Maciej Stachowiak m...@apple.com CC: o...@pettay.fi, public-webapps@w3.org Apologies. I feel like I have failed to properly contextualize this issue. Let me back up and see if I can't help create a different frame of reference. This email is already too long so I've avoided examples. Please let me know what isn't apparent and I'll explain further. 1) Imperative templating (JSP, jQuery, Closure, a load of others) is the problem. Declarative templating (Angular, Knockout, JSTemplate, Spry) is the solution. -Imperative approaches reduce to a function that spits out a string containing markup. -They are destructive in updating an existing view. Re-rendering trashes transient state and thus they are fundamentally unsuitable for dynamic web applications. -They aren't performant because they require destruction and re-creation of all instances in a collection when any item is added or removed. -Use of innerHTML for parsing tends to create XSS attack surface. 2) There's very little new in our design. This isn't a question of validating a new approach. Its a question of doing the hard work of making a successful pattern fit well into the rest of the web platform. -We've simply taken the basic design aspects of existing declarative approaches and attempted to explain their behavior with respect to the rest of the platform APIs. Further, we've attempted to give the pattern direct support for missing capabilities which currently require fairly ugly hacks. -Declarative approaches are heavily deployment tested and shown to be robust. -Declarative templating is a subset of the expressiveness of imperative. Generally speaking it's the subset that people use. [An imperative-declarative compiler is possible. It would need to enforce certain things. e.g. code blocks must contain balanced HTML, loops must not exit early, conditionals must be deterministic, etc...]. 3) The diversity in templating systems doesn't represent diversity in approaches or semantics. The differences are mostly superficial. The expressive requirements can be summarized quickly: a) Insert, assign (and possibly transform) a data value into an attribute, property or textContent. b) Conditionally include/show a bit of DOM. c) Produce a sub-template once for every item in a collection. d) Sub-iteration support is required e) Recursion (producing unknown depth trees) support is required f) Some mechanism for scoping is specifically required inside iterations, and more generally, so that full paths to data items don't need to be typed. 4) The lack of a standard blocks economies of scale that generally lead to many terrific things I don't have to list for this group, but most importantly: -Automation: Complexity kills. Non-trivial applications need tooling support. The automation and tooling support for Windows, MacOS and even Linux dwarfs that of web applications. Without a standard, there's little chance that we'll get good tools (inspecting/debugging, authoring, validation, optimization) inside or outside the browser. 5) We can create a feature which is fast by default. Libraries almost never
