import.meta and TC39 process as a whole

Fri Aug 4 13:14:55 UTC 2017

This seems to be the conclusion the lead to consensus:
```
YK: Option #3.c (import { url } from here) is undesirable because it must
be top-level.

(bikeshed discussion of what to call import.thing) (general consensus for
import.meta)

MM: What about exposing dynamic import() as a method of import.meta?

DH: import.meta.import() is just really verbose for a common idiom.

BF: And import() should be available in script, where the import.meta
meta-property is not available.

Conclusion/Resolution

Let's go with import.meta; Domenic to come back later this meeting with a
proposal
```

- Matthew Robb

On Fri, Aug 4, 2017 at 9:11 AM, Matthew Robb <matthewwrobb at gmail.com> wrote:

> Just want to add some links to this convo:
>
> https://github.com/tc39/tc39-notes/blob/master/es8/2017-05/
> may-23.md#16iib-module-import-options-discussion-potentially-for-stage-1
> https://docs.google.com/presentation/d/1p1BGFY05-iCiop8yV0hNyWU41_
> wlwwfv6HIDkRNNIBQ/edit?usp=sharing
>
>
> - Matthew Robb
>
> On Fri, Aug 4, 2017 at 9:08 AM, Dmitrii Dimandt <dmitrii at dmitriid.com>
> wrote:
>
>> import.meta isn’t rushed. yet. dynamic imports? definitely rushed. That’s
>> the only reason import.meta exists in the first place. (Much like
>> function.sent, new.target and many other things).
>>
>> Ad-hoc shortsighted solutions lead to ad-hoc shortsighted solutions.
>> Worse still, these solutions have actually been defended by other equally
>> bad solutions!
>>
>> dynamic import’s looks-like-function-doesn’t-look-like-function was
>> defended by invoking things like !function{}() [1]. import.meta is defended
>> by pointing at new.target (link lost in my memory) etc. Basically these
>> features just open a huge can of worms that will keep spreading
>> uncontrollably throughout the language. It’s already happening and we are
>> already witness to this.
>>
>> [1] https://github.com/tc39/proposal-dynamic-import/issues/
>> 35#issuecomment-274561995
>>
>> P.S. regarding polluting `import`, this proposal for node actually takes
>> this into consideration: https://github.com/WebReflection/node-eps/blo
>> b/master/XXX-module-import.md#why-polluting-module-and-not-require-
>>
>> On Fri, 04 Aug 2017 at 14:54 Matthew Robb <Matthew Robb
>> <Matthew+Robb+%3Cmatthewwrobb at gmail.com%3E>> wrote:
>>
>>> I don't want to fan a fire and personally I've preferred other solution
>>> s for module meta data but nothing is being rushed imo. I've been closely
>>> tracking this discussion in tc39 for some years and while again some of the
>>> current front runners are not my favorite proposals they are well thought
>>> out, well intended, and painstakingly deliberated.
>>>
>>> Now is the time to raise objections but please it helps no one's cause
>>> to come at this with anything but constructive discourse. You have validity
>>> in your objections but it's going to be difficult to Garner support without
>>> tact.
>>>
>>> On Aug 4, 2017 8:45 AM, "Dmitrii Dimandt" <dmitrii at dmitriid.com> wrote:
>>>
>>>> Sorry, it’s just the manner in which Javascript is being actively
>>>> demolished has really irked me. Especially the speed with which these
>>>> decisions are carried out. Suggestions like “you should really do some
>>>> light reading before engaging in arguments” don’t help either.
>>>>
>>>> These are decisions we as developers have to live with for years to
>>>> come. It’s very easy to add features to a language. It’s almost impossible
>>>> to remove them. Hence the (uncalled for) curtness.
>>>>
>>>>
>>>>
>>>> On Fri, 04 Aug 2017 at 14:31 James M Snell <James M Snell
>>>> <James+M+Snell+%3Cjasnell at gmail.com%3E>> wrote:
>>>>
>>>>> Dmitrii,
>>>>>
>>>>> Quick aside: the rude manner in which you are communicating is
>>>>> interfering with your goal of convincing anyone. Perhaps if you tried not
>>>>> being so rude, people here would be more willing to listen to what you're
>>>>> saying.
>>>>>
>>>>> - James
>>>>>
>>>>> On Fri, Aug 4, 2017 at 1:09 AM Dmitrii Dimandt <dmitrii at dmitriid.com>
>>>>> wrote:
>>>>>
>>>>>> Let’s continue with the trend of light reading. Let’s see the
>>>>>> multitude of things that are in JS, and no one bats an eye:
>>>>>>
>>>>>> — start quote —
>>>>>>
>>>>>> Note that implements, let, private, public, interface, package, p
>>>>>> rotected, static, and yield are disallowed in strict mode only.
>>>>>>
>>>>>> You may have noticed I included eval and arguments in the list.
>>>>>> These are not strictly reserved words, but they sure act like them
>>>>>> <http://ecma-international.org/ecma-262/5.1/#sec-12.2.1> — they’re
>>>>>> disallowed in strict mode too.
>>>>>>
>>>>>> Also, the (unlisted) NaN, Infinity, and undefined properties of the
>>>>>> global object are immutable or read-only properties in ES5. So even though var
>>>>>> NaN = 42; in the global scope wouldn’t throw an error, it wouldn’t
>>>>>> actually do anything. To avoid confusion, I’d suggest avoiding the use of
>>>>>> these identifiers altogether, even though they’re not strictly reserved
>>>>>> words.
>>>>>>
>>>>>> — end quote —
>>>>>>
>>>>>> Oh, hello. What do we have here? Non-reserved words like they are
>>>>>> reserved, and JS treating them in a special way.
>>>>>>
>>>>>> So. The *only* reason *not* to introduce a proper global
>>>>>> introspection API is?
>>>>>>
>>>>>> On Fri, 04 Aug 2017 at 10:03 dmitrii at dmitriid.com <
>>>>>> dmitrii at dmitriid.com> wrote:
>>>>>>
>>>>>>> I’d recommend you assume your opponent has done some light reading.
>>>>>>> And I’d suggest you yourself read the links you post (that is, practice
>>>>>>> what you preach).
>>>>>>>
>>>>>>> Multiple reserved keywords have been both added to the language and
>>>>>>> removed from the language. Because *the language evolves*.
>>>>>>>
>>>>>>> However, you (and TC39 in general) keep insisting that
>>>>>>> short-sightedness and ad-hoc solutions is the only way forward for
>>>>>>> JavaScript.
>>>>>>>
>>>>>>> You don’t like System, you think it cannot be used? Oh, introduce an
>>>>>>> `introspect` keyword. Introduce a `system` keyword. Heck, nothing stopped
>>>>>>> you from introducing a language-level built-in in the form of Symbol,
>>>>>>> what’s stopping you now?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, 04 Aug 2017 at 09:55 Jordan Harband <Jordan Harband
>>>>>>> <Jordan+Harband+%3Cljharb at gmail.com%3E>> wrote:
>>>>>>>
>>>>>>>> Because it's been reserved syntax since JavaScript's inception, and
>>>>>>>> System hasn't.
>>>>>>>>
>>>>>>>> I'd recommend some light reading before attempting to continue
>>>>>>>> arguing: https://mathiasbynens.be/notes/reserved-keywords
>>>>>>>>
>>>>>>>> On Fri, Aug 4, 2017 at 12:53 AM, Dmitrii Dimandt <
>>>>>>>> dmitrii at dmitriid.com> wrote:
>>>>>>>>
>>>>>>>>> But you can’t `var x = import`, for example. I guess you can’t
>>>>>>>>> `var import = {}`  either.
>>>>>>>>>
>>>>>>>>> Hmmm… I wonder why…
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, 04 Aug 2017 at 09:50 Jordan Harband <Jordan Harband
>>>>>>>>> <Jordan+Harband+%3Cljharb at gmail.com%3E>> wrote:
>>>>>>>>>
>>>>>>>>>> It can't be made syntax, because `var System = {};` is valid
>>>>>>>>>> code, and we can't break the web. (seriously)
>>>>>>>>>>
>>>>>>>>>> On Fri, Aug 4, 2017 at 12: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 <Jordan Harband
>>>>>>>>>>> <Jordan+Harband+%3Cljharb at gmail.com%3E>> 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/20170804/aeb160d7/attachment-0001.html>