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

Re: Model-driven Views

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Thu, 28 Apr 2011 15:24:08 +0300
Message-ID: <4DB95C68.3040007@helsinki.fi>
To: Maciej Stachowiak <mjs@apple.com>
CC: Rafael Weinstein <rafaelw@google.com>, public-webapps@w3.org
On 04/28/2011 12:02 PM, Maciej Stachowiak 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 you; better to add primitives which allow creating
script libraries.


-Olli


>
> Regards, Maciej
>
>
Received on Thursday, 28 April 2011 12:24:38 GMT

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