Re: Model-driven Views

Thanks everyone for your consideration.

It sounds like the group wants to proceed by looking first at missing
primitives. Maciej is right that one of them is the ability to declare
inert DOM structures, but my feeling is that it's probably best to
start with the central problem:

-There's no way to observe mutations to JS objects.

Current approaches resort to a number of hacks which create really terrible
artifacts in application code. The ECMA Script Proxy mechanism may be the
best starting point, but there's a related
problem with timing that isn't addressed.

I'll start a thread shortly on this problem detailing our best
understanding, and make an attempt to loop in library authors to get their
view.

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
>
>