ModuleImport

John Barton johnjbarton at google.com
Wed Jul 2 14:38:23 PDT 2014


This seems like a bit too many issues, so let me just correct one
(important) one.


On Wed, Jul 2, 2014 at 2:09 PM, Jussi Kalliokoski <
jussi.kalliokoski at gmail.com> wrote:

> On Wed, Jul 2, 2014 at 7:09 PM, John Barton <johnjbarton at google.com>
> wrote:
>
>>
>>>
>
>>
>>> Now, I know there are people that think that this isn't not good, but it
>>> is. It gives you a lot of power when debugging things or playing around
>>> with new things (something I haven't seen discussed re:modules on this
>>> list). One of the greatest things in JS is that instead of reading the
>>> usually poor documentation, let alone the code, of something you want to
>>> use you can just load it up in node or the developer tools and play around
>>> with it. With node, you require() something in the repl and you see
>>> immediately what it exports.
>>>
>>
>> Loader.get() provides the module.
>>
>
> Hmm, my bad, I actually thought that Loader.get() works only when the
> module has already been fetched.
>

Your thought was correct: Loader.get() only works if the module is fetched.
 It was my impression that you were describing a debugging scenario where
the module would be loaded and where you are likely to want to avoid
module-loading since your goal is to debug the live image.



> Well that improves things a lot but that still leaves the disparity
> between what you'd write in actual code and the repl and thus fails to be
> better (in this case) than for example CommonJS.
>

I expect devtools to support declarative import in their REPL, so the code
you would write is the same.

jjb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140702/dd625143/attachment.html>


More information about the es-discuss mailing list