Using webpack 2 and NPM to bundle various resources of a web application part 1: introduction

Introduction

Single Page Applications (SPA) have definitely become very popular and fashionable lately in the world of web development. An SPA has a single HTML page, as its name implies, and uses a large amount of JavaScript files to modify that single page with new content as the user clicks around in the interface. In contrast, traditional web applications serve up a complete HTML page upon every new request and rely on a relatively small amount of JavaScript to work. We can call these traditional web apps as multi-page applications or MPAs.

In an MPA there’s a lot of traffic between the browser and the server as the browser requests new HTML content to be rendered for the website user. The amount of HTTP traffic in an SPA is a lot smaller as much of the rendering and website interaction is delegated to the client via JavaScript files. An SPA front-end typically consults the web server for some set of information, such as a filtered list of products, and the web server responds with a document in some format, most often JSON. The client then takes this JSON document and renders it in a way that’s understandable for the client, like a fancy table. The web server hosts an API which any client can contact via HTTP calls and an SPA front-end is no exception.

Advantages of a single-page application

Here are some of the advantages of an SPA:

• Fewer HTTP requests between client and server
• Easier to build rich client applications with a lot of user-friendly functionality
• An SPA often has a fluid interface which makes it feel like a traditional desktop application, thereby enhancing the user experience
• AJAX is used extensively to only update that part of the page which the user has requested
• The load on the web server will also be a lot smaller due to the reduced HTTP traffic
• There’s no need to load static content such as JS and CSS files upon every single request – they are loaded once on the first request

In other words a significant part of the “energy” it takes to build a single web page is delegated to the client. The web server is offloaded so that a single server can satisfy more end users. Therefore we can potentially server more end users with the same infrastructure. Each component in the infrastructure can concentrate on its main task: the back-end will mainly contain the business logic and security features and the front-end will take care of the “fancy stuff”. The front-end and back-end components are therefore decoupled to a higher degree than in an MPA. We don’t need completely separate applications for the web and mobile interfaces of our business. Instead, the back-end API can be common. It’s enough to build a mobile-friendly interface with e.g. Bootstrap or Bulma. If your business requires a separate mobile application, then it can also get its data from the same back-end API, the mobile application can concentrate on the UI.

This all sounds great but SPAs also come with a number of disadvantages:

• They rely heavily on JavaScript so if it’s disabled in the browser then the SPA becomes unusable by the client
• The total number and size of JavaScript files in an SPA can be very large with tens of thousands of lines of code. The total load time of the page will increase a lot due to the large number of scripts
• Securing JavaScript applications tends to be more difficult than securing traditional back-end based web apps
• Many features that we get from the browser by default, like the Back button, scroll position, browsing history are missing from an SPA since we are on the same page all the time. Note that there are frameworks to avoid these problems when working with a JS framework such as React or VueJS but these features are not provided to begin with unlike in a traditional web app
• Search Engine Optimization and page analytics must also be given extra consideration since they depend on real page loads by default

The JavaScript in an SPA kind of tries to take over some of the responsibilities of a web browser. We need to give extra considerations to features that we normally think of as given like the behaviour of the Back button of the browser. Designing an SPA is definitely not easy and you’ll invariably end up using some JS framework to alleviate the issues. The below list includes some of the most popular JS frameworks to build SPAs:

• React JS
• Angular
• Vue JS

Webpack

So where does webpack enter the scene? Webpack is a packaging and resource bundling tool whose primary goal is to solve the second problem in the list of disadvantages, namely the large number of JS files. A common practice in SPAs is that the JS code is divided into many relatively small JS files with a specific purpose: main.js, header.js, customerService.js etc. These files are also called JS modules. It’s similar to how we normally produce lots of small files in the back-end code to ensure the separation of concerns. Webpack takes all the JS files of the SPA and puts them into a single minimised JS file whose name is most often bundle.js. This bundle includes all the code from the constituent JS files and is served to the client instead of all the single small JS files.

The various JS files also often have dependencies so that the order in which they are loaded matters. E.g. footer.js might need the services of culture.js to format the current date. Therefore culture.js must be loaded before footer.js otherwise footer.js will break. Webpack also takes care of this aspect.

Webpack also comes with a number of other benefits depending on the plugins added to the bundling flow:

• ES6 language features can be translated into their ES5 equivalent so that older browsers can also understand them. This way the front-end developer can use the new features in ES6 without having to wait for the browser manufacturers to catch up.
• The JS code can be checked for styling depending on which JS style library was loaded where JSLint and AirBNB are two examples but there are many out there each with its own set of JS styling rules
• It can also package other static files like images and CSS scripts
• As mentioned above, webpack “understands” the dependencies of the various JS files and creates a dependency graph for the correct ordering of the dependencies when the bundled JS file is built

The main disadvantage of webpack is that it’s complex. Of course complexity is relative but most newcomers to webpack think that it’s difficult to start with and painful to configure. However, VueJS, ReactJS and Angular have all adopted it as their main build tool. If you want to explore those technologies then webpack is difficult to avoid.

The goal of this series is to give you an easy start on webpack. Hopefully by the end of the series you’ll have a good basic understanding of how it works. We’ll start some basic coding in the next post.

View all posts related to JavaScript here.