views:

285

answers:

5

Hello,

I'm starting to learn JavaScript and jQuery. I managed to do some tweakings and stuff, everything's fine so far. But I was thinking if it is a best practice to mix multiple jQuery files and plugins. For example:

I have jQuery 1.3.2 min.js, jQuery easing 1.3.js, jQuery Cycle min.js and jQuery UI. Would it be recommended to put together jQuery (main), jQuery easing and jQuery cycle in just one file?

Please give me some light here.

Thanks,

+2  A: 

No, I would keep the files separate. It keeps the functionality separate, and makes it easier to re-plugin any later versions of the plugins should you want.

Also, by editing the file to include all plugin code, you are inherently introducing risk, as the file itself will not have been subject to the testing of the original code base authors.

Certainly, I would argue any benefits are considerably outweighed by the pitfalls.

James Wiseman
I would lean towards keeping the files seperate just because of the possible problems variables being named the same, not having things seperated by namespaces, etc. If you want to cut down on bandwidth, minifying the code before deployment may be something to look at.
Chris
Thank you very much for your clear answer. You guys got a strong point there. I'm much more relieved now to see that it's not a crime if I compile them or keep them separated.
Vitor
Got a downvote for this. Not that I'm bothered, but it would be nice to know wh
James Wiseman
Hey James,It wasn't me. o_O
Vitor
Hehe, I guessed that from your response anyway. Glad to be of help.
James Wiseman
I didn't down vote, and this is a little late, but I wouldn't leave all the files separate (if you plan on serving them yourself). @Chris The files he is talking about are all the jQuery library files so there probably isn't a naming conflict. @James I agree with your argument about how you now have a file you have never tested, but that risk is minimal if it is a file of jQuery plugins. You can also keep the functionality separate during development and compile them at runtime.
Mark
+5  A: 

You can do so. It saves the amount of HTTP requests to haul all the JS code in. It is only a bit harder to maintain, but in my opinion it doesn't outweigh the benefits you (and the client!) have with less HTTP requests.

If you're using a server side language and good deployment tools, you can even automate the minifying and merging of JS files before publishing. We also do it here with a little help of YUI Compressor and a few lines of Java code in a batch application. Works great, the endusers have the benefit of less HTTP requests and the developers have the benefit of not doing all that merging and maintainence manually.

BalusC
Thank you very much for your clear answer. I was afraid it would be considered an "rough" thing, you know. :-)
Vitor
+4  A: 

Given that Google is thinking about considering site response speed as a qualifier for rank you may be better off compiling all JS into one file. YSlow is a good tool for helping you determine the most optimal way to do this sort of thing.

Darrell Brogdon
YSlow is indeed a great performance analysis tool, but I don't see how that would help in the decision whether to minify JS files or not. Even more, YSlow *recommends* to do it, regardless of what you have. This just implicitly answers "yes, you should do".
BalusC
@BalusC Right, thats basically what I was trying to say in my long-winded way. :)
Darrell Brogdon
Thank you very much for your clear answer. I'm not very familiar with dealing with YUI itself, but I'm willing to learn. If I use an online YUI compiler the results will be the same?
Vitor
I think so. Just be sure to test test test after compression. :)
Darrell Brogdon
+5  A: 

Keep the files separate and use your back-end to minify and gzip them as part of your deploy process. As others have mentioned this will save your users making unnecessary requests and it will save you having to maintain a huge ugly file.

The added benefit here is that you can actually keep the verbose, commented, full files for all of these in your source tree (for reading/etc) while serving the compressed ones to users.

thenduks
Thank you very much for your clear answer. Awesome tip aobut the back-end gzipping, but I'm on a shared hosting that currently doesn't support that. :-( Damn...
Vitor
You can Gzip the output manually. Details depends on the server side language in question.
BalusC
Usually you need to enable gzipped asset support in apache, afaik. It's ok if you can't get that working with shared hosting. Just remember to revisit when you move to VPS :)
thenduks
+2  A: 

This is probably a late answer, but I would try to serve as many files as I could from the Google, Microsoft, etc CDN's. Even if you reference multiple files, the chances that someone already downloaded file from some other site is high and they will avoid downloading it again.

As for custom, in-house, JavaScript, I write 99% of my JS in a jQuery plugins, even if I am only going to use that plugin on one form. Then I can combine all my JS into one file, run it through Google Closure, and have it ready to go.

The other 1% is where each page invokes the plugins and passes whatever params it needs.

Mark
Thanks a lot, Mark. You gave me a lot of insights here. :)
Vitor