Front-end Web Development Refresher

Introduction

In this post, I’ll share my thoughts on the challenges of modern front-end web development, particularly the number of tools and configurations. While I find the development process itself rewarding, the complexity of present-day workflows can be discouraging. The decision fatigue and quite overwhelming number of possibilities when setting it up.

I remember being involved with front-end web development around 2006. Before Webpack, NodeJS, and a plethora of configuration files. Around 2006 jQuery was introduced as well as MooTools. Usually, you would just import one of those JavaScript libraries to aid your cause. The only real challenge was dealing with Internet Explorer, specifically version 6, which for instance did not support transparency in PNG images.

Nowadays we have an abundance of devices and screen sizes, JavaScript frameworks, single page applications and extreme dependency trees and JavaScript itself, which has its quirks. Of course, now with ES6 and maybe TypeScript there are a lot of good ways to make use of the language. Although, working with TypeScript in a convenient way also needs some configuration for auto-compiling on save and such. (Or it could be that things have improved beyond my current knowledge)

Front-end development is really a steep learning curve and needs a variety of skills to navigate the complex nature of it. I am currently exposed to it because I want to setup a simple front-end design, that should be responsive and easy to maintain.

NodeJS and Webpack

Currently, I am not too involved with front-end development. So, let’s see, where do I start again. I know that front-end developers often use module bundlers, such as Webpack or Vite. But Webpack is built upon NodeJS, which is a JavaScript runtime environment. I do not want to use NodeJS for a server, but I do want to use Webpack for automatically bundling my files, so they can be minimized, combined and will load faster. Therefore, it seems I am bound to NodeJS anyhow. It seems I have to start there:

# Windows
winget install openjs.nodejs

# Ubuntu
sudo apt update
sudo apt install nodejs

# Check with
node -v
npm -v

Node Package Manager

NodeJS comes with a package manager called Node Package Manager or npm for short. The package manager keeps track of all dependencies for your project. The dependencies are stored in a directory named: node_modules. This directory is filled with JavaScript and/or CSS libraries, scripts, and other assets. Any imported module you use from node_modules, can be automatically packaged by Webpack.

Besides npm there is another package manager (and several more actually) that you can use instead or even in parallel with npm. Yarn is such an example. Yarn was made to solve problems npm had in earlier versions.

Of course, Vite (also a bundler, but does more and in a different way) and Yarn (package manager) have their places in the development world and fixed shortcomings, but as an “outsider” I would rather have seen just updated versions of npm and Webpack. To me, all these extra tools is where the complexity actually starts. All have their own configuration files and sometimes they have breaking changes. How can I determine the best tools for a specific project?

For the moment I just stick with npm and Webpack, because I did work with them in the past and I do only need something not too complex.

To start a project:

npm init -y

This creates the node_modules directory and a package.json where dependencies are stored.

Webpack config

First, we have to install Webpack via npm:

npm install --save-dev webpack webpack-cli

After a lot of tweaking and reading, my current working webpack.config.js looks like this:

const path = require("path");
const MiniCssExtractPlugin = require("mini-css-extract-plugin");

module.exports = {
  entry: "./src/js/index.js",
  output: {
    filename: "bundle.js",
    path: path.resolve(__dirname, "static"),
  },
  resolve: {
    modules: [path.resolve(__dirname, "node_modules"), "node_modules"],
  },
  mode: "development",
  module: {
    rules: [
      {
        test: /\.js$/,
        exclude: /node_modules/,
        use: {
          loader: "babel-loader",
          options: {
            presets: ["@babel/preset-env"],
          },
        },
      },
      {
        test: /\.css$/,
        use: [MiniCssExtractPlugin.loader, "css-loader"],
      },
      {
        test: /\.(sass|scss)$/,
        use: [MiniCssExtractPlugin.loader, "css-loader", "sass-loader"],
      },
    ],
  },

  plugins: [
    new MiniCssExtractPlugin({
      filename: "main.css",
    }),
  ],
};

Breakdown

For everything you want to do, you have to dive deep into the documentation of the Webpack config files. A necessary break-down of the config file is as follows:

• Line 1: require is a NodeJS defined function that in this case loads Node’s built-in path module. It is used to ensure cross-platform compatibility.
• Line 2: mini-css-extract-plugin can be installed via `npm install mini-css-extract-plugin –save-dev`. More on what this does later.
• Line 4: module.exports is a JavaScript object with the Webpack configuration inside.
• Line 5: Entry is the input of your JavaScript files. So Webpack starts bundling your code here.
• Line 6-8: Output is where Webpack puts the output of the entry. On line 7 and 8 is defined that the output file will be called bundle.js and be placed inside the ./static/ directory.
• Line 10 & 11: Resolve configures how Webpack will resolve modules when they are imported in your own JavaScript files. It prioritizes the local node_modules folder. Interestingly, apparently there is also a global node_modules directory Webpack can fallback to?
• Line 13: Mode “development” gives output that is easier to debug. Can be set to production.
• Line 14 & 15: Module and rules defined how Webpack handles different file types. Each rule has a test which is a regular expression to match the files. An exclude to ignore specific files and directories. Then a use is used to define a tool that processes the matching files.
• Line 20: The babel-loader is used to transpile modern JavaScript (ES6) into backwards-compatible JavaScript.
• Line 26 & 27: Matches CSS files. css-loader interprets @import and url() in CSS files. By default, Webpack makes one JavaScript file out of both JavaScript and CSS files.
• Line 31 & 32: Same for SASS. sass-loader will compile SCSS into regular CSS.
• Line 37-40: This will actually make the separate CSS file instead of parsing CSS into JavaScript.

So, as you can see, this is just a small configuration file, but a lot is happening just to have a simple start. The only way to use configuration files is to read about how to use them.

NPM Run Build

For this specific example to run successfully we need to install additional packages with npm (and any other if you find any dependency issues):

npm install css-loader sass sass-loader mini-css-extract-plugin babel-loader --save-dev

To actually wield Webpack more easily we can, for example, add this to our package.json:

  "scripts": {
    "build": "webpack --mode=production",
    "watch": "webpack --mode=development --watch"
  },

When we type:

npm run watch

In the command line, it will actually bundle our files and generate the output. And with watch (instead of build) it automatically compiles any changes. In my current example this will do the following. I have two scss files:

• ./src/css/main.scss
• ./src/css/navbar.scss

The content of main.scss is:

@charset "utf-8";
@use "navbar.scss";

With JavaScript it is more or less the same. I have two JavaScript files in this example:

• ./src/js/index.js
• ./src/js/menu.js

// example
import "../css/main.scss";
import { BurgerMenu } from "./mobile/menu";

I have index.js import menu.js via an ES6 import statement. Because we defined one entry point in webpack.config.js we need to import our main.scss file here. These 4 input files will be compiled to 2 output files, as you can see in the webpack.config.js. The output will be:

./static/bundle.js
./static/main.css

These output files can be loaded in your HTML document and can be shipped to production later. After thoroughly testing of course.

Complexity

From this working basic setup, we might also start working with TypeScript. Maybe add a CSS framework like Bulma, PureCSS or Bootstrap. Or maybe also a development platform like VueJS, React or Angular? We could also consider lodash and axios, or some other JavaScript libraries. And before I forget, what templating mechanism should we use for our HTML templates…?

Front-end development asks for a mixture of tools, technologies and skills and the level of freedom in setting it up makes it complex to me. With a programming language like C#, you usually don’t really have to figure out what frameworks, bundlers, dependency managers or build configurations to use, because it typically comes with a more structured, standardized and cohesive ecosystem.

In other words, the fragmented (choice rich) ecosystem of front-end development is what I think makes it complex. If I would compare this to rules in traffic, what if every city can choose its own set of traffic rules? Would that make it better? Sometimes less is more. I’ve heard people say that JavaScript is easy. Maybe easy to learn, but with all quirkiness and freedoms I find it one of the hardest languages. But even with easy to learn I do not agree in that regard. Maybe it’s easy to “just start” and get some initial output, but it’s hard to provide a robust and high-quality product and code base. TypeScript was probably made with a reason.

Possible Solutions or Helping Factors

To reduce the complexity (in a broader sense) of front-end web development:

• More opinionated frameworks could help, so that you spend less time configuring.
• Choose technologies that fit your preferences and tastes. If it works, it works.
• A new hype or technology does not have to be the best choice for your project.
• Create an archive of configuration files so that you can reuse them.
• Create skeleton setups so that you can start developing sooner.
• Document your setup process, why you chose specific tools and configurations.

Conclusion

As a bit of an outsider of front-end web development, I tried to create more clarity for myself by writing about it. I did help me actually to reflect on things and get a better understanding of the tools. I want things to be simple, straightforward and clear while not compromising too much on a professional approach.