import.meta and TC39 process as a whole

Sat Aug 5 09:13:12 UTC 2017

I would be comfortable with `module.import()` and `module.meta` instead of
`import()` and `import.meta`, simply because the name `module` more
automatically describes the module specific "global" object than `import`
does. Also, it more explicitly communicates that the "import" is specific
to the module and hence how it is able to use its folder path etc. as root,
for example. I would be comfortable if everything else about them stayed
the same as the proposals though

I would like to see the `module` object and `module.import()` included in
the "Alternative solutions explored" section in the dynamic imports
proposal: https://github.com/tc39/proposal-dynamic-import along with the
explanation that `module` could be the module specific "global" object
instead of `import`, along with `module.meta` as an alternative to
https://github.com/tc39/proposal-import-meta . I think it is the most
compelling of the "alternative solutions".

On Fri, 4 Aug 2017 at 21:47 Dmitrii Dimandt <dmitrii at dmitriid.com> wrote:

> I was going to write a big answer going into details while a `system`
> “special form” would be beneficial, extensible and future-proof, draw
> comparisons and parallels to `super()` etc.
>
> Instead I will leave you with this quote and links from node.js
> enhancement proposals on `module.import`
> https://github.com/WebReflection/node-eps/blob/master/XXX-module-import.md
> :
>
> — start quote —
>
> Why polluting module and not require ?
>
> require function has been historically abused (
> https://www.npmjs.com/package/require.async) or polluted (
> http://requirejs.org/docs/api.html#data-main) in an era where Promise, as
> well as async and await patterns, weren't even discussed in the JS
> community.
>
> ...
>
> On the other hand, being module where developers define their exports, I
> don't see any confusion in being module where developers can import their
> dependencies.
>
> — end quote —
>
> It’s funny to see how TC39 ended up abusing and polluting `import`.
>
>
>
>
> On Fri, 04 Aug 2017 at 16:58 "Caridy Patiño" <">"Caridy Patiño" > wrote:
>
>> > Make “System” syntax, and there you go.
>>
>> Dmitrii, I like that, let’s continue with that train of thoughts! How do
>> you make System syntax? You can’t consider it an object (it is not an
>> object, it is syntax), which means you can’t pass it around because it
>> holds contextual information (linked to the source text were it was used,
>> similar to our beloved eval), it means you can’t really use other syntax to
>> spread it, because it is not a object, etc, etc, etc. Do you see where I’m
>> going? You quickly ended up with something almost equivalent to import().
>>
>> We didn’t come up with it in the shower, it took years to understand all
>> the problems, and create consensus, definitely not rushed IMO.
>>
>> /caridy
>>
>> On Aug 4, 2017, at 3:31 AM, Dmitrii Dimandt <dmitrii at dmitriid.com> wrote:
>>
>> Make “System” syntax, and there you go.
>>
>> Instead we have multiple ad-hoc random additions to random keywords just
>> because someone needs something and since there are rarely any long-term
>> design decisions anymore, we’re stuck with new.target, function.sent,
>> import.meta (add your own)
>>
>> Seriously. How is new.target is “syntax that has context information”,
>> but System.whatever cannot be provided with context information because
>> it’s API?
>>
>>
>>
>> On Fri, 04 Aug 2017 at 09:26 Jordan Harband <> wrote:
>>
>>> > There’s nothing stopping you from providing context to System.load.
>>> Or Loader.import, or…
>>>
>>> Those are APIs. It is, in fact, impossible to provide context with API,
>>> since it's just normal functions - it must be with syntax.
>>>
>>> Additionally, please don't use sexual language, especially in a
>>> derogatory manner - that's against TC39's code of conduct, and I'm quite
>>> sure it won't be tolerated on this list.
>>>
>>> Criticism that's purely insult, and doesn't actually explain the cons of
>>> something, is also not productive or useful.
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>> On Fri, Aug 4, 2017 at 12:20 AM, Gil Tayar <gil at tayar.org> wrote:
>>>
>>>> Myself, and tens of programmers I know, use ES6 modules (and their
>>>> precursors, CommonJS modules) for years now and can't even believe there
>>>> was a time when they didn't exist, given that they have totally transformed
>>>> (in a good way) the way we work. And that is also the vibe I am getting
>>>> from the community (twitter, blog posts, meetups, etc). So when you say
>>>> that modules are "redundant and unnecessary on the server-side.  and
>>>> [...]continue to fail to solve an relevant pain-point for everyday
>>>> programmers on the frontend-side now", I believe you are not talking about
>>>> myself or about the community I surround myself with.
>>>>
>>>> - Gil Tayar
>>>>
>>>> On Fri, Aug 4, 2017 at 9:47 AM kai zhu <kaizhu256 at gmail.com> wrote:
>>>>
>>>>>
>>>>> > I’m curious what the concerns were. You mentioned disliking the
>>>>> syntax, but I’m guessing there’s more to it than that?
>>>>>
>>>>> the concern is that es modules are starting to look like a solution in
>>>>> search of a problem.  its redundant and unnecessary on the server-side.
>>>>> and it continues to fail to solve an relevant pain-point for everyday
>>>>> programmers on the frontend-side now, or in the foreseeable future, while
>>>>> creating new ones.
>>>>>
>>>>> > I’ve been experimenting with ES Modules over HTTP 2 for a few
>>>>> months. I used rollup to create my dep graph without actually bundling,
>>>>> then served requested modules as entry points with a server push for their
>>>>> deps. I imagine that it won’t be long brolefore generic tooling for this
>>>>> sort of approach emerges (my own solution is pretty hacky, just wanted to
>>>>> see how it might work).
>>>>>
>>>>> for most projects, dep-graph and tree-shaking have marginal benefits
>>>>> in frontend programming, given their complexity.  for all that extra work
>>>>> and boilerplate, the result is typically not anymore smaller, more
>>>>> efficient, or more maintainable than a pre-es6 rollup file.
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>
>> _______________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170805/e538b194/attachment-0001.html>