import.meta and TC39 process as a whole

Fri Aug 4 12:54:30 UTC 2017

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/e3181aa1/attachment-0001.html>