> Oh, and yes, I've loaded upwards of 50-100 modules in development. 20 modules is *easy* to achieve in single-page apps.
was that with some combination of babel/rollup/webpack or pure-es6? if i want to develop a pure-es6 webapp (no babel), how would i transition from development-mode (20 es-module files) -> production-mode (1 rollup file)? On Fri, May 31, 2019 at 10:47 AM Isiah Meadows <[email protected]> wrote: > If it's bundled by Rollup or Webpack into a single bundle, it's > equivalent to a single `<script type="module" src="...">` pointing > towards the original entry point, excluding network requests.* But in > either case, you aren't listing 50 scripts, you're only listing the > entry module and importing child modules within parent modules. Rollup > and Webpack do mostly the same thing browsers do when it comes to > resolving dependencies, just they generate a bundle afterwards where > browsers execute code afterwards. Also, it's worth noting that the gap > between a single large request and multiple smaller requests has > shrunk a lot since HTTP/2 came along, since it's binary, it allows > requests and response data to be interleaved, it better leverages the > underlying TCP protocol format, and it allows servers to send data > pre-emptively without the client requesting it first. (Web sockets are > built on this functionality.) It's still better to bundle in general, > but it's less of a problem not to. > > This is *not* the case for `<script type="module">` elements - those > operate more like inline scripts that happen to have the ability to > `import`. > > Oh, and yes, I've loaded upwards of 50-100 modules in development. 20 > modules is *easy* to achieve in single-page apps. > > * This is, of course, not the case if you are using pure ES6 and you > aren't using any plugins to, say, run the original source through > Babel for React + JSX or something. > > ----- > > Isiah Meadows > [email protected] > www.isiahmeadows.com > On Sat, May 25, 2019 at 2:12 AM kai zhu <[email protected]> wrote: > > > > Asynchronous loading differs only in > > that it takes more code to express the same logic and you have to take > > into account concurrent requests (and you need to cache the request, > > not the result), but it's otherwise the same from 1km away. > > > > > > so async-loading 50 ```<script type="module">``` tags > > has equivalent side-effect > > as sync-loading single webpack-rollup (of same 50 modules)? > > > > i have nagging suspicion of doubts. has anyone tried native > async-loading large numbers (>10) of > > ```<script type="module">``` tags, and verify it resolves identically to > using a single webpack-rollup? > > > > again, i'm not that knowledgeable on es-modules, so above question may > be trivially true, and i'm just not aware. > > > > -kai > > > > On 24 May 2019, at 23:41, Isiah Meadows <[email protected]> wrote: > > > > There's two main reasons why it scales: > > > > 1. Modules are strongly encapsulated while minimizing global pollution. > > 2. The resolution algorithm applies the same logic no matter how many > > modules are loaded. > > > > It's much easier for it to scale when you write the code unaware of > > how many modules you might be loading and unaware of how deep their > > dependency graph is. Fewer assumptions here is key. It's an > > engineering problem, but a relatively simple one. > > > > If you want a short example of how sync module resolution works, you > > can take a look at this little utility I wrote: > > https://github.com/isiahmeadows/simple-require-loader. That doesn't > > asynchronously resolve modules, but it should help explain the process > > from a synchronous standpoint. Asynchronous loading differs only in > > that it takes more code to express the same logic and you have to take > > into account concurrent requests (and you need to cache the request, > > not the result), but it's otherwise the same from 1km away. > > > > ----- > > > > Isiah Meadows > > [email protected] > > www.isiahmeadows.com > > > > On Thu, May 23, 2019 at 10:49 AM kai zhu <[email protected]> wrote: > > > > > > actually, i admit i don't know what i'm talking about. just generally > confused (through ignorance) on how large-scale es-module dependencies > resolve when loaded/imported asynchronously. > > > > On Wed, May 22, 2019 at 10:42 PM Logan Smyth <[email protected]> > wrote: > > > > > > Can you elaborate on what loading state you need to keep track of? What > is the bottleneck that you run into? Also to be sure, when you say > async-load, do you mean `import()`? > > > > On Wed, May 22, 2019, 20:17 kai zhu <[email protected]> wrote: > > > > > > i don't use es-modules. > > but with amd/requirejs, I start having trouble with > module-initializations in nodejs/browser at ~5 async modules (that may or > may not have circular-references). 10 would be hard, and 20 would be near > inhuman for me. > > > > can we say its somewhat impractical for most applications to load more > than 50 async modules (with some of them having circular-references)? and > perhaps better design/spec module-loading mechanisms with this usability > concern in mind? > > > > p.s. its also impractical for me to async-load 5 or more modules without > using globalThis to keep track of each module's loading-state. > > _______________________________________________ > > 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
