Book Image

Modular Programming with JavaScript

Book Image

Modular Programming with JavaScript

Overview of this book

Programming in the modular manner is always encouraged for bigger systems—it is easier to achieve scalability with modular programming. Even JavaScript developers are now interested in building programs in a modular pattern. Modules help people who aren’t yet familiar with code to find what they are looking for and also makes it easier for programmers to keep things that are related close together. Designing and implementing applications in a modular manner is highly encouraged and desirable in both simple and enterprise level applications. This book covers some real-life examples of modules and how we can translate that into our world of programming and application design. After getting an overview of JavaScript object-oriented programming (OOP) concepts and their practical usage, you should be able to write your own object definitions using the module pattern. You will then learn to design and augment modules and will explore the concepts of cloning, inheritance, sub-modules, and code extensibility. You will also learn about SandBoxing, application design, and architecture based on modular design concepts. Become familiar with AMD and CommonJS utilities. By the end of the book, you will be able to build spectacular modular applications in JavaScript.
Table of Contents (17 chapters)
Modular Programming with JavaScript
Credits
About the Author
About the Reviewers
www.PacktPub.com
Preface
2
Review of Important JavaScript OOP Concepts
Index

A look at a non-modular example


Let's consider an extremely simple example and see how the (somehow) specialized modular approach differs from a non-modular one.

We start by writing a couple of functions in the traditional way, as following:

function doAddition(num1, num2){
  return num1 + num2;
}

function doSubtraction(num1, num2){
  var result = null;
  if(num1 > num2){
  result = num1 - num2;

  }else{
    result = num2 - num1; 
  }
  return result;
}

console.log(doAddition(3,2)); // displays 5

console.log(doSubtraction(3,2)); // displays 1

As you can see in the above code, we have two independent functions for doing simple additions and subtractions and there is no relation between the two, other than the fact that they both operate on the two passed-in numbers (numeric values).

If we had implemented these functions in an application and were to do the identical operations in a different application, we most likely would either rewrite the same functions in that application from scratch or we would copy/paste the code from this application into the other one.

What if we now decided to also do multiplication, division, and other related calculations in our application using the same approach?

Well, one way would be to just continue writing independent functions as above and add them to our application. This approach could work and would get the job done, but probably not in the best way, since as the code grows it will become more disorganized and chaotic.

By using this approach, not only would we be polluting the global namespace with a bunch of global functions that could possibly collide with other global functions of the same name. We would also end up with scattered pieces of code that had not been packaged together based on their functionality and specialization.

If all such functions do mathematical calculations of one kind or another and that is the commonality that they all have, how about if we create a package (module) that specializes in mathematical calculations?

This would allow us to have a specialized package that regardless of the application that it is hosted in, would always provide the same specialized functionality.

Let's even imagine a step further and assume that we created this package in a separate JavaScript file that can be added as an independent module to any application.

Even better, how about if this module only would get added (requested from the server, in the case of a client side web application) to the application at runtime, and only when needed?

This type of implementation would give us the ability to load chunks, pieces, or modules of the code when needed at runtime and then unload them when the application does not need them anymore. This would enable us to cut down on the footprint of our application on the client side while providing all the necessary functionality as needed and on demand.

Such an approach can also be very useful on mobile devices which have limited bandwidth and resources to be leveraged.

Rest assured that I do intend to explore all such possibilities with you in the later chapters of this book.