The Mysterious Magic of Webpack

This week we finished up our e-commerce group projects on Wednesday and then started a short solo hackathon sprint.  I decided to explore a machine learning API called Clarifai to build an app that can recognize houses, faces, and houses that look like they have faces.  It’s not quite done yet, so more on that later.

I started this project using boilerplate code, and I realized that there was a lot of magic going on behind the scenes that I didn’t fully understand.  Generally, I knew what all of the different libraries were doing (Travis was doing something with testing before deploy, webpack was bundling code, etc.)   I’ve decided to investigate each of these libraries that I came across a bit more deeply, because I want to be able to provide more eloquent explanations of the tools I’m using to support my code.

First up: the mysterious Webpack.

After reading through the documentation, I’m using a metaphor of a vacation packing list to help me understand what webpack is doing with my JavaScript files.

  • Webpack is a static module bundler.  Modules are chunks of functionality.  Imagine that my packing list is on my computer and I’m using links to other, smaller packing lists that live elsewhere.  Let’s say that my Clothes packing list module includes a link to a Beachwear list, some items I’ve just typed in, and another link to a Hiking list.  The bundle created would include all of the other lists referenced, which are called dependencies.  Bundling allows the browser to load fewer chunks of information in order to display your app – instead of having to click through to see all of these packing lists, it just gets one master list to display.
  • The webpack entry point is like saying, ‘Hey application!  I’m gonna give you some bundled instructions, and to do them, you gotta start at the Clothes part of the list.”  Webpack defaults to using ./src/index.js as its entry point, just like I default to starting by packing clothes first.  Both of us are flexible if given other specific instructions.  Maybe you’d prefer to start packing your makeup first.
  • The webpack output is like saying, ‘Hey application!  I made you all these nice instructions on how to pack for your trip, and I’m putting them all together in a list named [something].bundle.js.  Webpack defaults to ./dist/main.js, but again, that can be changed in the config file.
  • Loaders allow webpack to interpret files it’s not typically familiar with.  Without loaders, webpack can handle JavaScript and JSON.  Loaders are like giving webpack the tools to read some of the packing list that’s in French without freaking out.  It can still include those files in its master packing list file.

There are other components of webpack that I haven’t touched on here, but going through the basics and comparing them to my imperfect-but-helpful packing example definitely makes me more clear about what webpack is doing with my application.  It’s essentially a streamlining tool that takes a whole mess of files that all reference each other and creates a simpler, fewer-layer to do list for the browser to implement.


Node.js 101

Node.js is a server environment.  It’s open source, free, runs on a bunch of different platforms, and uses JavaScript.  It works well because it’s asynchronous and event based!

Server Environment?

Think of a server as a server at a restaurant.  A customer asks for stuff, and they deliver the stuff.  In computing, it’s similar.  The server is still called a server, but the customer is called a client.  Instead of the stuff being a meatloaf dinner, the stuff is known a service – like sharing data or a resource.  The server could be a computer program or a device – it’s not always the giant room of big machines you may be envisioning.  Node.js allows you to write computer programs that can function as a server.


Here’s a metaphor.  You’re working the register at a sandwich shop.  You get an order for a PB&J, and there are 7 more people in line.  The synchronous strategy to handle this would be to ask the sandwich-maker to make the PB&J, wait while she makes it, give it to the hungry customer, then take the next order.  You keep going this way until everyone in line has a sandwich.  The asynchronous strategy would be to pass along the first order, then take another order.  Pass along the second order, then take another.  At some point, the first PB&J is done and you can deliver it, but you’re taking orders and passing them along to the sandwich-maker the entire time.

Node runs things asynchronously.  It gets a request (“i want PBJ.html!”) and lets the computer file system know about the request (“computer #1 wants PBJ.html, can you take care of that?”)  Then it’s available to wait for more request while the file system deals with the request – it needs to read it and respond with PBJ.html.  Other server frameworks, like PHP or ASP, don’t start listening for additional requests until PBJ.html has been delivered to the requester.  They’re the first strategy in the sandwich shop metaphor, while Node.js is the second.

So that’s the asynchronous part.  Sometimes it’s also referred to as “blocking” (synchronous, one sandwich at a time) vs. “non-blocking” (asynchronous, multiple orders open at once.)

Uhh…Event Based?

This is what makes Node.js fast.  In event-driven programming, the code only runs when certain events happen.  We’re not sending PBJ.html all the time, only when a request is made for it.  The events can be things like mouse clicks, pressing a key, or trying to access a certain port (more on that later.)  In any case,  the code isn’t running unless there’s a reason to run.

So What Does It Do?

Node can generate the content on a web page, it can manipulate files, it can play nicely with databases (add, delete, or modify info), or it can collect data from a form.  Cool!  Even cooler – it’s just a JavaScript file.  The file has instructions on what to do when certain events happen.

Arguably the best parts about Node.js is the Node Package Manager, or npm.   It’s the Amazon of web development (you can get anything!) and contains over 600,000 packages that do lots of cool things.  You can import these packages into your code and take advantage of their functionality.  There are packages to help test your code, to build databases, to allow for real-time communication, to send automated emails to users, and to make front-end development simpler.  There are also a number of built-in modules that you don’t have even have to install.

Node.js works best in conjunction with other frameworks from npm – using pure Node.js to built the back-end of a website isn’t great, but using it with Express, Sequelize, React, Redux…now we’re getting somewhere (more on all of those later.)

Next up – Express!