When dealing with websites with large amount of javascript, i see that these are still usually served to the client as one large javascript file.
In the development phase, are the javascript files usually split up (say there are >300 lines of js) to make things abit more manageable, and then merged when the website is 'put live'? Or do the developers just put up with working in one long large file?
In my experience — having separate files in development is the norm. It certainly makes life easier when you need to hunt for code or have multiple people working on different parts of the system.
We place different modules/classes/parts in separate files and use a proper build process to
An example of how to use Ant for this can be found in one of my projects here http://github.com/oyvindkinsey/easyXDM/blob/master/build.xml.
I also have projects where the webserver automatically merges the files, localizes and then minifies them before serving the client.
So stick with whats manageable, using separate files, but do remember that if you use error reporting then the line numbers will point to the concatenated version.
It would be ideal to have multiple javascript files depending on the class and functionality (like you have them for java project ) in development environment.
However when you are deploying the js file in production, you should concatenate all js file in a single file and have them referred by your web application. That will make thing easy
Note: It would also be advisable to use javascript compressor to reduce the actual size and hence saving bandwidth.
Developement differs from company to company and from developer team to developer team.
I for myself am used to the approach of implementing functionality step by step, storing those functionalities in seperate files and merging everything together in most cases - at lease when i am not the only one working on a given project.