How do you organize your Javascript code? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Because this question may lead to opinionated discussion, debate, and answers, it has been closed. You may edit the question if you feel you can improve it so that it requires answers that include facts and citations or a detailed explanation of the proposed solution. If edited, the question will be reviewed and might be reopened.

Closed 8 months ago.

Improve this question

When I first started with Javascript, I usually just put whatever I needed into functions and called them when I needed them. That was then.

Now, as I am building more and more complex web applications with Javascript; taking advantage of its more responsive user interaction, I am realizing that I need to make my code more readable - not only by me, but anyone who replaces me. Besides that, I would like the reduce the moments of 'what the heck, why did I do this' when I read my own code months later (yes, I am being honest here, I do have what the heck was I thinking moments myself, although I try to avoid such cases)

A couple weeks ago, I got into Joose, and so far, it has been good, but I am wondering what the rest do to make their chunk their codes into meaningful segments and readable by the next programmer.

Besides making it readable, what are your steps in making your HTML separated from your code logic? Say you need to create dynamic table rows with data. Do you include that in your Javascript code, appending the td element to the string or do you do anything else. I am looking for real world solutions and ideas, not some theoretical ideas posed by some expert.

So, in case you didnt't understand the above, do you use OOP practices. If you don't what do you use?

• Yuriy N.: My answer to similar question: stackoverflow.com/a/56115623/2534191

Answer 1

For really JS-heavy applications, you should try to mimic Java.

• Have as little JS in your HTML as possible (preferably - just the call to the bootstrap function)
• Break the code into logical units, keep them all in separate files
• Use a script to concatenate/minify the files into a single bundle which you will serve as part of your app
• Use JS namespaces to avoid cluttering up the global namespace:

var myapp = {}; 
myapp.FirstClass = function() { ... }; 
myapp.FirstClass.prototype.method = function() { ... }; 
myapp.SecondClass = function() { ... }; 

Using all these techniques together will yield a very manageable project, even if you are not using any frameworks.

• James Black: I forgot about the namespaces. This is an excellent response. You can also try to use private and protected variables, not everything has to be public.
• Asaf: @JamesBlack Not always practical in JS. The methods defined through prototyping can't access the private variables as they have to be defined as local variables in the constructor function then accessed through closure by methods defined there as well.
• theblang: I have recently been doing a ton of reading and research to try and figure out how to get a handle on my JavaScript organization. This is by far my favorite way of doing it.

Answer 2

I use unobtrusive javascript, so, outside of the script tags I don't keep any javascript in the html.

The two are completely separated.

A javascript function will start when the DOM tree is completed, which will go through the html and add the javascript events, and whatever else needs to be changed.

In order to organize, I tend to have some javascript files that are named similar to the html pages that they use, and then for common functions I tend to group them by what they do, and pick a name that explains that.

So, for example, if I have UI functions then I may call them: myapp_ui_functions.js

I try to put the name of the application in the filename, unless there is some javascript that is common to several projects, such as strings.js.

• David: This is correct, I'd just like to add that this is more easily accomplished with jQuery or Prototype.
• DLS: Nice, I like the idea of having Javascript files similar to the HTML pages(I do this too for large applications). I do like the unobtrusive code. It makes my blood boil to see "onclick" event right on a HTML tag.

Answer 3

I have (usually) one file that contains a bunch of functions and that's it. That is included in every page that uses Javascript. In the pages themselves, I'll make the calls to the functions like:

$(function() {
 $("#delete").click(delete_user);
 $("#new").click(new_user);
});

where delete_user() and new_user() are defined in the external file.

I too use unobtrusive Javascript, which for me means jQuery (there are other libraries that are unobtrusive).

You don't want a separate file for each page. That just means more unnecessary external HTTP requests. With one file—assuming you've cached it effectively—it'll be downloaded once and that's it (until it changes).

If I have a large amount of Javascript or the site is effectively split into multiple areas then I may split the Javascript but that's not often the case.

Also, in terms of my source code, I may have multiple JS files but I'll often end up combining them into one download for the client (to reduce HTTP requests).

More at Multiple javascript/css files: best practices? and Supercharging Javascript in PHP.

• strager: I made a depandency system which allows me to call load('level') and the Javascript will request 'javascript.php?jquery;jqueryui;level'. The PHP appends all the files requested into one response (and would optimally minify and cache it). This means I can split up my Javascript and almost always it is more efficient than loading one large file (because I don't load what I don't need).
• strager: Still, I do like your idea of creating separate functions to ... do certain things ... Hey, it sounds obvious now, but it didn't when I was writing my code! xD
• Ionuț G. Stan: @strager, re your second comment. Yeah, one of the pitfalls of lambdas.

Answer 4

I prefer to organize JavaScript code using objects (classes) based on functionality.

Theory

• Classes are named after functionality they implement, e.g. ContextMenu, UserList, Dialog etc.
• Each class goes into its own file named after the name of the class. E.g. context_menu.js, user_list.js etc, not constants.js, authentication.js and so on. The files have no other code besides the class definition.
• Class constructor is used to attach events using Unobtrusive JavaScript approach and create any HTML a particular feature requires. <template> tag is used if dynamic HTML is needed.
• There is a single file called app.js, which serves as a kind of entry point which creates objects from classes found in above mentioned files. Obviously, they need to be loaded first.

---

Practice

Say, we are implementing a class to represent a context menu. We create the new class ContextMenu and declare that it can be used as a module:

context_menu.js:

export class ContextMenu {
 constructor() {
 this.#createHtml();
 document.addEventListener('click', this.#close.bind(this));
 target.addEventListener('contextmenu', (e) => {
 e.stopPropagation();
 });
 }
 #open() {}
 #createHtml() {
 const container = document.createElement('ul');
 container.classList.add(this.#containerCssClassName);
 container.hidden = true;
 this.#container = container;
 document.body.appendChild(container);
 }
}

Then in some another module we are importing the menu and start using it:

app.js:

import { ContextMenu } from "./context_menu.js";
const menu = new ContextMenu();

---

• Irrelevant method implementations were omitted for brevity.
• A real world example and the full code listing can be found at the ContextMenu project repository.

Answer 5

I've been rewriting a lot of my reusable code as jQuery plugins. I moved to jQuery from Prototype when I started doing ASP.NET MVC. Overtime I've migrated a lot my reusable code, or at least the ideas, from Prototype-based OO to jQuery-style plugins. Most of these are stored in their own JS files (mainly intranet apps so page load speed is pretty high anyway despite the extra requests). I suppose I could add a build step that coalesces these if I needed to.

I've also settled on a MasterPage approach that uses a ContentPlaceHolder for scripts that is right before the closing body tag. The standard jQuery/jQuery UI loads, and any other common JS goes right before the script placeholder in the MasterPage. I have tiny bit of JS at the top of the MasterPage that defines an array that holds any functions that partial views need to run on page load. These functions are run from the base document.ready() function in the MasterPage.

All of my JS is completely separate from my mark up. Some JS may exist in partial views -- these are encapsulated when the partial may be included more than once to make it specific to that instance of the view -- but generally not. Typically only included in the placeholders so that it's loaded at the bottom of the page.

• DLS: I like the idea of jQuery plugins, but say you have lots of events happening in your application, how do you break down the event handling portion? Any code you're willing to share? I like looking at another person's code to see what I can do to improve myself.
• tvanfosson: You can find a couple of my plugins on my blog: farm-fresh-code.blogspot.com.

Answer 6

Also, if you want to go OO heavy, check out mochikit: http://www.mochikit.com/

• DLS: David, For now, I am married to jQuery as I introduced it to my current web development team and my future one in 5 days. But, I will definitely check it out.

Answer 7

I find that developing your javascript using OO methodology is the way to go if you want it to be clean, readable and even somewhat secure. I posted the following question

Cleanest format for writing javascript objects

And got some fantastic responses on how to write my javascript code well. If you follow these basic principles you can use almost any library, such as yui, jquery and prototype, with ease.