Workshop: Webpack - Part 1: Theory
von Matthis Buschtöns (Kommentare: 0)
Due to the fact that webpack is a very complex subject I will split my posts in 3 parts which will be posted every 2 weeks.
Today we're starting with a little theory.
What is webpack?
Why do I need it?
Think about having a complex website. The easiest way to load your code is bundling it into one giant file - the main.js. It can easily reach a total size of 30mb. Now imagine the client is browsing with 3G-Network and is visiting your website. What happens? In order to navigate on your website, the client needs to download the whole main.js first. This will take ages.
According to a research from Doubleclick (owned by Google) published in September 2016: "Slow loading sites frustrate users and negatively impact publishers. In our new study, "The Need for Mobile Speed", we found that 53% of mobile site visits are abandoned if pages take longer than 3 seconds to load." (Source: http://www.hobo-web.co.uk/your-website-design-should-load-in4-seconds/)
So, as you can think, our clients will jump off our website faster than 30 speed, and will probably never come back again.
You'll need other strategies to keep the users on your website. The common way is to split the main.js and start to load dependencies on demand, but you still got most of the assets separated from your code which leads us to two of the frequently asked questions in web development: What else does this style affect? and Where else do we need it?
This is where webpack enters the court.
Okay, sounds handy. Tell me more.
For now, let's focus on two of the key-features: Code Splitting and Loaders
Code Splitting is a big thing in web-development. It is not efficient to put everything in one file, especially when some of the code isn't truly needed when you enter a website. Webpack solves this by splitting the code into on-demand chunks, which are loaded - guess what - only when you need them. It does that by distinguishing between two types of dependencies: synchronous and asynchronous.
If webpack's analyzing process runs over a synchronous imported module, the module will be packed directly into the current bundle-file. If the same module instead would be imported asynchronously, webpack would create a new, lazy-loaded chunk, and every dependency this module has will be packed into the same chunk. This goes on as long as an async dependency occurs, because then a new chunk will be formed with its own dependency-tree.
After all dependencies are analyzed and optimized, a file is emitted for each chunk.
css-loader: loads a stylesheet style-loader: applies the loaded stylesheet to the DOM file-loader: loads a binary file babel-loader: transpiles the given module
All of the loaders are installed via npm and can be used right in one of our modules
It's simply done by prepending the loader to the require path. The "!" separates the loader from the module and is used to chain loaders as well. The chaining is applied from right to left, so in this example, the css-loader is processed first. This is important to know when you, for example, use Sass, because the styles must be transformed to css first before you can apply them.
In conclusion: if you want to use a file that is not written in ECMAScript 5, you need to use a loader to make webpack handle it.
Webpack is an awesome tool, that can help you to solve many problems in web development. With Code Splitting you can implement route based chunking and decrease the loading time of the website. The Loaders help to organize the assets and modules, and with webpack's plugin system you can perform actions and custom functionality on your bundled modules or chunks. (I will talk about Plugins in one of the next posts.)
But it is only as powerful and helpful as you make it. Means that if you start to synchronously import all modules into one bundle and then use assets as modules as well, it makes it even more worse than the previous solution (the one with the giant main.js). So you have to keep an eye on your project structure and architecture.