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 [email protected] > On 9 May 2018, at 8:43 AM, Isiah Meadows <[email protected]> wrote: > > Missed the list somehow... > > ---------- Forwarded message ---------- > From: Isiah Meadows <[email protected]> > Date: Tue, May 8, 2018 at 8:43 PM > Subject: Re: Dynamic `import` with options > To: Peter Jaszkowiak <[email protected]> > > > Here's three scenarios that aren't even possible without it: > > - Hot reloading: https://github.com/nodejs/node/issues/8443 > > - Loading modules uncached: > - https://www.npmjs.com/package/import-fresh > - https://github.com/nodejs/node/issues/8443#issuecomment-382316960 > - Automatic re-runs of module-based tests in the browser. > > - Loading modules with mocks: > - https://www.npmjs.com/package/proxyquire > - https://www.npmjs.com/package/mock-require > - https://nodejs.org/api/esm.html#esm_dynamic_instantiate_hook > (requires a synthetic module and a lot of boilerplate to do it, > though) > > There's other use cases, too: > > - Integrating `import` with `WebAssembly.instantiate`: > https://webassembly.org/docs/js/#webassemblyinstantiate > - Easier importing relative to another directory (important when > dependencies get involved). > ----- > > Isiah Meadows > [email protected] > www.isiahmeadows.com > > > On Tue, May 8, 2018 at 8:04 PM, Peter Jaszkowiak <[email protected]> wrote: >> What are some use cases, and how are they easier done this way than through >> existing alternatives, like returning a factory function. >> >> On May 8, 2018 17:57, "Isiah Meadows" <[email protected]> wrote: >> >> 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 >> [email protected] >> www.isiahmeadows.com >> _______________________________________________ >> 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
