Re: Coordination (was: ES6 Modules)

On Sat, Apr 13, 2013 at 12:52 PM, Sam Tobin-Hochstadt <samth@ccs.neu.edu>wrote:

> On Sat, Apr 13, 2013 at 3:12 PM, Dirk Pranke <dpranke@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]".
> >>
> >>>
> >>> 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.
>
> 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.

 -- Dirk