ModuleImport

Calvin Metcalf calvin.metcalf at gmail.com
Wed Jul 2 06:12:27 PDT 2014


circular dependencies in CJS are much easer then that
https://gist.github.com/calvinmetcalf/57be20b8eda0ee8fe6de


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

> On Tue, Jul 1, 2014 at 10:28 PM, Kevin Smith <zenparsing at gmail.com> wrote:
>
>>
>>  As such, we are balancing the marginal user experience gains of
>>> "export-overwriting" against the better support for circular dependencies
>>> of "real" modules.
>>>
>>
>> Another way of looking at it:
>>
>> Being in control of the language, you can always invent new sugar to
>> optimize user experience (within limits) when real usage data proves its
>> worth.  But the core model can't be changed.
>>
>> As such, it seems like it would be better to err on the side of making
>> the core model simple and solid, leaving minor UX optimizations to future
>> syntax.
>>
>
> But it's neither simple nor solid. It's overtly complicated to support
> features that shouldn't be there.
>
> Sorry in advance for the tone of this message, it is quite negative. But
> the intent is constructive. To me modules are the most anticipated feature
> in ES6 and I've been closely following the discussion and the proposal's
> evolution and I've been extremely thrilled. Finally we could have a chance
> of alleviating the situation of having a ton of non-intercompatible
> different module loaders. I haven't contributed much to the discussion
> since I liked the overall direction. However, now that I've been actually
> using the modules for a while with a couple of different transpilers, it's
> become obvious that the design is inherently broken (not the fault of the
> transpilers, they are actually probably better in some aspects than the
> real thing), and in order for ES modules to help the situation instead of
> making it worse, it needs to be better than the existing solutions.
>
> The core unique selling points of ES6 modules as opposed to the other
> module loading systems:
>
> * Language built-in: the strongest point. This makes sure that most
> tooling should support the feature out of the box and that module authors
> are more inclined to provide their modules in this format. But the design
> can be whatever and this point will still hold true, so no points to the
> design here.
> * (Reliably) statically analyzable syntax. This is my favourite feature
> and really awesome. Allows engine to fetch next modules while the current
> one is still being parsed, and tooling to better understand what the code
> does. However, this would hold true even if all we standardized was
> syntactic sugar on top of requirejs.
> * Cyclic dependencies: First of all, this is not a feature you want to
> necessarily encourage. It looks good in academia, but in my career I've yet
> to see real world code that would benefit more from cyclic dependencies
> more than refactoring. Not to mention that having cyclic dependencies have
> been possible in global scope modules since LiveScript, and is possible in
> CommonJS as well if you do a little DI:
> https://gist.github.com/jussi-kalliokoski/50cc79951a59945c17a2 (I had
> such a hard time coming up with an example that could use cyclic
> dependencies that I had to dig the example from modules examples wiki). And
> honestly I don't think it's a feature that deserves to be easier to do than
> my example, and especially not worth making other design compromises for.
> * Mutable bindings: This will make a good chapter in a future edition of
> JavaScript: The bad parts, along with being able to redefine undefined. You
> can have mutable bindings in other module systems as well, just reassign
> something in your exports and then your consumer uses the exports property
> directly. A lot of WTFs avoided and even doing it like that will ring alarm
> bells in code review.
> * Compile-time errors: This not a feature, it's a bug. Try finding a
> website that doesn't somewhere in its code check for whether you have a
> feature / module available, i.e. optional dependencies. Some examples:
> Angular has jQuery as an optional dependency; spritesheet generator modules
> for node that have multiple engines as optional dependencies because some
> of them may be native modules that don't compile on all platforms. Also
> things get worse if platform features are implemented as modules. Let's say
> things like localStorage, IndexedDB and friends were provided as modules
> and as a result, things like localforage would either not exist or would be
> infinitely more complex. Just look at github search for keywords `try` and
> `require`
> https://github.com/search?l=javascript&q=try+require&ref=cmdform&type=Code
> to see how widely used the pattern of wrapping a module load in a try-catch
> is.
>
> Now let's look at some things that tip the odds into existing solutions
> favor:
>
> * Massive amount of existing modules.
> * Existing large-scale user-bases.
> * Node has stated that the core will always be CommonJS, meaning that on
> node, in order to use ES6 modules, you'll have to be using two different
> module systems which doesn't sound like a thing that people would do unless
> there's proven benefits.
> * Completely dynamic. 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. You can do whatever
> with the exports: enumerate, extend your own exports with them, whatever
> you want, it's just an object. In debugging situations and learning of new
> libraries, it's really straightforward to just require the module and give
> it different inputs to see what the outputs to see if it's something you
> want to use or what's the edge case of the method that causes the bug
> you're trying to fix (and then just make a failing test out of it). I can't
> tell you how many times a day I write
> angular.element(document.body).injector().get("Something") or
> require(function (Something) { window.Something = Something }) in the dev
> tools. With the current design of ES6 modules, I don't think it's even
> feasible to allow the users to type into the devtools console first `import
> something from "somewhere"` and then in the next entry refer to
> `something`. Not to mention that the dynamic loading in the existing
> solutions caters for situations like build tools, for example loading grunt
> tasks. The case there is that a lot of grunt plugins have dependencies
> lists from here to the end of the world, so when you run a task, you only
> want to load the modules that are required by that task to avoid
> concatenating files taking 20 seconds because it loads a ton of crap for
> other tasks. So people started loading the modules when the tasks get
> called, not all at the same time when initializing and this proved to have
> significant performance benefits. So much that now there's jit-grunt that
> by guessing and configuration is able to load the modules for a given task
> when the given task is invoked. This is simply not possible with ES6
> modules without a massive boilerplate spaghetti with async stuff.
>
> Given all this, how are we supposed to convince people to use this stuff?
> These concerns are not something that can be fixed later either, they're
> fundamental to the current design.
>
> Now I can guess you're thinking that this was purely destructive, so
> where's the constructive part? The key takeaway is that I'm no longer sure
> that we should even try to ship modules with ES6. On the web platform, it's
> better to not hurry shipping something that's just going to end up on the
> wall of shame of short-sighted decisions. Brendan probably knows this the
> best. :) Let's take the time to actually ship something that we can
> confidently say is better than the status quo rather than doing this:
> http://xkcd.com/927/
>
> Cheers,
> Jussi
>
>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
-Calvin W. Metcalf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140702/a86e9559/attachment-0001.html>


More information about the es-discuss mailing list