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
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>
>>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss