Yes and no.
/imports directory will not be automatically bundled and made available client side, unless they are referenced somewhere in your app via an
/import that you don’t use in your application anywhere (don’t reference via
import), they won’t be included in your client side JS bundle. So in one sense yes using modules could help reduce the amount of code sent over the wire to the client.
What isn’t currently supported with Meteor however, is the option of only sending code down the wire to the client when it’s actually needed. So let’s say you have a public site made available via a route of
/public, and an admin site made available via a route of
/admin. Let’s say you’ve built a monster reporting module for the admin side or your application. Ideally you wouldn’t want people accessing the
/public side of your application to download the admin reporting module.
Some tools allow you to split your codebase up into separate chunks of functionality, that are only loaded when they’re actually needed. Webpack does this for example. Here’s a quick snippet from their docs explaining this further:
For big web apps it’s not efficient to put all code into a single file, especially if some blocks of code are only required under some circumstances. Webpack has a feature to split your codebase into “chunks” which are loaded on demand. Some other bundlers call them “layers”, “rollups”, or “fragments”. This feature is called “code splitting”.
It’s an opt-in feature. You can define split points in your code base. Webpack takes care of the dependencies, output files and runtime stuff.
To clarify a common misunderstanding: Code Splitting is not just about extracting common code into a shared chunk. The more notable feature is that Code Splitting can be used to split code into an on demand loaded chunk. This can keep the initial download small and downloads code on demand when requested by the application.