Pushing javascript too hard with Script# and javascript?

Question

So I have been playing around with a home project that includes a lot of js. I having been using Script# to write my own library etc. Personally I wouldn't write a lot of js if I didn't have a tool like Script# or GWT to help maintain it.

So far it includes these external libraries: – ASP.NET AJAX – ExtJS – Google Maps – Google Visulisations – My own library to wrap the above libraries and add extra functionality...

So that works out to be a heap of js. It runs fine on my pc. I however have little faith in js/browsers and I am concerned that loading too much js will cause the browser to die or perform poorly.

Is this a valid concern?

Does anyone have any experience with loading a lot of js into the browser that has resulted in performance issues? I however know there are a lot of variables here, for example browser type (I assume IE is worse than others) the client PCs RAM etc, but it would be good to get other peoples experiences. I would hate to invest a lot of time into js only to find that I am painting myself into a corner.

The more I use Script# the more client classes I have as I move more processing onto the client. At what point would this start becoming an issue? I'm sure the browser could easily handle 100 MS Ajax classes but at what would be too far for a browser?

NOTE: I am not concerned about the actual js file sizes but more the runtime environment that gets loaded.

Answer 1

with modern browsers routinely occupying 250 MB of RAM or more, script caching, and optimized javascript engines, keeping the script library resident would probably be negligible added load in most reasonable scenarios.

the biggest bottleneck would probably be intitial load time of the scripts - downloading and parsing them. but once that's done, the scripts are cached and the per-page initialization isn't very noticeable.

Answer 2

I agree with jspcal, you should be able to load quite a lot of javascript with no problems. The javascript engines in all the modern browsers are a lot faster than they were a few years ago. The initial load will be the biggest issue. If possible I'd suggest lazy loading scripts that aren't needed for the page to render.

Also, Steve Souders has a lot of great material about improving page load times, such as this article, which gives several techniques for loading scripts without blocking.

http://www.stevesouders.com/blog/2009/04/27/loading-scripts-without-blocking/

If you're really concerned about performance then I would take a look at your target audience. If you think you'll have a relatively high number of IE6 users then test it out in IE6-- on an older machine if possible. IE Tester is great for this.

Answer 3

I highly doubt a browser would ever crash running your JS scripts, but it will become really slow and may not perform what you want. Most people are more concerned about how fast it runs, not if it will run!

Answer 4

Hi,

There is nothing wrong with having large number of js files or big js files, the project currently am working on got more than 60 core framework libraries and 30 of each module got average of 5 to 6 js files.

So the only concern is how you design your website that make use of the JS best practices & optimization techniques. like

1. Minimize the JS using YUI or any other compression libraries to address the download size issues.
2. Enable proper caching in your webserver to reduce the file downloads.
3. Put your javascript in the bottom of the page, or make it a separate file.
4. Make your AJAX response cachable.
5. And finally, design your page that handles the on-demamnd script loading.
   - Microsoft DOLOTO is a good example for this one. download it here

And Check out the High Performance Web Sites && latest Even Faster Web Sites by Steve Souders. Its a must read for the web developers. This book addresses all the common problems web developers facing today.

Cheers

Ramesh Vel