import.meta and TC39 process as a whole

Fri Aug 4 13:16:02 UTC 2017

And here is the notes from progressing the proposal to stage 2:
https://github.com/tc39/tc39-notes/blob/master/es8/2017-05/may-25.md#15iif-importmeta-for-stage-2

- Matthew Robb

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

> 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/m
>> ay-23.md#16iib-module-import-options-discussion-potentially-for-stage-1
>> https://docs.google.com/presentation/d/1p1BGFY05-iCiop8yV0hN
>> yWU41_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/3
>>> 5#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/4a4ae90b/attachment-0001.html>