Utility Cart

Home > Uncategorized > Utility Cart

February 8th, 2010 admin Leave a comment Go to comments

Utility Cart
Should I reference more than one Javascript source file?

I'm creating a website and I have many javascript/Ajax functions. The functions are complex and involve many utility (private) functions. I could just put all the functions in one source file, but that might be cumbersome. Would it be wise to "tier" the javascript by, say, putting all the data access logic on one source file, all the business logic in another file, and all the display logic in another file? Or can I separate the logic by components, like creating a shopping cart object on one file, a customer object on another file, and a catalog object on another file? Or should I just put everything on one file? What do the pros usually do?

Thanks.

There are trades to be considered between logical structure to minimize the programmers' efforts and performance benefits on the server and for the user. Using more files allows you to segregate the modules into recyclable, mix-and-match collections of utilities and devoted modules; this approach is easier to develop, maintain, and evolve over time...minimizes the cost of the developers. Packing everything into a single file cuts down the number of HTTP request/response cycles, making the app appear more responsive to the user; additionally, if the scripts are minified (all comments and white space removed), the real performance is improved, since the total number of bytes transfered is reduced significantly.

The concerns are assessed as:

- how many files
- how big are the files
- how sophisticated are the developers
- how available are the programmers

Heuristically speaking...

- If there are only a few small files, multiple files is probably best.
- If there are a few big files, it's probably okay.
- If there are many small files, it's probably okay.
- If there are many big files, it's probably time to integrate them into one file and perform optimizations such as minification.

The tricky part is to determine how to assess the expression "few files" and the terms "small" and "big" for files. It could mean more time than it's worth to make the effort to figure these issues out in most cases.

We don't often use the big libraries such as the YUI, JQuery, etc., but when we do, the minified version are the ones deployed to production. We rarely employ more than 5-6 files in total for any page. The best test is your own development level experiences with performance and the user-testers reports of their experience. If the page loads are terribly slow, refactoring the scripts may be useful, but only in conjunction with consideration of all issues that affect transfer volume and the number of HTTP request/response exchanges. Usually, we start looking hard, if the initial page-load with a clean cache - everything has be retrieved from the server with new requests - takes longer than 5 seconds...refreshes longer than half that are bothersome. Ideally, we want no more than maximum 5 seconds initial loads and less than 3 seconds refreshes.

It's important that visitors have a good experience. It's important that server resources aren't overburdened pointlessly. It's important that programming and support costs aren't outrageous. Finding the balance ain't a science - it's an art.