Yeah, I definitely understand why Meteor would have that requirement but now I really worry about MDG’s choice in naming this feature “dynamic import”, given that they are only implementing part of the specification. It really is only lazy loading and not true dynamic import. I hope they make that clear when they release Meteor 1.5. Regardless it is a great addition and I am looking forward to it.
Keep in mind that import() path cannot be fully dynamic (e.g., import(Math.random())). Rather either completely static (e.g., import(’./locale/de.json’)) or partially static (e.g., import(’./locale/’ + language + ‘.json’)).
Correct me if I’m wrong but wouldn’t having the option to automatically download the entire app but defer lower-priority modules (but still download them) be superior to this download-and-load-modules if requested approach? That way all parts of the app are ready to be consumed by the user upon request? This is similar to ordering routes in the order of usage (although of course this optimization will probably result in a un-noticeable speed performance improvement).
I think this matters if the additional dynamic import requests are slower than the user will notice, perhaps >1 second. If the dynamic imports are small enough, perhaps they will likely be so fast the load time doesn’t matter (which I’m guessing is the case for most of them). So I’m wondering what the latency + load time of each additional dynamic import request is and will work to measure this once I get a chance to play with dynamic-import more.
It’s definitely possible to build the system you’re talking about on top of this one! That could be a very cool thing to add, and doesn’t sound like it would be very hard. However, as a default I feel like loading on demand is better since some people have data caps etc.
@sashko and @jalligator I did see that kind of approach when I once had the developer console open while loading a Facebook page. FB downloaded about 5 megabytes on initial page load but didn’t stop after that, strongly hinting it was precaching some components.
There was a discussion on this here, a good analogy to this approach is online video streaming and the buffering that happens while watching video.
It seems that components buffering technique is the next logical optimization that can be build on top of dynamic imports as sashko hinted. We need to optimize for both initial load time and routes transitions time, the code splitting crucial for large apps initial load time, while the “components buffering” is an optimization that can be built on top of dynamic imports to speed up in the routes transition time.
I’ve gone ahead and done the FlowRouter implementation as in the first post, but… I see all of those files loading in my app.js (in dev), and can also see them (minified) inside my prod js file. Is that right? Or am I missing something? I thought the whole point of this was to keep components from loading if they weren’t needed (eg, admin pages or an obscure part of the website).
Just to be clear, if you want to be able to use the [import directive] anywhere within Meteor (client or server), we must put the stuff we intend to import somewhere inside a [imports directory] that lives under root?