import.meta and TC39 process as a whole

Fri Aug 4 13:11:53 UTC 2017

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/
> blob/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/86656dbc/attachment-0001.html>