How many packages is too much

packages
1

Hi All, new to here (and to Meteor also)

Everyone loves packages, me too. However, I was wondering average count of packages per application on community, especially on production apps. So, as a total newbie for meteor I am looking tips if It is ok to shoot my app like 25 external packages or not?

Cheer’s
Erno

2

It’s totally OK! In some sense, using more packages means you write less code.

3

too many packages for what?

4

If the packages are maintained then it’s definitely ok. In theory your entire application could just be separate packages that you either get from atmosphere or that you develope in house. Meteor as a framework is nothing more than a group of independent packages that work together.

5

If you take a look at this Meetup Presentation there may a number of reasons also to design your app (your own code) as packages.

6

Thoughts on “module oriented” vs packages?

7

Even though you can write less code using more packages, wouldn’t the app take more time to load?

8

Let’s say I have an community like app for the Bass Players.

For the core for our app we need iron:router, account packages (1-3)
Collections2, spinner and others, you name it.

We also want to app behave and look good so we need bootsrap.
And then we have Jquery, and lets say 5 jquery plugins. Then we need 10 other cool js components like timelines and carousel.

So, we can easily end up having 25 packages for the looks and features. What I was thinking was that instead of putting all these js 10 components in by packages for example, should I consider loading them in traditionally on pahe level when needed?

Also, I cant stop thinking: more packages = slower app ???

Cheers and thanks for your comments so far

Erno

1 Like
9

I’m not sure how it follows that more packages = slower app. The code has to get to the browser one way or another and using packages is a really easy way to manage it.

My recommendation would be to use and abuse packages like there’s no tomorrow to get a prototype out the door. If people like what you’re doing, you can always optimize later.

6 Likes
10

No, you should not.

Loading the code into the browser is basically “free”. The only cases where you should consider optimizations are:

  1. You care very much about initial page load time.
  2. 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!

Cheers,
Denis

1 Like
11

Thanks man, thats what I call A Reply.
Cheers
Erno

1 Like