W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: Coordination

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Sat, 13 Apr 2013 14:06:50 +0300
Message-ID: <51693C4A.2090401@helsinki.fi>
To: public-script-coord@w3.org
On 04/13/2013 08:34 AM, Boris Zbarsky wrote:
> On 4/13/13 12:49 AM, Rick Waldron wrote:
>> This statement negates itself—people defining new APIs have an
>> obligation to understand the language in which the APIs they are writing
>> will be used.
>
> While true, there are different levels of understanding at play here. Do they need to understand all the things that have been proposed and rejected
> and why they were rejected?  Do they need to understand various minutiae of language features that don't even exist yet and might not?
>
> You can make the argument that they should; that there is no way to really understand a language unless you know all the things it is not and why it's
> not those things.  But I'm not sure that's a useful thing to require, in the end.
>
>>     2) We need better examples of what JS-friendly APIs are (or should be)
>>
>> I can't believe I'm reading this, as if you believe there are no
>> examples of real world code that is very JS-friendly?
>
> There are examples of real-world code that some TC-39 members claim to be "JS-friendly" while other TC-39 members claim otherwise...
>
> It's obviously worth looking at the APIs exposed by JS libraries, but even then there is significant disagreement between libraries and their user
> bases about what makes for a "JS-friendly" API.

Yes. Certain kinds of APIs make sense in the context of a script library X using paradigm Y, but may not make sense
in the context of script library A using paradigm B.

We need some examples and reasoning behind those examples.



-Olli


>
>> As far as "outreach", in my own experience whenever I've offered
>> feedback directly to DOM API authors, I'm frequently met with responses
>> such as "that's not consistent with the platform [/end]".
>
> I'm sorry to hear that.
>
>> Meanwhile, library authors have no trouble designing sane DOM APIs that
>> web developers enjoy using. The difference: library authors listen to
>> their users, DOM API authors do not.
>
> Another important difference worth keeping in mind: users who do not like the API a library exposes use a different library with an API more to their
> liking.  That's not an option we have with the DOM except to the extent that people don't use it and use a library instead.
>
>> So far today, every response from a non-TC39 member has been to the tune
>> of "I want something, but I don't want to work for it, so find another
>> way to give it to me, but I don't have any suggestions".
>
> I think that's a gross mischaracterization of what Chaals and I said, at the very least.  If that's honestly what you read in what we said, then I
> urge you to read at least http://lists.w3.org/Archives/Public/public-script-coord/2013AprJun/0068.html again.
>
> -Boris
>
>
Received on Saturday, 13 April 2013 11:07:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:48 UTC