Discuss
  • Dynamic `import` with options

Dynamic `import` with options

# Isiah Meadows (7 years ago)

Yeah, it's about that time. I'm proposing adding support for an options object as a second "argument" for the call-like import(), something like import("./foo.mjs", {...options}). To complement this, I also propose adding a hook to allow embedders to optionally return something different from the call rather than the usual import and/or change the way something is imported.

Isiah Meadows me at isiahmeadows.com, www.isiahmeadows.com

# Isiah Meadows (7 years ago)

Missed the list somehow...

---------- Forwarded message ---------- From: Isiah Meadows <isiahmeadows at gmail.com>

Date: Tue, May 8, 2018 at 8:43 PM Subject: Re: Dynamic import with options To: Peter Jaszkowiak <p.jaszkow at gmail.com>

Here's three scenarios that aren't even possible without it:

There's other use cases, too:

Isiah Meadows me at isiahmeadows.com, www.isiahmeadows.com

# kai zhu (7 years ago)

or … we could avoid integration-level headaches that shouldn’t even exist, by avoiding es6-modules altogether and

  1. sticking with well-understood require(...) in nodejs and not cross-cut it with import(…, options), and
  2. sticking with well-understood global-assignment of modules in browsers (with long/descriptive names to avoid name-clash).

but … we need es6-modules/import to manage frontend-projects that load dozens/hundreds of modules in the browser! no, that’s a backend-thinking design-pattern, that's idiotic on the frontend and often leads to web-project failure, due to all the integration-problems it entails in practice.

most of us honestly should learn to write leaner, frontend glue-code that doesn’t require dozens of superfluous modules; or hire better/trained frontend-engineers who can; rather than place faith in “scalable" frontend-solutions that falsely assume most UX-problems can be solved by throwing 10x clueless backend-engineers at it (resulting in 10x useless and hard-to-integrate “frontend” code).

a normal web-project with about a dozen frontend-modules shouldn’t require complicated es6-module infrastructure at all. and if it successfully evolves to the scale of something like facebook or gmail, your frontend-engineering-team is more likely to come up with a custom module-framework better-suited for your specific use-case than again, rely on es6-modules (and entrust your at-scale, product-specific, module-loading issues to tc39’s design-by-commitee process).

kai zhu kaizhu256 at gmail.com

# T.J. Crowder (7 years ago)

On Wed, May 9, 2018 at 9:25 AM, kai zhu <kaizhu256 at gmail.com> wrote:

or … we could avoid integration-level headaches that shouldn’t even exist, by avoiding es6-modules altogether and

Yes. I talked to my team of average developers, and many were increasingly of the opinion that they’d all made a big mistake in coming down from the trees in the first place. And some said that even the trees had been a bad move, and that no one should ever have left the oceans.

(With apologies to Douglas Adams)

-- T.J. Crowder

# Isiah Meadows (7 years ago)

Inline.

On Wed, May 9, 2018, 04:25 kai zhu <kaizhu256 at gmail.com> wrote:

or … we could avoid integration-level headaches that shouldn’t even exist, by avoiding es6-modules altogether and

  1. sticking with well-understood require(...) in nodejs and not cross-cut it with import(…, options), and

The issue is with cross-platform (Node + browser) code, which often, you want to share application logic between the front and back end (which is simpler).

  1. sticking with well-understood global-assignment of modules in browsers

(with long/descriptive names to avoid name-clash).

This is exactly what led people to modules - name clashing gets increasingly difficult and it's harder to maintain. And in my experience, most namespacing issues are not with my code (where I get to choose the names), but with others' code, my dependencies. Dependency hell is a bitch, but npm's structure + file-based (not namespace-based) modules completely sidestep the problem. And this isn't unique to highly advanced web apps - even some more traditional web sites have to contend with this.

Also, it's far more convenient and readable to do new Foo() with a local import than new app.page.feature.Foo() (my job's code base has numerous classes with namespacing thay deep*). You don't need to be at Google scale to still want some level of sanity.

* Fun fact: we have about half as much front-end code as backend code, and very little of it includes any real logic. It's mostly presentation and integration code, with most of the logic (and some presentation) in the backend. But even in integration code, it's useful to have at least static imports.

but … we need es6-modules/import to manage frontend-projects that load dozens/hundreds of modules in the browser! no, that’s a backend-thinking design-pattern, that's idiotic on the frontend and often leads to web-project failure, due to all the integration-problems it entails in practice.

The front-end benefits IMHO were way too over-hyped, I agree (bundling and prototyping excluded). But it's in the back end where you really start seeing benefits. Node's require is incredibly slow, enough to be a performance burden on many applications. If you can parallelize and optimize module resolution, that would be very helpful for them, and that's one of the main reasons for making import() async.

most of us honestly should learn to write leaner, frontend glue-code that doesn’t require dozens of superfluous modules;

Sounds like a great idea in theory. In practice, there is an unavoidable amount of complexity to everything - not all apps can be kept this simple.

or hire better/trained frontend-engineers who can; rather than place faith

in “scalable" frontend-solutions that falsely assume most UX-problems can be solved by throwing 10x clueless backend-engineers at it (resulting in 10x useless and hard-to-integrate “frontend” code).

a normal web-project with about a dozen frontend-modules shouldn’t require complicated es6-module infrastructure at all. and if it successfully evolves to the scale of something like facebook or gmail, your frontend-engineering-team is more likely to come up with a custom module-framework better-suited for your specific use-case than again, rely on es6-modules (and entrust your at-scale, product-specific, module-loading issues to tc39’s design-by-commitee process).

Problem: if we have N different standards, how are companies supposed to share their own open source code?