In the previous post we first briefly discussed the output that webpack generates in the bundle.js file. Simply put, webpack extracts the dependency graph from the various JS input files and organises the elements into functions that in turn are placed into an array. The functions in the array are invoked in a sequence that reflects the dependency graph. Then we also built a minimal HTML page to execute the bundle in various browsers. Our ES6 code was successfully executed in all of them except for IE11 which is obviously too old to correctly interpret the new ES6 features. We would see the same in older versions of Chrome and FF as well.

In this post we’ll explore another great feature of webpack, namely the ease at which we can add plug-ins to the bundling process. We’ll specifically add babel.js to transform ES6 code to ES5. The point here is that JS developers want to be able to use the latest and greatest of ES6 and other future versions of JavaScript without having to worry about JS support across various browsers.

In the previous post we successfully configured webpack and executed it to create a bundled JS file in the build folder. We saw that the bundle.js file is larger than the two small input JS files together. That’s understandable as the generated bundle contains a lot of configuration code that webpack added on top of the file.

In this post we’ll briefly look at the generated bundle and also create a HTML page to execute bundle.js.

Like this:

Say you’d like to divide an integer, e.g. 20, into equal parts of 3 and distribute any remainder equally across the groups. The result of such an operation would be the following 3 integers:

7,7,6

20 can be divided into 3 equal parts of 6 and we have a remainder of 20 – 6 * 3 = 2. 2 is then added as 1 and 1 to the first two groups of 6. The result is a more or less equal distribution of the starting integer.

Share:

Like this:

We looked at the basics of using ES6 generators in this post. Generators also come with symbol iterators which can be applied to objects. A symbol iterator helps us implement a custom iterator for our objects. We can declare how our object should behave in a for-of loop. Symbol iterators also involve some weird syntax but generators are weird anyway so a little more weirdness should be fine.

In the previous post we started setting up a minimal project for our webpack demo. We installed Node.js so that we can create an NPM project where NPM stands for Node Package Manager. We also installed webpack as a development dependency and discussed the difference between development and production dependencies in an NPM project. We went through the role of the package.json file and saw where the dependencies are installed on disk. Finally we added two JS files to our src folder but left them empty.

In this post we’ll first briefly discuss dependencies between JS modules. Then we’ll go ahead and configure webpack, activate it for our demo project and run it using NPM.

In the previous post we introduced the topic of this series which is the basics of webpack. Webpack is a bundling and packaging tool whose primary goal is to bundle the various JS and CSS scripts and images into minimised files that are faster to download in a web browser. Webpack is often associated with Single Page Applications that heavily rely on JavaScript to render and re-render the same page according to the actions of the website user. To be more exact, the various popular JS frameworks like React or Vue use webpack behind the scenes to build a deployable package out of a set of components of an SPA. Normally the command line tools associated with these frameworks, like the React command line interface (CLI), already have webpack configured that fits most needs but it’s still good to understand how webpack works and what it does in isolation. Otherwise newcomers to the technology don’t even dare to touch the webpack configuration file since it seems to perform a lot of woodoo magic.

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.