14 Aug 2022 ~ 6 min read

JavaScript and It's many Runtime Environments

On this article we will explore JavaScript's ubiquitous runtime environment(s).

Table of Contents


Ever heard of JavaScript? Yep that language. It has been praised multiple times by people, because you can run JavaScript mostly anywhere. On your computer, phone, cloud, arduino, smart devices anything can run JavaScript. But what most people will underestimate is the complexity of the JavaScript ecosystem because of this simple fact. In my own opinion, JavaScript was so simple and successful people started applying it to various projects. Business also looked at this as an advantage and started utilizing JavaScript in multiple projects. That way businesses can take the people who are already versed with working with JS and task them in projects that might have taken longer if it was another language.

So I want to highlight some things as if you’re just starting out or simply you’re still confused about the differences of the apis on different JavaScript Runtime Environments.

Before we go further, let’s us define the term Runtime Environment? what does it mean?



Runtime Environment describes a system, program or platform that exists both on the developers side and the target machine running the program, which acts as the execution target for your program. It differs from the definition of compiler because the compiler is generally involved on one stage, the compile-time where as the Runtime is there during each execution of your program.

Typically the runtime system will have some responsibility for setting up and managing the stack and heap, and may include features such as garbage collection, threads or other dynamic features built into the language. Wikipedia


The JavaScript Runtime Situation

So, why do I bring up JavaScript in this talk? Well JavaScript happens to be in a situation. Right now there are countless numbers of Runtime Environments for JavaScript it can becoming challenging. From the top of my head I can list a couple,

  1. NodeJS
  2. Deno
  3. Bun (Everyone is talking)
  4. Your Chrome Web Browser
  5. Other Web Browsers
  6. Mobile Runtime environments like React Native, Ionic and similar stuff

I bet if I look further into this rabbit hole I think I can find much more interesting solo dev projects too. But that’s my point, right now JavaScript is subject of the Runtime you’re on. The performance, features and limitations all lie on the runtime you’re on. I honestly don’t think this is a bad thing, but I do believe this creates a overly complex ecosystem for anyone joining.


Difference between Server side JS, Client side and their respective challenges

JavaScript on the server and on the client are completely different. When I started out I was confused when I got errors like window not available, and calling addEventListener of undefined (document). But if you think about it, the server doesn’t have a visible window? why would you want to look for window? Well here lies the issue. If you’re using a build-tool like nextjs for example, that also happens to have SSR support, you might find your self in a similar situation. Since nextjs is running both on the server and the browser, it gets confused when it encounters a situation window in a place where the server can execute.

Understanding situations like this helps you bring your development game up a level. Understanding the different browser environment also helps when you’re working on client side code too.

  • Understanding the differences between the chrome supported features, firefox exclusive ones or any other browser
  • What earlier browser versions can and can’t do
  • What build tool you are using, how the tool affects your code
  • The framework you’re working with, what characteristics does it have
  • How are you importing code? (Yes, you should consider this too)

So if you’re working with the web, you’re most likely going to be looking at the Web API Documentation, if you’re working with NodeJS you’re most likely working with the NodeJS API Documentation. Also applies to the other JS runtime environments.


JavaScript Tools

As a JavaScript developer, especially as a professional developer, you will most likely be using JavaScript paired with some sort of build tool. If you’re using TypeScript you’ve probably used something like webpack or tsc. As a result, aside from understanding how your code will react inside of the runtime you’re also tasked with understanding your build tools to work efficiently. For example, I love webpack, I’m getting used to it and right now I am convinced it is one of the most composable build tools out there. If you want to add support importing for scss, svg or images in your React app for example webpack has plugins that can help you with that. Knowing how to work with your preferred build tool is like having a swiss army inside your pocket.

But, you’ve guessed it, this also comes with it’s own circumstances. IMO one efficient habit of a javascript developer is understanding and being familiar with your build tools. That’s because build tools affect how your code get’s bundled, transpiled and exported for usage inside your runtime. If you are having a hard time working with your build tool, it will severely affect your work experience. So let me point out some things you’re build tool does for you

  1. Handle how you’re code it bundled and exported
  2. Determine what is globally available from your code
  3. Tree shaking, code-splitting and minifying
  4. Have plugins to have support for framework specific files, images, font, JSON files, SVGs, etc…
  5. Transforming your code from one file to JavaScript



I’ll try and go in further in depth in all these topics in separate articles because there is much to cover there too. But in conclusion I wanted to shed light on the kind of environments and tools you’ll be expected to work on as a JavaScript Developer. Covering these topics in advance gives you a heads up when talking with someone who is already a professional developer or just at work. But one thing we shouldn’t forget is, it’s not important weather you know 100% about these things. It’s just a matter of knowing where to look for information when tasked with a problem, being able to spot what you’re solving. Thank you for reading.



  1. Runtime system, wikipedia
  2. What is a Runtime, stackoverflow
  3. Introduction to JavaScript Runtime Environments, codecademy
  4. Differences between Node.js and the Browser , nodejs.dev
  5. Differences between Node and the Browser, flaviocopes

Headshot of Maxi Ferreira

Hi, I'm Zablon. I'm a software engineer, mostly working in the web space, based in Ethiopia. You can follow me on Twitter, see some of my work on GitHub, or read more about Qebero.dev on here.