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 +0000
Resent-From: 	<public-webapps@w3.org>
Date: 	Mon, 2 May 2011 18:05:17 -0700
From: 	ext Rafael Weinstein <rafaelw@google.com>
To: 	Maciej Stachowiak <mjs@apple.com>
CC: 	<Olli@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
to libraries will continue to put apps in the awkward position of
*needing* to render on the server first so as to deliver a page that
loads above the fold immediately and then precariously bootstrapping
back into a proper dynamic separation of view&  model.

-Wire-bytes are getting cheaper but latency isn't. Loading libraries
is a bitter pill to swallow in order to create the basic abstractions
you need to improve productivity and scale your application.

[http://www.stevesouders.com/blog/2010/07/13/velocity-tcp-and-the-lower-bound-of-web-performance/]

7) Leaving DOM production to libraries worsens the tower of babel problem.

-Most JS frameworks make an attempt to be in control of DOM
production. The platform needs to be the cop and make the libraries
play nice. For example, Angular would like to provide a development
methodology but allow jQuery widgets to be used. Both (rightly so,
lacking browser support) want to be in control. Chaos ensues.

-We can spec the semantics, timing, and lifetime events of DOM
production such that it opens the way for libraries to reliably plug
in and be more confident that some other library won't break them. XBL
is apropos for similar reasons.


8) Script has no ability to expand the declarative semantics of HTML

-The operation of web apps is already opaque to robots on the web. The
data already canonically live in the JS heap.

-Allowing declarative support for separating view&  model opens the
way for web-automation to better understand what's going on.


9) We need to lead here and create a "pit of success". The current pit
is full of nasty stuff.

-Creating a templating library that mostly works is easy and fun.
Every framework is going to have one and everyone who creates one is
going to make the same XSS mistakes (by use of innerHTML), and finally
discover that it doesn't really work with dynamic applications.

-The web is deeply engrained in the approach of imperative templating.
It's non-obvious to typical webdevs why this approach doesn't have
legs.

-The web has succeeded dramatically by making complex things easy.
Offering support here will raise the bar substantively for what a
novice webdev can achieve. Web applications shouldn't just be the
domain of web ninjas.



On Thu, Apr 28, 2011 at 2:02 AM, Maciej Stachowiak<mjs@apple.com>  wrote:
>
>  On Apr 27, 2011, at 6:46 PM, Rafael Weinstein wrote:
>
>>>
>>>
>>>>
>>>>  What do you think?
>>>>
>>>
>>>  - Is this something you'd like to be implemented in the browsers,
>>
>>  Yes.
>>
>>>    and if yes, why? What would be the reasons to not just use script
>>>    libraries (like your prototype).
>>
>>  FAQ item also coming for this.
>
>  Having heard Rafael's spiel for this previously, I believe there are some things that templating engines want to do, which are hard to do efficiently and conveniently using the existing Web platform.
>
>  However, I think it would be better to add primitives to the Web platform that could be used by the many templating libraries that already exist, at least as a first step:
>
>  - There is a lot of code built using many of the existing templating solutions. If we provide primitives that let those libraries become more efficient, that is a greater immediate payoff than creating a new templating system, where Web apps would have to be rewritten to take advantage.
>
>  - It seems somewhat hubristic to assume that a newly invented templating library is so superior to all the already existing solutions that we should encode its particular design choices into the Web platform immediately.
>
>  - This new templating library doesn't have enough real apps built on it yet to know if it is a good solution to author problems.
>
>  - Creating APIs is best done incrementally. API is forever, on the Web.
>
>  - Looking at the history of querySelector(), I come to the following conclusion: when there are already a lot of library-based solutions to a problem, the best approach is to provide technology that can be used inside those libraries to improve them; this is more valuable than creating an API with a primary goal of direct use. querySelector gets used a lot more via popular JavaScript libraries than directly, and should have paid more attention to that use case in the first place.
>
>  Perhaps there are novel arguments that will dissuade me from this line of thinking, but these are my tentative thoughts.
>
>  Regards,
>  Maciej
>
>

Received on Tuesday, 3 May 2011 11:39:12 UTC