import.meta and TC39 process as a whole

[Dmitrii Dimandt]

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

<
mailto:kai zhu <kaizhu256 at gmail.com>
> wrote:

a, pre, code, a:link, body { word-wrap: break-word !important; }

> 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
mailto: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/204d4df2/attachment-0001.html>