JavaScript - Part 1: Confusion January 22, 2025 on Kenneth Dodrill's blog

I will do my best to not rant in this blog post. (I whispered this to myself three times before writing this.)

The JavaScript ecosystem is perhaps one of the most confusing environments you might step into as a new programmer. If you are interested in some form of web development, you will be stepping into the JavaScript world at some point. I want to talk about what that was like for me, and then explore what that might be like for a new developer now.

JavaScript Past

Back when I started working on web development, JavaScript frameworks were only a few years old, and didn’t have the massive following that they now have. They were still fairly popular, but you didn’t see them being so highly recommended as you do today.

Like many, I started out with basic HTML and CSS, unknowingly making terrible websites. I knew JavaScript was another essential part of web development, but tooling was much more limited and various frameworks that were around weren’t as popular. I started learning JavaScript, got the basics down, then moved onto PHP. I do remember seeing jQuery and a few other things but not much else. Perhaps I wasn’t looking in the right places simply because I didn’t have a need for a JS framework.

JavaScript Present

Let’s imagine that you are a new developer. You know some basics, perhaps have taken a class or two. You are interested in making a video game, and want to build it for the web so your friends can play it easily. Let’s see what that entails.

You see many people telling you to go the JS route, so you do. You see many, many different opinions and ways to go about making a video game. You sometimes see people wary of JS and it’s tooling, but you decide that JS sounds easier than learning a compiled language (oh boy…).

You will likely start by just learning plain ole’ JavaScript. The things you do are simple at first, mostly event listeners to change buttons on the DOM. You start thinking, “man this should be easier”. But you press on, as making websites isn’t your complete focus.

You now want to put your skills to the test. You want to make a small video game, so you search for how to do that with JavaScript. You will likely be introduced to Phaser.js or something similar. You notice new things, like npm, yarn and pnpm. Nodejs? What’s that? “Seems like I can download other bits of code using one of these.”, you think. Kind of like an app store, but for code (bear with me).

How many things can go wrong here? Node could be out of date (likely). The package itself could have out-of-date dependencies with the node version you are using. But let’s say you get it installed.

Okay, you have the library. How do you use it? “It’s saying I can write import, but I’m getting library not found when I have my index.html open…”, you might think. Upon further searching, you understand that JavaScript files can be bundled together, and must be for npm packages to work correctly. You see a wide landscape of tooling. Gulp, Parcel, Rollup, and Webpack just to name the more popular ones.

How much research must you do at this point to figure out what’s best for your project?

You see people recommending build tools like Vite and Parcel over bundlers like Gulp and Rollup. You don’t know how these build tools work, and everything has it’s own configuration file. The build tools also have numerous options, and you aren’t sure exactly what template to pick. The code you have written is minimal, and you spend days just trying to figure out how to build it.

How many people would just give up or quit here? Let’s say you don’t.

You have your build tool in place, and things are working…somehow. You run a command and your game updates and all is well. You begin developing your small game. The code gets messy. You learn about JavaScript classes, and notice something new again; TypeScript. People recommend it online because it can make JavaScript code more structured. But how do you use it?

You installed TypeScript according to their docs, but you’re getting so many errors without even building the project. Even the packages that you’re using have errors. You learn more about types and that there are packages for them. You learn that if a package does not provide the types, you are left on your own and must figure out how to declare these so the bad red text goes away. You need to learn about the TypeScript configuration file in order to fix these.

At this point, your game library updates to the next version. The entire API changes and you must rewrite all your code. Just kidding?

Okay, you have the types installed and you’re feeling good. But now the build tool is messing up. It doesn’t understand TypeScript. You don’t understand the build tool. Ugh…things are getting complicated. Why is it that everytime I want to do something, I have to learn all these ideologies and configuration options?

Most people would give up by now.

You try and understand the build tool (you will likely fail to do so). You finally realize you could just reset the build tool with the typescript template, so you do that. Great, things are working! “Finally, I can write my code.”, you say. Except, you still don’t know all that much about TypeScript, and you find it hard to actually type things that are semi-complex. You take the time to learn more about it, and improve your code typings.

You have completed your project. Your game is a simple platformer where you move across the screen for one level. A thought comes to you. “How do I distribute this?”. The game library might have a way to build for the web, but perhaps not. You suppose it’s time to delve into the server realm.

JavaScript Present is so much longer than JavaScript Past, that I don’t think you really need to read it.

The main question I want to pose with this write-up is: how many steps do you need to take with a JavaScript project before you can write real code?

I think you understand that the answer to that is, “a lot”. We are focusing just on JavaScript for this, so I left out the server parts and deploying, so let’s just consider what we needed to do in order to try and make our project.

We had to learn:

At what point, as a new developer, would you just stop and try to do something else?

What we should have to learn:

The difference between these two is huge. With JS, you get a half-baked programming language and need to learn so much tooling JUST to make the damn thing work. If you want it to work well, that’s even more tooling and build configurations! (A small rant is fine, right?)

Next week we will discuss a short history of JavaScript (just the programming language). This post will shed some light on why this process is so confusing and frustrating.