Coordination (was: ES6 Modules)
On Fri, Apr 12, 2013 at 8:10 AM, Alex Russell <slightlyoff at google.com>wrote:
On Thu, Apr 11, 2013 at 1:51 PM, Robin Berjon <robin at w3.org> wrote:
On 09/04/2013 16:51 , Brendan Eich wrote:
First, this cuts both ways. Do you really want to get into the times even in the modern era, even in the last three years, when a W3C/WHATWG (the two are diverging again) piece of spec-work was done without consulting with es-discuss or any such group, resulting in a less than ideal JS API? I am not going to throw that stone, it's not my point. I'm asking you to refrain as well.
It most certainly cuts both ways. What I'd be interested in though is if there's anything we can do to make it not cut at all.
You mention reviewing JS APIs; we're working on quite a few of those — and we really want all the feedback we can get.
Is there a simple, lightweight process that would ensure everyone's aware of ongoing work?
From the DOM side, I don't know that there's enough F2F contact to say that "DOM authors need to be aware of X" from the TC39 side will ever fly without some big checkbox in their lifecycle that says "has been reviewed for idomatic API practice [yes|no]".
From the TC39 side, it wouldn't be hard to have a quick breifing at the front of every-other meeting to bring people up to date on the specs that are going through the process, need eyes, etc. No review in the meeting, but just a heads up that now's the time to weigh in on X, Y, and Z.
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 them to keep up to date, as well as providing a good jump off for questions and concerns.
On Friday, April 12, 2013, Rick Waldron wrote:
On Fri, Apr 12, 2013 at 8:10 AM, Alex Russell <slightlyoff at google.com> wrote:
On Thu, Apr 11, 2013 at 1:51 PM, Robin Berjon <robin at w3.org> wrote:
On 09/04/2013 16:51 , Brendan Eich wrote:
First, this cuts both ways. Do you really want to get into the times even in the modern era, even in the last three years, when a W3C/WHATWG (the two are diverging again) piece of spec-work was done without consulting with es-discuss or any such group, resulting in a less than ideal JS API? I am not going to throw that stone, it's not my point. I'm asking you to refrain as well.
It most certainly cuts both ways. What I'd be interested in though is if there's anything we can do to make it not cut at all.
You mention reviewing JS APIs; we're working on quite a few of those ? and we really want all the feedback we can get.
Is there a simple, lightweight process that would ensure everyone's aware of ongoing work?
From the DOM side, I don't know that there's enough F2F contact to say that "DOM authors need to be aware of X" from the TC39 side will ever fly without some big checkbox in their lifecycle that says "has been reviewed for idomatic API practice [yes|no]".
From the TC39 side, it wouldn't be hard to have a quick breifing at the front of every-other meeting to bring people up to date on the specs that are going through the process, need eyes, etc. No review in the meeting, but just a heads up that now's the time to weigh in on X, Y, and Z.
The "DOM side" should all be subscribed to es-discuss and read it on a regular basis.
I think that's totally fair and something the W3C needs to get people to do more reflexively than is done today. Indeed, I'd be shocked if most of the folks who are designing DOM APIs are subscribed today.
On Fri, Apr 12, 2013 at 3:39 PM, Rick Waldron <waldron.rick at gmail.com> wrote:
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 them to keep up to date, as well as providing a good jump off for questions and concerns.
Given the number of people working on platform APIs that "should" seems ever less likely to become a reality. We need a different strategy.
On Apr 12, 2013 11: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> wrote:
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 them to keep up to date, as well as providing a good jump off for questions and concerns.
Given the number of people working on platform APIs that "should" seems ever less likely to become a reality. We need a different strategy.
Feels like some tc39 member(s) should be invited experts to anything @w3c dealing with scripted apis as a checkpoint and that w3c folks should at least follow es-summary and review f2f notes.
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 them to keep up to date, as well as providing a good jump off for questions and concerns.
Given the number of people working on platform APIs that "should" seems ever less likely to become a reality. We need a different strategy.
Parts of "the DOM side" have weekly summaries, eg
http://www.w3.org/QA/2013/03/openweb-weekly-2013-03-24.html
Having such weeklies for all relevant spec groups, including TC39, with specific feeds (not just part of general news feeds) and then a feed aggregator on top (only for the various weeklies), might help giving interested parties an idea of when to dive in where. It might also establish a lower barrier on what "everyone" might be expected to follow?
twitter.com/esdiscuss almost fits into that gap, but twitter isn't quite the right format, and suitable editing & labeling are needed to guide readers to the right firehose at the right time.
Claus
while I mostly agree with Rick, I also see the scalability problem you're worried about here. Part of the problem is that so many w3c platform APIs are designed without any appreciation of JavaScript esthetics, often it seems without any real JavaScript experience, and with WebIDL as the design language for working out and discussing these API designs. Due to heroic efforts by Cameron, WebIDL is now a workable formalism for specifying such APIs. But as a design language for discussing and working out the designs, WebIDL systematically leads to APIs hostile to the working JavaScript programmer.
If more of the w3c's design discussions were phrased in terms of JavaScript APIs as they would appear in JS, that would help. Once a design is settled, then re-expressing it in WebIDL probably remains a necessary evil, but one that would hurt less.
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> wrote:
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 them to keep up to date, as well as providing a good jump off for questions and concerns.
Given the number of people working on platform APIs that "should" seems ever less likely to become a reality. We need a different strategy.
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. 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:
-
A great many existing DOM APIs are very un-JS-friendly
-
We need better examples of what JS-friendly APIs are (or should be)
-
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 :).
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.
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> wrote:
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 them to keep up to date, as well as providing a good jump off for questions and concerns.
Given the number of people working on platform APIs that "should" seems ever less likely to become a reality. We need a different strategy.
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.
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:
- A great many existing DOM APIs are very un-JS-friendly
Agreed.
- 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?
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]".
- 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.
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: mail.mozilla.org/listinfo/es
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> wrote:
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 them to keep up to date, as well as providing a good jump off for questions and concerns.
Given the number of people working on platform APIs that "should" seems ever less likely to become a reality. We need a different strategy.
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:
- A great many existing DOM APIs are very un-JS-friendly
Agreed.
- 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 in mind.
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]".
- 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 describe.
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: mail.mozilla.org/listinfo/es-discuss
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?
On Sat, Apr 13, 2013 at 3:12 PM, Dirk Pranke <dpranke at chromium.org> wrote:
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]".
- 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.
I don't understand what you're saying here. Is it just that JS doesn't have a module system yet? What else has TC39 failed to provide?
Also, by definition, there's nothing available to library authors that isn't available to platform API authors. So I don't see how this is a reason for the current designs of DOM APIs.
On Sat, Apr 13, 2013 at 8:52 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
I don't understand what you're saying here. Is it just that JS doesn't have a module system yet? What else has TC39 failed to provide?
Also, by definition, there's nothing available to library authors that isn't available to platform API authors. So I don't see how this is a reason for the current designs of DOM APIs.
It would help if this was made a bit more concrete. I hope we all realize most of dom.spec.whatwg.org is over a decade old and cannot really be changed. The new things added to it are in much better shape.
On Sat, Apr 13, 2013 at 12:52 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu>wrote:
On Sat, Apr 13, 2013 at 3:12 PM, Dirk Pranke <dpranke at chromium.org> wrote:
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]".
- 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.
I don't understand what you're saying here. Is it just that JS doesn't have a module system yet? What else has TC39 failed to provide?
modules plus some mechanism for discovery and installation (for some definitions of those terms); equivalents to CPAN/PYPI/NPM/etc.
Also, by definition, there's nothing available to library authors that isn't available to platform API authors. So I don't see how this is a reason for the current designs of DOM APIs.
If you can assume a library, you can assume the existence of the library's abstractions. If it is difficult to assume (require) libraries, then your hands are tied when designing new standalone APIs. This is a problem C has always had, for example, as compared to Java, Perl, Python, etc.
Put concretely: if Futures are provided via libraries, but you can't assume (require) libraries, then you can't design DOM APIs around Futures. Clearly, one way to solve this is put Futures into the language, but another is to solve the extensibility problem so you can start requiring libraries.
Put concretely: if Futures are provided via libraries, but you can't assume (require) libraries, then you can't design DOM APIs around Futures. Clearly, one way to solve this is put Futures into the language, but another is to solve the extensibility problem so you can start requiring libraries.
I don't understand this. Surely you wouldn't design a platform API to be dependent on userland JS libraries. No?
On Sat, Apr 13, 2013 at 4:52 PM, Kevin Smith <zenparsing at gmail.com> wrote:
Put concretely: if Futures are provided via libraries, but you can't assume (require) libraries, then you can't design DOM APIs around Futures. Clearly, one way to solve this is put Futures into the language, but another is to solve the extensibility problem so you can start requiring libraries.
I don't understand this. Surely you wouldn't design a platform API to be dependent on userland JS libraries. No?
I think I've taken us off into the weeds, and I apologize. What I was trying to say is that library authors have an advantage over platform authors, in that they can require other libraries.
If the platform itself provides a mechanism for using and acquiring libraries (modules), then hopefully it'll be easier to move to better-designed APIs (or even multiple different APIs) without having to go back to TC39 for everything.
Of course, you will still have the problems of defining core or standard libraries and ensuring their quality.
I think I've taken us off into the weeds, and I apologize. What I was trying to say is that library authors have an advantage over platform authors, in that they can require other libraries.
No - this is good input. You want to be able to modularize your platform API, and not have to hang everything off of window. This is a use case that ES modules need to address.
On Thu, Apr 11, 2013 at 1:51 PM, Robin Berjon <robin at w3.org> wrote:
front of every-other meeting to bring people up to date on the specs that are going through the process, need eyes, etc. No review in the meeting, but just a heads up that now's the time to weigh in on X, Y, and Z.
Thoughts?