First of all the docs are very well written. Whosoever has written them, bravo! I was going through the section on modules, http://docs.meteor.com/#/full/modules. I need some help understanding the following,
If you would like a module to be evaluated lazily (in other words: on demand, the first time you import it, just like Node does it), then you should put that module in an imports/ directory (anywhere in your app, not just the root directory), and include that directory when you import the module: import {stuff} from “./imports/lazy”. Note: files contained by node_modules/ directories will also be evaluated lazily (more on that below).
Lazy evaluation will very likely become the default behavior in a future version of Meteor, but if you want to embrace it as fully as possible in the meantime, we recommend putting all your modules inside either client/imports/ or server/imports/ directories, with just a single entry point for each architecture: client/main.js and server/main.js. The main.js files will be evaluated eagerly, giving your application a chance to import modules from the imports/ directories.
Does that mean all files are loaded the first time an app is loaded in the browser? What is the difference between lazy evaluation and asynchronous loading?
I believe it means that the file won’t be executed/loaded unless it is explicitly imported somewhere
Asynchronous loading could be something like webpack’s code splitting feature or an ES6 module loader like systemjs which can execute files on-demand as you navigate throughout the app
See sections 4.3, 7.1 and this comment on the article you linked for more info.
React is just javascript, it works the same way as your other modules
So, essentially, all client JS is sent to the client at startup, including all dependencies. However, a module is only loaded/executed when importing? I think I get that, it’s intuitive, thanks.
If I wanted an implementation that sent the minimum possible amount of code to the client at startup and than sent code as someone navigated along, what tools would I use?
With the current implementation, as is, all code is sent over to the client at startup and all the ‘talk’ between the client and server is just data?
This is commonly referred to as “code splitting”, and is one of the main features of tools like Webpack. Currently the Meteor build system doesn’t support it directly, but if you search the forums you can see many examples of people integrating Webpack and having features like this. But it definitely comes at the cost of some added complexity.
Meteor will bundle & send only the modules that were imported so, if you have a module inside an import folder that is never imported, it won’t be sent to the client or evaluated
I did indeed try @benoitt’s webpack implementation a week ago. It worked very well but I could not figure out how 1. to compile differently for client and server and 2. how to share code between them (ex. sharing collections). But that’s a topic for another place.
Thanks for your comment.
It would be nice to have code-splitting for two reasons, methinks,
not to have everyone download components that would be loaded conditionally with RBAC (thus being totally un-available to un-authorised users). Sometimes the admin users have heavy dependencies not needed for the casual guest or the logged-in user.
and 2. the obvious speed-ups.
I think I’ll go with the current implementation for now.
A guide by MDG or by the community in http://guide.meteor.com/ on code-splitting would be much appreciated.
Yeah right now code splitting is just not a feature that is supported in Meteor 1.3, and has all of the issues you mentioned. Perhaps in a future Meteor release. We’re well aware this would be an awesome feature to have!
