import.meta and TC39 process as a whole

Fri Aug 4 13:05:35 UTC 2017

I'd like to refocus this thread myself. I have to dig around for the
meeting notes where it was decided that import.meta should proceed over
`import meta` but I do remember there was no rationale other than
consensus. Can some of you who physically attend those meetings provide a
real comparison and some of the whys for that consensus?

A different thread should be used to discuss:
- TC39 process
- keyword meta properties in general
- API centric reflection
- Module Loader features not related to module context specific meta data

- Matthew Robb

On Fri, Aug 4, 2017 at 3:20 AM, Dmitrii Dimandt <dmitrii at dmitriid.com>
wrote:

> I’ll reply to several emails with one, so as not to spread more-or-less
> similar texts over multiple small emails.
>
> > whatwg/loader was too big of a spec. It was floated around in various
> forms for at least 5 years. Despite the very hard work of its champions it
> didn't garner enough implementer support.
>
> And the reason is: it was supposed to be a properly designed spec. That is
> why it was big. Because you either do it properly, or not at all
>
> > I think history has proven now that incremental improvements are more
> likely to succeed, so I'm happy to see import() and import.meta be able to
> go through the process at a relatively swift pace.
>
> No. These are not incremental improvements. These are ad-hoc solutions
> that beget more and more ad-hoc solutions. Calling it “incremental
> improvements” is putting slapstick on a pig.
>
> Let’s take dynamic imports as a prime example of a horrible no-good ad-hoc
> solution and how it begat a horrible no-good ad-hoc solution in the form of
> import.meta.
>
> import is a keyword. It’s scope and usage are known, simple, and
> understandable.
>
> What is import()? It looks like a function, it behaves like a function
> (it’s invoked like a function, it accepts parameters like a function, it
> returns values like a function). Except it’s not a function. In *some*
> contexts it is a function:
>
>     import(‘blabla’).then(() => …)
>
> In *other* contexts it is not:
>
>    [‘bla’, ‘bla’].map(import) and others
>
> To quote myself from an issue: "So, what is this new import? A new
> keyword? No. A builtin function on par with eval, parseInt et al? Why does
> it override the name of an existing keyword? Wouldn't it be better to
> introduce module-related functionality into a new global Module object
> exposing Module.import, Module.importAsync etc.?”
>
> Well, the only somewhat-valid argument for the dynamic import is this:
>
> > I suggest you to look at previous discussions about import, and why it
> is different (a hint: it is different because like super, it needs some
> contextual information).
>
> Let’s consider this:
>
> - super() is a *new* function-like keyword that doesn’t override behaviour
> of an existing one. It has its clearly defined place where it can be used,
> and, well, it is a function call as it ends up calling user-defined
> functions (etc. etc. etc., see https://github.com/tc39/
> proposal-dynamic-import/issues/23#issuecomment-263439543)
>
> - the argument for context is especially funny considering how import.meta
> started
>
> First of all, this is a language you design. There’s nothing stopping you
> from providing context to System.load. Or Loader.import, or…
>
> Second. Let’s see how import.meta proposal started (
> https://esdiscuss.org/notes/2017-05-23#16iiia-accessing-
> host-specific-module-metadata-from-inside-a-module):
>
>    > Probably a good idea to do import * as module from "js:context"
>
> See? Since you scrapped proper implementation in favour of an ad-hoc
> solution eschewing common sense, now you scramble to find ad-hoc solutions
> to your ad-hoc solutions. Let’s just for a second assume you went with
> Module.import(). All of a sudden you’re free to extend Module with a
> Module.context or Module.meta, define it as Introspection API and have fun
> with it. Instead, you go for this (can’t find the link right now) in favour
> of import.meta:
>
>   > Yes, we have new.target, super.* and function.sent as precedent
>
> That is, you take horrible ad-hoc design decisions and present them as
> viable precedent.
>
> This morning literally in the span of time between stepping out of the
> shower and finishing my morning shave I came up with a solution that does
> away with new.target, function.sent and import.meta.
>
> It’s called System.context (especially useful with
> https://github.com/tc39/proposal-optional-chaining)
>
>     System.context.function.{sent, target, what,have,you},
> System.context.module.{whatever,meta,info,you,might,want,to,slap,on}
>
> See. Suddenly you have an infinitely extensible introspection API that you
> can (ab)use to your heart’s content instead of sodomizing the rest of the
> language. But that would require some sort of long-term thinking instead of
> ad-hoc (sorry, incremental) short-term solutions.
>
> There is a reason PHP became a laughing stock in programming community.
> However, it took way more than 10 years to arrive at
> mysql_real_escape_string and \ as namespace separator. At the current rate
> JS will surpass PHP within a year or two.
>
> On Fri, 04 Aug 2017 at 08:46 kai zhu <kai zhu
> <kai+zhu+%3Ckaizhu256 at gmail.com%3E>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170804/c1d76a69/attachment.html>