Coordination (was: ES6 Modules)
dpranke at chromium.org
Sat Apr 13 12:12:52 PDT 2013
On Fri, Apr 12, 2013 at 9:49 PM, Rick Waldron <waldron.rick at gmail.com>wrote:
> On Fri, Apr 12, 2013 at 10:17 PM, Dirk Pranke <dpranke at chromium.org>wrote:
>> On Fri, Apr 12, 2013 at 8:06 AM, Anne van Kesteren <annevk at annevk.nl>wrote:
>>> On Fri, Apr 12, 2013 at 3:39 PM, Rick Waldron <waldron.rick at gmail.com>
>>> > The "DOM side" should all be subscribed to es-discuss and read it on a
>>> > regular basis. Additionally, our f2f meeting notes are a great way for
>>> > to keep up to date, as well as providing a good jump off for questions
>>> > concerns.
>>> Given the number of people working on platform APIs that "should"
>>> seems ever less likely to become a reality. We need a different
>> I also think you need a different strategy. If people interested in
>> defining new APIs for the web have to be tracking how the JS language
>> itself is evolving, this is a total failure of both one or both sides.
> 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.
Of course you have to understand the language, but you shouldn't have to be
tracking the nuances of the implementation of proxies and private symbols
in order to write a decent JS API.
>> A slightly more ridiculous example to prove my point would be to suggest
>> that web spec authors should also be tracking the minutes of WG21 (the ISO
>> C++ committee), since all of these APIs are actually being implemented in
>> C++ :
>> However, I grant that there are three valid points between where we are
>> and where we want to be:
>> 1) A great many existing DOM APIs are very un-JS-friendly
>> 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?
I'm sorry, I didn't write this at all clearly. There are lots of good JS
APIs, of course, but very few of them are baked into browsers or part of
the W3C's specs. Robin's "Web API Design Cookbook" is closer to what I had
> 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]".
>> 3) TC39 et al. need to give us a language where we can build sane DOM
>> APIs without feeling like we need to change the language to do so :).
> 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.
Right. This is close to what I was trying to say. TC39 (or at least the
browser-based implementors who belong to it) has failed thus far to give us
an environment where it's possible to use libraries trivially and with
near-zero cost, so it's harder to take the stance that problems should be
solved in libraries than it should be.
The DOM API authors, on the other hand, have failed in exactly the way you
I am optimistic however we might soon be fixing both of these issues.
To that end, we probably do need more *short-term* interaction, but I
>> don't think asking everyone working on a DOM spec to follow es-discuss is
>> the best way to do so. There's actually very little overlap between what is
>> talked about most of the time on es-discuss and the sort of stuff a DOM
>> spec author cares about.
> 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". There is no free
> lunch. If you want to know what's going on, here's the subscription page:
I am trying to offer suggestions, and I've been subscribed to es-discuss
for years :)
I don't think TC39 is doing a bad job these days, and I think the types of
discussions that go on on es-discuss are good and important, but I don't
think they're the types of discussions that most API and library designers
are interested in.
Are you suggesting that we should have more language-user-oriented (as
opposed to language-lawyer-oriented) discussions on es-discuss?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss