Where identifiers have unique names there should not be any collisions. What is the actual code tried?
On Sat, Jun 1, 2019 at 1:51 AM kai zhu <[email protected]> wrote: > > Place all of the code to be exported in 1 file? > > that obviously will not work, because of module-scope collision. can > anyone share their experience on deploying a [babel-free] pure-es6 > application with 20 es-modules rolled-up into one [production] bundle? is > it even possible? > > > On Fri, May 31, 2019 at 7:55 PM guest271314 <[email protected]> wrote: > >> > how would i transition from development-mode (20 es-module files) -> >> production-mode (1 rollup file)? >> >> Place all of the code to be exported in 1 file? >> >> > with some of them having circular-references >> >> Not certain how that is possible when using ```import``` within >> ```<script type="module">```? >> >> > how many async-modules can js-app practically load? >> >> Again, how many have you tried to load? 100? 500? 1000? Either should be >> possible. >> >> What specific issue are you actually to resolve? >> >> On Fri, May 31, 2019 at 5:40 PM kai zhu <[email protected]> wrote: >> >>> > 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 >>> >>
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
