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