views:

471

answers:

11

For our site, Im using a lot of jQuery - right now Im looking at 340 lines of jQuery code on top of the base library. How much is too much? I will be adding more, when do I start trying to condense the code and eventually move to OOP?

+6  A: 

How much is too much depends a lot on your application.

You should strive to be concise, but not at the expense of readability or user experience.

singpolyma
+11  A: 

The number of lines doesn't mean anything - what matters is what you're actually doing. You could have 10 lines of supremely inefficient code that would do much more damage than a meticulously crafted 1000 lines of code.

Daniel Schaffer
+6  A: 

Optimally, you should keep you script size as minimum as possible, but with today's 'Web 2.0' websites, you will most probably accumulate quite a lot of JavaScript code.

The important thing is that before you deploy your website, make sure to minify and gzip your script files as to reduce the size of your script files as much as possible.

If you are really interested in optimizing and improving your website performance, I highly recommend taking a look at Steve Souders' High Performance Web Sites: Essential Knowledge for Front-End Engineers

Andreas Grech
+3  A: 

I would pay attention to script loading time more than lines of code. If it gets to be too big, break the file down into page or section specific files. "Too much" is based solely on application performance and what you deem to be acceptable for your users.

John Sheehan
A: 

It depends on the project you are working on. You should keep your code efficient and readable. Once you deploy your website, just compress and gzip your scripts and that would improve performance.

Chatu
+1  A: 

340 lines is nothing, try using a few telerik controls...soon gets to 15k+ lines!

redsquare
A: 

Oh ok, Yeah I already have everything in its own .js file. And I practice reusability as much as possible - but this is the first website where I have written a lot of js code, so I just wasnt sure.

jrutter
This should be a comment - not an answer.
Eran Betzalel
A: 

I wouldn't concern yourself with the length of your JavaScript. You have multiple options available to you like using Packer to compress your JavaScript for release (you'll want to practice with it some since it does have a few rules for how it works).

Focus on making sure your code is understandable and easy to maintain. Heavy use of JavaScript in websites can get hairy in a big hurry.

Concerning yourself with trying to make it short or small can hurt you more than if a user has to wait an extra second for the page to load.

Hugoware
A: 

For development it becomes absolutely essential to separate out code into separate .js files or things will get messy.

HOWEVER,

Do not leave a ton of script references in a production page. Most browsers are limited to 2 simultaneous HTTP requests. Those script references will slow down your page load and far outweigh any possible benefit of caching components separately.

You can concatenate your development files into one file using JS Builder:

http://code.google.com/p/js-builder/

Edit: By script references I mean the < script src="blah.js">. Each of those needs to be loaded via HTTP when the page loads.

ifwdev
A: 

What do you mean by script references?

jrutter
by script references he means having many <script> tags in the html.
Erlend Halvorsen
@jrutter this should be a comment - not an answer.
Eran Betzalel
A: 

340 lines of javascript is nothing, but as your javascript code base grows I'd spend some time looking into frameworks for compressing and concatenating javascript on the fly. If you're on Java I'd recommend using JAWR, which lets you switch between multiple references in development mode and a single, minified script in production. Just make sure you test your app in production mode before you go live, as the minification algorithm could screw up your code in some obscure cases (if you write clean code and remember to end every line with a ';' you should be fine).

If you're not on Java I don't know of any frameworks, but implementing something similar yourself actually isn't that hard. I think I have some code lying around somewhere for doing it in eZ Publish, which is written in PHP.

Erlend Halvorsen