Divide and Conquer: Implementing New Solutions for Convenient Coding or Why UI and JS are Important to Separate

In today's post, our guest blogger Susan Saurel explains why it's important to separate your JavaScript from the user interface (UI)

Even though the divide and conquer tactic is mostly used in wars, it’s not the only place where we use it. Another industry where this tactic is being used is the technology industry.

Especially since the object-oriented programming it’s being implemented in web or mobile applications, this divide and conquer tactic is omnipresent.

The tactic is an integral part of the SOLID programming principle, which is one of the most important programming principles.

• Single Responsibility - This principle states that every module, class or functionality of an application should have only one responsibility. A function shouldn’t both make an API call and manipulate the response. In terms of project structure, the UI, HTML, and CSS should be separated from JavaScript. Divide and conquer much?
• Open/Close Principle - The open/close principle refers to the fact that every software entity should be open for extension, but closed for modification.
• Liskov Substitution Principle - This is the hardest principle to understand. This principle refers to the fact that if B is a subtype of A, then each implementation of A could be replaced by its subtype, B.
• Interface Segregation Principle - Interface Segregation highlights the fact that no methods should be imposed on a client. This means that you shouldn’t add extra functionality to an interface by adding new methods. Multiple interfaces for the same class, not multiple methods for the same interface.
• Dependency Inversion Principle - High-level modules shouldn’t depend on low-level modules. They should depend on abstractions. Which, in their turn, shouldn’t depend on details. The details should depend on abstractions. 

When creating the frontend of your new application or website, unless it’s a static one, you should always make sure the user interface is optimized and that you use the best solutions for convenient coding.

Now, let’s see why you should use the divide and conquer principle when creating the user interface of your new application.

1. Separation of Concern

In computer science, separation of concern is a design principle that focuses on splitting the code into modular components. Each of these components should do one thing and one thing only.

Here are the main reasons why you should do this:

• If your code is split into modules, every one of them focusing on a certain concern, if you are looking to add new functionality, you won’t have to make extensive changes to the application. You will only have to change the module which takes care of the functionality you are looking to modify. For example, if you split your JavaScript from the user interface when you are adding a new page, you won’t have to major changes to the JavaScript file. You will only have to add a redirect which can be done easily.
• If you separate concerns, if you are working on a large-size application, you don’t have to know it exhaustively, when you are looking to debug a certain part of it, it’s ok if you only know how that part works.
• Another important aspect of this design principle refers to the fact that a piece of code that does not change is less likely to break. For example, if you have an application with 4 modules A, B, C, D, and you are working on module D of your application, the rest of the modules are less likely to break because you didn’t touch them, did you?
• Last, but not least, if you implement the separation of concern together with the abstractization principle, it’s less likely that modifications in any layer of your application will need new features. For example, if you want to change the database and use another one, you should only switch the implementation of your persistence layer. You won’t have to make drastic changes to your application.

2. Slower Loading Speed

Think about loading your application as building a wall. There are two methods you can do it.

The first one would be to place the bricks on the ground, bind them, add the paint, and the window, then place the wall where it’s supposed to be.

The second one would be to define its place, place the bricks where they are supposed to be, bind them, paint them and then place the window. Which one of these methods do you think is the most appropriate? The answer is clear, isn’t it?

The brick, in our case, is the HTML, the paint is the CSS, and the JavaScript is the dynamic part of the wall, the window.

The ‘loading speed’ of the first method is drastically increased compared to the latter because you consume lots of resources.

3. Higher Crash Probability

Let’s say you have the HTML, CSS, and JavaScript in one file and they are all loaded at once. The browser will try to render them, but, at some point during the rendering process, a function throws an error. What do you think it’s going to happen? Well, your application will crash and, chances are, nothing will be rendered on the user interface. That’s not pleasant user experience, my friend.

On the other hand, if you keep HTML, CSS, and JavaScript in separate files they will be rendered separately. Meaning that, first, the HTML will be placed on the window object, then the CSS will implement its classes. Lastly, the JavaScript functions will start doing their magic.

In this implementation, if, by chance, a JavaScript function throws an error, chances are a big portion of your user interface, if not the entire user interface is already rendered.

According to Alex McGee, Frontend Developer at College Papers “By separating the JavaScript from the HTML and CSS means that, if the application crashes, the user will have a visible user interface, which, even though it might not be fully functional, is way more than having a blank screen.”

In conclusion, keeping your HTML, CSS, and JavaScript in the same file might lead to a bad user experience.

4. Model-View-Control Pattern - MVC

The Model-View-Control is an architectural pattern refers to the fact that the entire application should be split into three important modules. This architectural pattern is closely linked to the separation of concern principle we’ve been talking about.

• Model - This module represents the shape of the information, the data that you are using across your application.
• View - The view module focuses on the user interface. This is the module that allows each user to interact with the application. It adds dynamicity to the applications. This is the module where your HTML and CSS should be placed.
• Control - The control module, from a frontend point of view, is used to encapsulate the business logic of your application. The user interacts with the View module, which fires a function from the Model This module will then communicate with the Control module. This module sends a request to the backend and when it’s received, through the Model module is rendered in the View module.

Feeling lost? Here’s a simple explanation of the way the Model-View-Control pattern works.

• User Action
  • View module detects the action
    • A function is fired in the Model module
      • This function fires another function in the Control module
      • The backend offers the response back to frontend
    • Information is received by the Control module
  • The information is passed downstream to the Model module
• The information reaches the user interface through the View

According to Adrian Gray, CTO at Custom Papers “The model-view-control pattern is another good reason why the user interface and the JavaScript should be separated. Each part of the application should focus on one aspect. HTML and CSS on the user interface and the Javascript on modeling the information inside the application and easing the communication between the frontend and the backend of your application.”

5. Readability and Maintainability

 Up until now, we’ve been focusing on the theoretical aspects of an application, design patterns, architectural patterns, and functional implementations.

Now, it’s time to focus on the more practical aspects of the divide and conquer principle.

Think of it like this, your HTML code has 300 lines of code, your CSS has roughly the same size, meanwhile, the JavaScript code has in excess of 600 lines of code. Your application is quite dynamic, isn’t it?

Now, how much time do you think it will take you to find a certain <div> inside the HTML or a certain CSS property or, even more, a certain function that makes a backend call?

The second time, think about how much would it take you to find the same elements if they are split into separate files. Instead of a 1200 line file, you will have three files with a lot less code.

You’ve written the code, chances are you will find your elements quite quickly even though they are placed in the same file. But, what if, one of your friends would like to help you out and the two of you start working together? It will take him a lot more than to find those elements. He will need a lot of time just to ramp up.

Conclusion

Even though you might’ve not thought about it, the divide and conquer tactic also applies in computer science. It’s very important to split your user interface elements from the JavaScript functionality because you need to separate the concerns of your application. Each module and each function should have a well-defined purpose with its own file. Next time you want to create a new website or web application, go through this article one more time. This way, the information will be fresh and you will be able to implement the principles correctly.