At Fyle, we are constantly on the lookout for ways to improve our website appeal, outreach and performance. This includes keeping layout designs fresh, updating blogs, refreshing imagery and pushing out timely promotions and advertisements. We also keep on updating the content by adding to or switching it based on specific goals. But, greater is the frequency of updates in a website, greater is speed of development or changes in code base and thus, greater are the chances of acquiring code debt in the process. This is where our journey to a progressive bundling process starts…
Problem overview
We kept on experimenting with designs and different UI components on the website which looked pretty neat to the user but what went behind the scenes was not really sophisticated. We kept on adding everything and anything(all sorts of UI components; forms, cards, carousels, navbar, footer, conversion and tracking scripts etc) in a single javascript file called main.js. We exceeded 2000 lines of code in there and the harsh truth was that we were serving this file to the browser as it is, without any minification. This hit us hard on performance, and in turn affected our SEO rankings as well. As developers, we felt real pain while debugging and maintaining the file.
This common javascript file is the villain and the hero of the story. You didn’t follow me, right? Well, you will get to know about it as we talk about it further…so hang on here :)
Enter the term: module-bundling
Back in the day, it was enough to concatenate scripts together. Times have changed, though, and distributing your JavaScript code can be a complicated endeavor. Now, a bundler like webpack is required because we know we need to concatenate and compress our JavaScript anyway, and managing load order isn’t something you wanna handle manually.
This blog will deep-dive into how we splitted, bundled, compressed, optimised and served our javascript using webpack. In short, we started from one huge js file and ended up in one small js file, but webpack did it all with ease! Listing down things we needed to achieve with a module bundler
After brainstorming and multiple rounds of reviews, research and team discussions, we enlisted the following pointers as our functional requirements.
Segregate the large javascript code into multiple smaller files. Bundle these smaller files together into a common js file. Run the bundled js file with minification in production mode. Reduce the number of HTTP requests. For better maintenance and development experience: Run the bundled file without minification in development mode - for better and easier debugging. Watch the code changes, serve them and reload the page automatically. Lint the javascript code - for a unified approach and neater syntax.
A comparison of build tools we shortlisted
We had many solutions as choices. Including multiple js files as external scripts in HTML, dynamic imports in the browser, dynamic script loading, uglification and concatenating using gulp and so on. We did detailed research on these and ultimately we attained a solution which met all our requirements and that was WEBPACK.
Webpack was an easy winner!
Simply put, webpack is such a powerful tool that it can already perform the vast majority of the tasks you’d otherwise do through a task runner.
In addition, webpack can be run as middleware through a custom server called webpack-dev-server, which supports both live reloading and hot reloading. By using loaders, you can also add ES6 to ES5 transpilation, and CSS pre- and post-processors. That really just leaves unit tests and linting as major tasks that webpack can’t handle independently. Getting started is really simple. If you’re just looking to bundle a bunch of JavaScript files together without any other fancy stuff, you won’t even need a configuration file. Let’s get started then!
Setting up Webpack
Before we can use webpack, we need to install it. To do that, we’re going to need Node.js and npm, both of which I’m just going to assume you have. If you don’t have them installed, then the Node.js website is a great place to start. Now, there are two ways to install webpack (or any other CLI package, for that matter): globally or locally. We installed it locally as it is easy to upgrade and there are chances of global installation failing, in case we run applications using a different webpack version.
Breaking down one huge main.js file into smaller js files
We splitted our entire javascript code base into 6 smaller modules/files. This was done based on the functionality of the code written: Common module: handles features which are used almost on all the pages on our website Business module: handles logic related to business Pricing module: handles code related to our product’s pricing details Resources module: handles code related to resources Forms module: handles code related to our demo form Analytics module: handles code related to GA and other events we use to track visitor behaviour
What did we achieve using webpack as our assets bundler?
This is just the beginning of our story…
We are still improving and optimising our website project with the super cool webpack; using latest ES6 syntax by transpiling the code, adding eslint to lint the javascript code, adding different configuration files of webpack for development and production modes, utilising svg sprites, removing redundant css and a lot more exciting stuff lies in the pipeline!
This was our first step towards using webpack and the rise of the hero of this story - bundled js file. This was one of the most interesting and comprehensive tasks I worked at Fyle.
By the way, we are also planning to make the fylehq website open source soon, so reach out to us with suggestions or share your webpack heroic stories with us!