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

Re: Model-driven Views

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 28 Apr 2011 02:02:04 -0700
Cc: Olli@pettay.fi, public-webapps@w3.org
Message-id: <ECABF159-5B52-4DC2-AE36-F2FF98502235@apple.com>
To: Rafael Weinstein <rafaelw@google.com>

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.

Received on Thursday, 28 April 2011 09:02:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:19 UTC