Inline. On Wed, May 9, 2018, 04:25 kai zhu <[email protected]> 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). 2) 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? > 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
