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 +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 12:04:30 UTC