W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: Model-driven Views

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 28 Apr 2011 02:33:26 -0700
Message-ID: <BANLkTinNRZRi07t_7w4=W9r=my2ZQfLFmQ@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Rafael Weinstein <rafaelw@google.com>, Olli@pettay.fi, public-webapps@w3.org
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?

/ Jonas
Received on Thursday, 28 April 2011 09:34:24 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:44 GMT