On Sat, Apr 13, 2013 at 4:52 PM, Kevin Smith <zenparsing@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. -- DirkReceived on Sunday, 14 April 2013 16:48:39 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:12 UTC