Setup and Configuration

Depending on your use case, project setup can be pretty tricky. This part of development, often called “configuration”, can get very overwhelming quite quickly if you are just starting out. Frankly, it’s one of my least favorite parts of programming as it can feel frustrating when things aren’t going properly. So here’s a lesson on how project setup works in a web context.

Barebones Websites

The beauty of the internet is how simple it can be. If you just want to throw together some HTML, CSS, JS files in a GitHub repository, host it with GitHub pages, and call it a day: go right ahead. It’ll work just fine.

The only real standard you have to follow there is to make sure your homepage is called index.html as that’s what the internet will look for when accessing your website online. If your homepage is named something else, the server will have some issues sending the correct page to load in when visiting your site.

Other than that, you can pretty much do whatever you like with how that setup goes. If you want to just host a simple diary for you to share with others, no problem.

Node, npm, and Bundlers

Now we can get a bit of a more advanced step. You may see Javascript code with the syntax:

import * from 'three'

Or something like that. Then, you try and use that code in your barebones site and you get a whole bunch of errors.

The problem here is that the code you’re using is trying to import what’s called a “package”: a library or bundle of code that it currently can’t access because of how your project is setup.

Something to note is that you can still use the import syntax in Javascript without needing to import a package. It just allows you to modularize your code in to separate files to keep them smaller and neater to look through. You can tell when that’s happening when you see something like:

import utils from "./utils.js";

In this case, you’re importing from a specifc file and can do that no problem.

So why won’t the other one work? To answer that, we need to understand Node.js, npm, and bundlers.

What is Node.js?

Node.js is a way for Javascript to run on your computer. This may sound a bit strange but Javascript was created as a web language only meant to run in the browser. So you wouldn’t be able to just write up a Javascript file on your local computer and just run it.

As time went on, people found it useful to be able to actually run Javascript in such a way and thus came Node.

If you really want to get sweaty, there’s also other Javascript runtimes that are meant to replace Node directly. Namely, Deno (an upgrade to Node) and Bun. The other runtimes are newer so their support isn’t quite to the level of Node so I’ll stick to that for now. But keep an eye out, Javascript is always changing.

To use the technology we need to run larger scale websites, you’ll need Node. So be sure to install it from the link above.

npm

As the Node.js community grew, many devs started writing so called “packages”, bundles of code that you could bring into your project to do many different things. To help manage all of these packages, Node has what’s called Node Package Manager, or npm for short. It’s bundled together with Node.js when you install it.

Using npm is pretty straightforward, just open up your project folder in your terminal and input:

npm install three

And there you go, npm will automatically install the three.js package into your project directory. However, you won’t be able to use it just yet. You see, to properly use this package you will need the last and final step in our configuration journey: a bundler.

Understanding Bundlers

When you have a package like three.js, for example, it contains many thousands of lines to work. You can actually look in your node_modules folder to see all of the code for the three.js library to work. Now, to get all of that necessary code on your website, you need something to wrap together (or ‘bundle’, haha) all your code together with the package code.

And that’s where bundlers come in. Bundlers, like the name would suggest, takes all of the code you’ve written for a project and all of the packages you’re importing and packages it. This packaged site, often referred to as “built” or your “build”, has all the necessary code for it to run along with some optimizations of the CSS and Javascript to help with load times.

With a built site, you can actually have all of the code stored on the server directly. This is important to note as you sometimes have the option of getting packages via a Content Delivery Network or CDN. This effectively sends you the package via the internet but incurring additional load times since that is an asynchronous process. The advantage of the CDN option is you can stick to a more barebones implementation if you want to, since you don’t have to worry about a bundled package but it does mean the code that uses the package may have to be written differently.

There are many Javascript bundlers that you can use all with strengths and weaknesses.There’s rollup, parcel, webpack, and some others. Personally, for myself and beginners in general, I recommend Vite (pronounced “veet”) as a bundler. It’s very easy on the setup and can scale relatively well.

To get started with Vite, it’s just as easy as creating a project folder, navigating to the folder in your terminal, and inputting:

npm create vite@latest

Follow all the questions in the terminal and there you go! Now you can use npm modules to your hearts content. You can even experiment with frameworks like React or Svelte, and static site generators like Astro and Hugo.

Conclusion

Understanding how to setup your website projects properly is crucial to make full use of all the technology. A house can only be as strong as its foundation. Implementing good practice with proper bundlers and build steps is an important step as you build increasingly complicated websites.

Of course, always look at the documentation (or even just ask AI) for these tools to make sure you’re getting the full mileage out of them. There’s always something new to learn every day!