Modern Web development with WebPack
Some context elements!
Note : The aim of this post is give you a quick look on WebPack and other tools and why we choose to use them. This is not by any mean a tutorial.
Although Wassa started as an app development company, our web development needs became more and more important as the time passed. Because we were not a Web agency from the start (and we’re still not), we didn’t master all the fancy frontend and backend sweets that has been around for some time now. Of course, we had made some tests with AngularJS, React, SASS, etc. but those remained “experiments”.
Whether it was to create full websites, APIs or complex back-ends, the complexity of both our functional needs and the technologies we had to work with grew quite rapidly. And doing all this stuff with plain Javascript and a bit of jQuery was not enough: poor code architecture, long development time, more bugs…
So it was time to convert our “experiments” to real, tangible projects. For many reasons we won’t explain here, most our projects now make use of the following:
- WebPack with super cool plugins
- Angular (4) with TypeScript
- Sass
What’s the problem, really?
One of the main reasons we waited so long to dive into modern tools, was we thought they will be bringing a long learning curve, performance loss and code complexity.
But at the end, we ended up having files with a lot of scripts and stylesheets imports, like the following:
What’s wrong with that? Well, a lot. Here are a few items:
- Language nightmare: JavaScript (ES5) is just the worst langage in the world. Yes, I mean it. The whole thing is completely flawed and outdated
- Architecture nightmare: with Javascript/jQuery, it’s really difficult to build a good, modular and extensible architecture
- Copy/Paste nightmare: a lot of duplicated lines, especially in CSS files
- Global space nightmare: so many variables are stored in the global space for them to be “shared” across scripts
- Network nightmare: for a single page, almost 30 HTTP requests are made by the browser. That WAY too much
- Reload nightmare: each time we made the tiniest modification, the page had to be reloaded
TypeScript, aka “Javascript nightmare killer”
Created by Microsoft to fill the (many) gaps left by Javascript, Typescript brings Web development to another level. Of course you could use Javascript ES6 wich is much better but its support is limited to recent browsers.
TypeScript comes with a lot of features you can expect from a modern OO language. Among them:
- Generic types Interfaces
- Optional function parameters
- Arrow functions (aka “self nightmare killer”)
- JSX support
- ES6 compliance
Below is an example. If you are used to plain Javascript, there will probably be a lot of new stuff. If you come from a modern OO language however, you will not find much fancy stuff.
Now what’s important to know is no browser is able to interpret TypeScript out of the box, you must use the TypeScript compiler to generate plain Javascript code. Of course, we will see below how to automate this process.
References:
Angular, aka “Architecture nightmare killer”
I won’t go into the Angular/React war and explain why we chose Angular over React. Actually, we didn’t per say. Although most of our projects use the first, maybe we will use React for future projects. At the end, the choice should be made by analyzing the pros and cons of each one for your projects.
One thing I could say however is : “Use a framework”. Light or heavy, whichever. Unless you work on a very small project, you will quite always benefit from a framework.
Here are some features of Angular that we mostly use :
- Two-way data binding
- Dependency Injection
- Component dynamic loading
- RxJS support
SASS, aka “Copy/Paste nightmare killer”
As for Angular, I will not discuss about why we use SASS over LESS or PostCSS. Even more than for the Angular/React war, there is a good chance that we use something else than SASS in future project.
Anyway, the bottom line is : how can we make CSS great again (© you know who)? Although CSS3 is very cool to create shiny and animated websites, it really misses great tools to make developers’ life easier.
That’s where SASS enters. With SASS, you will be able to (among others):
- Use variable (aka. copy paste killer)
- Create nested rules to have cleaner CSS files
- Create Mixins to avoid duplication of whole chunks of code
- Import files
- Create inherited selectors
At Wassa, we often create variants of a same WebApp with only some design changes, mostly colors. With pure CSS, we have to manually change all selectors containing the color to be changed, which can be quite painful if there are many. Of course, any modern IDE can do search & replace, but what if you only want to change SOME selectors ?
With SASS we can do that:
Of course, you can’t use SASS directly in your browser. You will need to compile your SASS files to CSS files prior to publish them. Just like for TypeScript.
Modules, aka “Global space nightmare killer”
Well, modules are more than just this. Actually, they could be 2 or 3 of the XXXX nightmare killers.
As WebApp become more and more complex, I can’t think of any decent project that could not benefit for a modular conception. If you have at least a little experience in programming, in whatever language, you know what I mean.
With the old fashion way, if you wanted a lib to be available to other scripts, you had to:
- Include the lib BEFORE the other scripts. Yes, order DOES matter
- Store data to be shared in the global space, making it available to all scripts, including those who didn’t care.
With a modular conception, you can do this for example:
Instead of polluting the global namespace by sharing the ProgrammingLanguage class with all scripts (which is wrong), the class is now exported and every script that needs the class has to explicitly import it.
Modules have been around for quite some time now, with 2 main implementations : CommonJS and AMD. Javascript ES6 has also its own implementation but is limited to recent browsers only.
What is WebPack?
From the official site:
WebPack is a module bundler for modern JavaScript applications. When WebPack processes your application, it recursively builds a dependency graph that includes every module your application needs, then packages all of those modules into a small number of bundles — often only one — to be loaded by the browser.
So basically, after running WebPack, you get:
What happened?
Well, too much to explain. But basically, the main steps are:
- WebPack go through all your project files and create a dependency graph from all your modules
- WebPack packs all files into a single or more bundles (only one in the example above)
When we say “all your project files”, we mean the ones that are actually used of course. If you write a JS file that is never imported, it will not be processed.
Why is it good?
For many reason, including:
- Limit the number of files the browser will have to download
- Use every static resources as modules, making possible to load them when you really need them
- Use external libraries as modules, for the same reason as above and for source code modularity
- By packing your files in more than one bundle, you can lazy-load parts of your app (try not to create too many bundles or you loose the benefits of WebPack)
Loaders
By default, WebPack will only bundle Javascript files. But we said it’s interesting to pack CSS, TypeScript, etc. So how can we do?
We’ll use loaders. Loaders are just meant to… well, load and preprocess all non-Javascript files. Multiple loaders can be chained for a single file type if you need different pre-processing.
Remember when we said we have to compile TypeScript and SASS? Well, it will be the job of loaders: they will run the related compiler (tsc for typescript and sass for… you know) to transform the source file into something your browser can interpret. All this automatically of course.
WebPack has a list of most common loaders.
Plugins
Simply said, plugins do what loaders can’t do. They have access to the entire compilation lifecycle, allowing them to alter the compilation process as needed.
WebPack has a list of built-in plugins.
Static files as modules? Why?
Let’s say you have an image file you display the old-fashion way. It will works until you change the name of the file or move it to another location. Then the browser will not display the image but it could be difficult to be notified about the error if you don’t check yourself.
By using modules for static files, WebPack will throw an error at compile time because it would not be able to find the file.
Configuration
OK, we will not got into all the configuration details as this post is not, remember, a tutorial. I will just quickly explain the basic configuration file you can find on the official site (slightly modified).
First thing to know : WebPack configuration is a “simple” exported JS object, which must have the following attribute:
- entry
- output
We will explain two more attributes:
- module
- plugins
The configuration can of course become MUCH more complex but we will keep it simple for now.
Entry
entry defines the path to the first file WebPack will go through to start building its dependency graph. What you put inside the entry file is completely up to you, if you use Angular it will probably be used to bootstrap your Angular app.
Output
output defines where WebPack will write the compilation results ouput.path and output.filename are quite self-explanatory.
Module
module will hold all the rules to be used to load modules. It’s a list of rules, each rule defining which loader(s) to use when WebPack encounters a file with a name matching the test regex.
Plugins
plugins simply holds a list of plugins to be loaded during compilation. Nothing extraordinary here.
Multiple targets
One thing we love at Wassa about WebPack is its ability to handle multiple targets. Imagine you have a website with 10 variants. Will you have to compile all 10 manually?
No! By defining multiple configurations, WebPack will go through all of them by itself. Here is how it can be done:
Quite easy, no? You simply define a common config and then merge it with WebPackMerge with the real configurations. Then, instead of exporting a single configuration object, you export an array of them.
Defining a common config is not mandatory, but you will find it very useful on real project, especially if your variants share a lot of common code.
Where to go next?
Well it depends on how you like to learn:
- You like to learn by building things yourself from scratch: there are more than enough detailed tutorials about every concepts we’ve been through. Just pick the ones on you preferred website.
- You like to learn from existing projects, deep into advanced configuration files: You can try AngularStarter for Angular or MERN Starter for React.
Bottom line
We’ve only scratched the surface of what we can do with these modern tools. By now, I hope you’re convinced you should not develop your website the old way any more.
Do you want to know more about Wassa?
Wassa is an innovative digital agency expert in Indoor Location and Computer Vision. Whether you are looking to help your customers to find their way in a building, enhance the user experience of your products, collect data about your customers or analyze the human traffic and behavior in a location, our Innovation Lab brings scientific expertise to design the most adapted solution to your goals.
Find us on:
