0

Is there a difference between having one large Javascript file compared to having many different Javascript files?

I recently learned that a separate application at my office contains two Javascript files for everything it requires. They're almost 2 MB and contain roughly 40K lines of code each.

From a maintainability standpoint, that is obviously awful. I can't imagine dealing with that in SVN. But does it actual make a difference in the performance of the application?

There is a setting for chunked transfer encoding in IIS, but I know little about it beyond what's mentioned in the article there. The "Rationale" section doesn't seem particularly relevant to Javascript. It seems more important for the "actual" pages in the application and communicating back and forth between the client and server.

Tagged with ASP.NET as the setting is under the "ASP" section of IIS... If that's not actually related please edit and remove the tag or let me know and I can.

sab669
  • 3,984
  • 8
  • 38
  • 75
  • 2
    Re: maintainability: You'd build these files using a tool-chain that compiles them from many, small source files. Those would go into SVN (or something modern), not the compiled output. – Thilo Nov 04 '16 at 14:02
  • @Thilo Is that like `UglifyJS` (used by jquery) or other "compactors"? And unfortunately for those poor saps on the other team, it is definitely just 1 giant file. – sab669 Nov 04 '16 at 14:06
  • bundelling smaller files solves both problems, maintainability and performance. – Imad Nov 04 '16 at 14:08

1 Answers1

3

Javascript files are often combined in production environments to cut down on server requests and HTTP overhead. Each time you request a resource, it takes a round trip from the client to the server, which affects page load speed.

Each separate request incurs HTTP overhead, basically extra data that is attached to the request/response headers, that must get downloaded too.Some of this will change with the implementation of HTTP2, and smaller files will become more efficient.

From a maintainability perspective, you'd never want to deal with files that large. Ideally, each JS file should be broken up into a logical module and stored independently in SVN. That makes it easier for the developers to work with and keep track of changes. Those small, modular files would then go through a build process to combine and possibly minify/uglify them to get them ready to be served in a production environment.

There are tons of tools you can use to automate this build process like Gulp, Grunt, or npm. Some .NET content management systems like DNN have settings that allow you to do this automatically in production.

J_Everhart383
  • 354
  • 1
  • 6