For the Love of JavaScript! — Notes from a Python/Go Dev Going Back to the Browser

In a recent blog post, I talked about a little web app I built which process data in real-time from the Bluesky firehose using JavaScript’s native websocket client. Now, it’s been a while since I last worked on JavaScript front-end stuff (we’re talking literally years) and I was reminded of just how quirky the language is.

I recall having fond memories using to build silly web apps when I was studying my undergraduate degree in computer science. I remember one of my fellow students building an entire card game using nothing but HTML, JavaScript and some CSS and think how amazing this was.

In my day job, I primarily use Python and Go as my languages of choice as part of my work toolkit, so moving to JavaScript was an interesting experience to say the least. Drawing upon on my recent experience with JavaScript, I thought I would put together a blog post highlighting the good, the bad and the ugly side to the language for front-end browser-based apps.

Here are some observations I’ve put together describing my experience.

Messy, so messy

To me, JavaScript often feels like the wild west — you can write code in a million different ways, but that doesn’t mean you should. Unlike Python or Go where conventions and formatting are strongly adhered to, JavaScript is far more flexible… and sometimes chaotic.

Things only get messier when mixing HTML, CSS, and JavaScript together, leading to code that looks like spaghetti unless you’re careful with structure. That being said, frameworks like React or Vue can help enforce structure, but working with “vanilla” JS reminds you why they exist.

You’ll fall in love with Chrome’s Inspect Element

Debugging in JavaScript often starts and ends with the browser’s dev tools. If you’ve done any front-end web development stuff before, you will be very familiar with Chrome’s “Inspect” tool. Other browsers have great tools too (shoutout to Firefox Dev Edition!), but Chrome remains the go-to.

Real-time editing of HTML/CSS and even JavaScript right in the browser is incredibly powerful. You can use it to watch your variables, set breakpoints, and monitor network calls — all without leaving Chrome.

Console logs are your best friend… but it’s easy to overuse them and lose track of what’s happening. Next thing you know, they all get bunched together, and then you realise you have thousands (I’m not exaggerating) of the same warning in the console.

Variables have scope

This was news to me, and I feel that this was a recent development (again, I could be wrong). To me, this was a big transition coming from Go, where scoping is much more strict and predictable.

JavaScript’s var, let, and const each behave differently — and remembering the quirks takes time. For instance, accidentally hoisting variables or leaking them into global scope is a classic beginner (and returning dev!) pitfall. For this reason, shadowing and closure behaviour can be confusing at first, especially in nested functions.

Can’t const the const

The keyword const is misleading — it only makes the binding constant, not the value. I do not understand why it has to be like this.

You can modify objects and arrays declared with const, which feels… wrong at first. For instance, the code below works when logically it shouldn’t.

const arr = [1, 2, 3];
arr.push(4); // totally allowed!

If you can modify the contents of a variable, then it’s not a constant! This behaviour contrasts sharply with const in C/C++, where immutability is stricter. It forces you to read documentation carefully — assumptions can lead to hard-to-find bugs.

You can get away with almost anything

This was pretty well known before I got back into it, but JavaScript lets you write code that runs, even if it doesn’t make sense. undefined, null, NaN, false, 0, and '' are all false — but not in ways that always behave predictably. For instance, type coercion means "5" + 5 equals "55", while "5" - 5 equals 0. 🤯

There’s a certain charm in how forgiving it is… until it isn’t. Why can we just not stick to types?

Working with a strictly typed language like Go or C, JavaScript is a walk in the park

JavaScript can feel liberating after working in verbose, statically typed languages (especially compare to languages like Go). Embracing JavaScript’s dynamic nature mean no more writing out rigid type declarations — just write some code and run.

But it’s also easy to shoot yourself in the foot without strong typing — which, I guess, is why tools like TypeScript are so popular. This is not a language I’ve looked in great detail.

So many packages and libraries

Have you ever taken the time to appreciate just how vast the JavaScript ecosystem is? The npm ecosystem is both a blessing and a curse.

Need to debounce a function? Format a date? Parse markdown? Yep, there’s (probably) a package for that. But it’s also overwhelming — and not all packages are maintained or trustworthy. And, yes, I know the same can be said for Python and pip.

But still, the sheer number of choices can lead to analysis paralysis, or worse, dependency hell. That said, it’s also what makes prototyping in JS so fast and fun.

Conclusions

As I draw to conclusion, here are some final thoughts. JavaScript gets a lot of slack, and I can understand why, but the quirkiness makes it all the more fun to play with and learn. There’s something oddly endearing about its quirks, JavaScript truly is a fun and versatile language to work with.

With all its messiness, JavaScript remains one of the most accessible, expressive, and flexible languages around. Whether you’re building serious apps or silly experiments (like my Bluesky apps), there’s a lot of joy to be found in just tinkering. Coming back to JS made me appreciate the lightweight feel, but I definitely missed the safety net.