Re: Model-driven Views

On Thu, Apr 28, 2011 at 12:09 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On Apr 28, 2011, at 2:33 AM, Jonas Sicking wrote:
>
>> 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.
>>
>> I agree with much of this. However it's hard to judge without a bit
>> more meat on it. Do you have any ideas for what such primitives would
>> look like?
>
> That's best discussed in the context of Rafael explaining what limitations prevent his proposal from working as well as it could purely as a JS library.

The goal for this work is explicitly *not* to leave things to
libraries -- I'd like for that not to creep into the discussion as an
assumption or a pre-req. Libraries are expensive, slow, and lead to a
tower-of-babel problem. On the other hand, good layering and the
ability to explain current behavior in terms of fewer, smaller
primitives is desirable, if only to allow libraries to play whatever
role they need to when the high-level MDV system doesn't meet some
particular need.

> The one specific thing I recall from a previous discussion of this proposal is that a way is needed to have a section of the DOM that is inactive - doesn't execute scripts, load anything, play media, etc - so that your template pattern can form a DOM but does not have side effects until the template is instantiated.

Right. The contents of the <template> element are in that inactive state.

> This specific concept has already been discussed on the list, and it seems like it would be very much reusable for other DOM-based templating systems, if it wasn't tied to a specific model of template instantiation and updates.

Having it be a separately addressable primitive sounds like a good
thing...perhaps as some new Element type?

Received on Thursday, 28 April 2011 12:47:16 UTC