I'd like to see a general horn-clause style dependency resolution system built into JavaScript functions and see that applied to dynamic loading. Then the same system could be used to executing async operations smoothly, logic programming, etc. Something smart enough to resolve all the relationships from simple rules and lazy load the required bits as soon as possible. I've done that with running async code and it makes more sense to me than Promises.
📱 Michael McGlothlin > On Aug 19, 2015, at 5:46 AM, Guy Bedford <guybedf...@gmail.com> wrote: > > It's great to see more interest in dynamic loading here. > > The contextual loader may be worth considering as a focus here - this is the > special contextual loading syntax to effectively provide a scoped > System.import call whose referrer is locked to the current module (`import > module from this` as Dave has put in the roadmap, but I'm not sure what the > exact syntax proposal is). > > This is the equivalent of the dynamic require in Node. > > As syntax it seems that would be in ECMA-262, and also might avoid the async > Promise issues to share with Node as it can be entirely > implementation-specific. > > Having a spec for this syntax would certainly be beneficial as it would > immediately enable transpilers and module loading environments to then > provide the dynamic loading feature, without other specification effort > necessary. > > >> On Wed, Aug 19, 2015 at 10:38 AM Isiah Meadows <isiahmead...@gmail.com> >> wrote: >> There are ways for syncing promises for Node compatibility, although they >> all lie in C++ land. Similar has already been done with Node callbacks. >> >> https://www.npmjs.com/package/sync >> >> (You could also spawn a thread, block for a message, and join it with the >> promise result from a C++ callback from a thenable.) >> >> >>> On Tue, Aug 18, 2015, 18:06 Bradley Meck <bradley.m...@gmail.com> wrote: >>> The problem is timing; WHATWG uses promises, which Node cannot use due to >>> existing code bases on npm + potential mixing w/ `require`. This causes >>> time discrepancies and would mean different actions depending on how >>> exactly hooks are specced out. Node does not want to prevent async loading >>> on the browser, and the WHATWG loader does not want to cause breakage in >>> Node. >>> >>>> On Tue, Aug 18, 2015 at 4:56 PM, Jason Orendorff >>>> <jason.orendo...@gmail.com> wrote: >>>> On Tue, Aug 18, 2015 at 12:45 PM, Bradley Meck <bradley.m...@gmail.com> >>>> wrote: >>>> > This would assume they can support the transformation hooks to do things >>>> > like load coffeescript etc. right now, which is the main contention >>>> > point. >>>> >>>> It is a perfectly ordinary occurrence in software to ship some >>>> capability at one point, and ways of customizing that capability >>>> later. >>>> >>>> -j >>> >>> _______________________________________________ >>> es-discuss mailing list >>> es-discuss@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
