So best practice is now to move all imports closer to where they are actually needed (e.g. inside functions) instead of being listed at the top of a file.
Doing such moves in the current Meteor version does not break the app, so it’s good to start making code changes right now. Then when 1.5 is released performance improvements will happen because of such code changes.
I hope all official code in tutorials and guides will be modified as soon as possible to help bring about this new best practice.
It’s never that simple - it’s up to what is best for your app. Tutorials are not meant to represent what is best for every single app.
It would be interesting to know the cases when it would not be good to move imports closer to where they are actually needed.
This is something that many (me included) have been awaiting for. Great job MDG! Can’t wait to test it out for myself.
So basically breaking out module imports and delaying loading outside startup allow them to be cached since they’re not bundled together? Great stuff.
Good to see MDG has addressed a few of my main gripes with meteor, i.e., build times and startup times…
Omg, the Meteor Gods have listened to all my bitching and whining. FINALLY!
I AM SO GOD DAMN EXCITED ABOUT THIS FEATURE!!!
Props to @benjamn and team for making major moves.
awesome blog post idea:
Show the one-for-one examples of doing code splitting in meteor 1.5 VS. webpack. This would be nice to see (for those familiar with how to set it up/use it in webpack).
Thanks for everything 
Meteor is fantastic and I love that it is always challenging and keeping me learning.
Like some other people, I’ve been turned off Meteor on occasion… and I have looked around at other solutions out there - but the simplicity of everything Meteor does keeps me here. Always excited for what is around the corner.
@abhiaiyer True story, you were one of the first to complain about bundle sizes and ask for code splitting (post 1.4.2).
Best is his last words : “Make Meteor fast again” …