Why frontend build tools are getting an overhaul

recently front-end tooling is getting a lot of attention it seems like everyone is working on something new snowpack was announced last year but just released a V - Evan you the creator of UJ s is working on a tool called vite even Jason Miller who wrote pre-act just tweeted a few days ago that he's working on a similar tool the one thing that all these tools have in common is that they are eliminating the bundling step from our local development environments so what does all that mean and why is it all happening now well to

answer that we need to understand why we started bundling our apps in the first place one reason we bundle our apps is for performance in high latency environments like the browser it's actually faster to send one large file over the network than it is to send many small files but there's another more important reason that we still bundle and that is because it enables us to write our application code using separate modules you see for most of its life the web has only had

one way to load script files and that's with a plain old script tag so if we wanted to load multiple JavaScript files well we just had to add multiple script tags to our pages and we actually did that for a while and it really sucked and the main reason it sucked is because there's nothing that explicitly connects one script tag to another that means that if we have one script that depends on another being loaded before it can run we now have to manually order those

script tags ourselves in a very specific order needless to say this gets really hard really fast but we still did it for a while so this is where explicit module systems come in modules let us write code in one javascript file that depends explicitly on code in another javascript file using keywords like import or require and once all the modules and our apps are using these keywords there's a whole layer of tooling that can generate that final module order for us

automatically and ensure that when our program runs every file that runs runs after every file it depends on has already been loaded this process is called dependence the resolution and it results in a module graph with all those dependency arrows pointing in the right way and that's what lets us as programmers just write code that depends on other modules or libraries without even giving it a second thought so resolving dependency graphs is one of

the most important functions that these app bundlers do tools like requirejs and browserify and more recently web pack now modules in front-end JavaScript have kind of an interesting history like I said earlier for most of its life the web has only had one way to load JavaScript files and that's with the script tag but when node came out it actually created its own module system called command J s command J s uses the keywords require and module dot exports

which you might be familiar with and because node runs on the server the way these keywords work is similar to how module loading works in any other server-side language like Ruby PHP or Python since the code that's being executed is on the same server as the other code it depends on when the app gets to a point where it needs to load another module the runtime can just stop what it's doing load the other module by reading it directly from disk and then pick right back up where it left off

this is called synchronous module loading and again it works because both the code that's running and the code in the dependencies live in the same physical location and reading from disk is super fast but the browser is different it's a very unique runtime environment and when we execute our application code we're actually running it on our users device now those users devices are very far away from the servers where our other code is being