Good practice with external JavaScript files

Question

I am new to JavaScript.

How do I split my functions into external scripts? What is considered good practice? Should all my functions be overflowed into one external .js file, or should I group similar functions together?

I would suggest that more files mean more HTTP requests to get the script, and this can slow down the performance? However, more files are streamlined: for example, onload.js initializes things at boot, data.js retrieves data from the server, ui.js refers to user interface handlers ...

What are the tips for this?

Thanks!

Answer 1

As Walkley mentioned, you should try the tool. Try Grunt Brunch , both designed to help you with the build process, and you can configure them to merge all your files when you are ready for prod (also minify, etc.), while maintaining separate files.

Answer 2

When releasing a product, you usually want as few HTTP requests as possible to load the page (for example, image sprites )

So, I suggest combining your .js for release, but keeping them separated in what works well for you during development.

Keep in mind that if you "use strict" , concatenation of scripts can be a source of errors.
( more info on js strict mode here )

Answer 3

It depends on the size, number of your scripts and how many of them you use at any time.

Many successful performance practices claim (and there’s good logic in that) that it is good to embed your JavaScript if it is small enough. This reduces the number of HTTP requests, but also prevents JavaScript browser caching, so you have to be very careful. That's why it is a practice to even embed your images (using base64 encoding) in some special cases (for example, look at Bing.com, all of their JavaScript is embedded).

If you have many JavaScript files and you use them at any time (not just as quantity, but as size), you can load them asynchronously (for example, using require.js). But this will require significant changes in the design of your application, if you did not consider it at first (and also increased the complexity of your application).

There is a practice to even cache your CSS / JavaScript in localStorage. For more information, you can read Web Performance Diary.

So, do something like a short flashback. If you have built-in JavaScript, this will reduce the first page load. Built-in JavaScript will not be cached by the browser, so each subsequent page downloader will be slower if you used external files.

If you use different external files, make sure that you use them, or at least most of them, because you may have redundant HTTP requests for files that are not really needed. This will lead to a better organization of your code, but probably to increase loading time (still do not forget the browser cache that will help you).

To put everything in one file, you will reduce your HTTP requests, but you will have one large file that will block the loading of your page (if you use synchronous JS file download) until the file is fully downloaded. In this case, I can recommend you put this large file at the end of the body.

You can use tools like YSlow to track performance.

Answer 4

When I think of good practice, I think of MVC patterns. It could be argued that this is a development path, but many people use it to structure what they want to achieve. It is usually not recommended to use MVC at all if the project is too small - just like creating a complete Windows C ++ application if you just need a simple C program with a for loop.

In any case, MVC or MV * in javascript will help you structure your code to such an extent that all actions are part of the controllers, and the properties of the object are simply stored in the model. The views are then intended only for demonstration purposes and are displayed to the user by special requests or rendering mechanisms. When I watched using MV *, I watched with BackboneJS and the "BackboneJS Application Development" guide by Addy Osmani. Of course, there are many other frameworks you can use to structure your code. They can be found on the TodoMVC website.

What you can also do is get your own structure from your applications, and then use the directory structure for your development (but without the MV * framework).

I do not agree that using such a structure leads to more files, which means more HTTP requests. Of course, this is true during development, but remember that the user should get improved performance (i.e., Compiled) and a reduced version as a script. Therefore, even if you are developing in such an organized way, it makes sense to minimize / remove and compile your scripts using the closure compiler from Google .