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 <[email protected]> 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+%[email protected]%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 >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
