No, you should not.
Loading the code into the browser is basically “free”. The only cases where you should consider optimizations are:
- You care very much about initial page load time.
- The scripts you load are being run (perhaps repeatedly) when they are loaded instead of sitting there quietly waiting for you to call and execute them and you have no way of changing that.
What the solution is currently for 1) I’m not sure, except, as you say, put the scripts in the public folder and load them right when you need them. Maybe there could be some “deferred script loading” package developed for Meteor where you could designate that some files are to be loaded later, after the initial work of loading and setting up the page is done. But with that solution every package on Atmosphere should just be updated to use that deferred loading and so its users wouldn’t have to worry about that aspect any more. Or ideally (and probably for now utopically) Meteor could figure out by itself what needs to be loaded when and thus make this aspect fully automatic. I don’t think we’ll have such sophisticated static analysis tools for a while to come, though.
Solution for 2) is probably to open an issue with or send a PR to whatever library you’re using to fix that package’s scripts’ behavior because that violates common expectations / standards / best practices.
Beyond that I suppose it might be that because of the way that the Meteor build system works it might take longer to build with 25 or 50 packages than with a monolithic app that doesn’t use packages, because each build tool has to be invoked X times instead of just once (like SASS compiler, Coffee compiler, minifier (?) etc). But in any case that would absolutely not make the runtime performance of the app any worse at all.
And because Meteor also has a great production build that aligns with current performance best practices it’s not a problem at all to have many small packages and files because they all get concatenated and whatever else is necessary.
And let’s end with highlighting the observation that the Meteor package system is awesome: Very easy to use, handles pretty much everything for you automatically, you can use npm packages in there… it’s a joy to use! And the benefits are very real, namely better modularization of your app and ease of reuse of packages across projects. Which begins to matter more and more the more work you do with Meteor, and many of us here already have lots of concurrent projects going with Meteor, as far as I can tell!