I was wondering, when using import vs the normal client/ and server/ directories.is there any performance difference during production [I don’t think there should be any] or during development with changes [not sure but it seems to have some difference].
The reason I am asking…
is when I look at the structure i was working with, I noticed there are a few modules that I would have to import and I keep on having to list them manually and repeating myself to manage it.
The most major advantage I can see with imports is I can turn modules on and off rather than deleting or moving them. The bad side effect of this one is I may not know which files are not even imported and can be removed.
The advantage of the drop on the spot is you don’t have to deal with explicit imports, but you have to make sure you know the order things are loaded.
I use a combination of both, individual components which I would have to import anyway because I use ESLint and have configured that I need to declare any variable/class/object I would use. Examples of this are ReactJS components, Angular modules, routes?, collections.
The two criteria where I would choose to put into imports are
- it needs to be imported by other modules
- it has an
export (including Angular HTML templates that now export the templateUrl, thanks @Urigo )
Then I have those that do not export anything I put into client or server.
Though after doing the ReactJS version of my boilerplate, I was thinking that for a Meteor project the routes (assuming I am using flow-router) should just be in /routes/ as it is used in both client and server. Though I also thought if I had a large application, I may want to keep it as an import and manage it using an index.js file so I can turn routes on and off as needed.
1 Like
/imports does Lazy loading which may effect performance.
If you have some asynchronous initialization, even if order doesn’t matter functionally, you may want to make sure it gets called fast and first for a faster first load.
That said, all the above are just thoughts. Would be neat to see some benchmarks.
The thing is every script eventually gets loaded at the beginning provided that there are no useless scripts. Unless you’ve seen otherwise. (Please say you have, I am curious how that would occur).
How do you get that? From what I can tell from the source the are not loaded with <script async ...
Even if everything loads, it could effect performance. For example computationally if file1 is loads, finishes processing, and is garbage collected all before file2 loads, it could help performance. I’ve had to take approaches like this when memory is a limiting factor to prevent thrashing.[quote=“trajano, post:3, topic:23267”]
How do you get that?
[/quote]
I’m again thinking computationally. An example may be a database query that has to run on the server startup. That query can run in the background while the rest of everything loads, then finish it’s execution. It would be helpful for performance if this asynchronous call were done early on, so other stuff could load while the server waits for the database to respond.
All of this is very theoretical. If there’s a strong performance concern benchmarks should be done. Otherwise keeping code maintainable is usually preferable to premature optimization.
Yup sounds like it. It seems moot on --production mode because all the scripts get bundled into one JS file. So there’s no async loading per se.
Anyway from what I can tell on http://www.html5rocks.com/en/tutorials/speed/script-loading/ the scripts individually are loaded in parallel asynchronously, but is still executed in order. So whether I “lazy” load things vs control the order of the only computational time it would save is the managing of the download threads and release of the download threads, but the scripts are still going to be computed sequentially at the end.
Anyway Meteor is primarily a toy exercise for me not my day job so I’d like to know what it can do in case I have to refer other people to use it. That’s why I am prematurely optimizing my boilerplate as much as possible 