Differences between Node.js and the Browser
Tags: javascript, node, coding, programming
Published: 2021-08-08 05:40:30

{% user cleancodestudio %}
[![Twitter Follow](https://img.shields.io/twitter/follow/cleancodestudio.svg?style=social)](https://twitter.com/cleancodestudio) 

---

Yes, the browser and node.js both use the JavaScript software language - but the literal **Run Time Environments** are different.

Node.js, aka server side JavaScript has many similarities with client-side JavaScript. It also has a multitude of differences. 

Despite both using JavaScript as their software language, we can key in on some key differences that make the software development experience between the two **RADICALLY DIFFERENT**.

---

In today's post we're diving into the differences that separate Node.js (aka server-side JavaScript) from the browser (aka client-side JavaScript).

---

From the front-end developers vantage point, node.js comes across as a huge advantage. Node.js pulls on the power of familiarity and comfort, allowing developers to create full-stack applications using a software language in JavaScript that they are _already_ familiar with. This is huge.

By using the same language for both ends of the stack, you can deeply learn JavaScript and stick to becoming better and better at it without needing to bounce between languages and partition your learning resources into two or more languages on top of everything else software development requires you to learn.

> _"We're using JavaScript on both sides, so what changes?"_

What changes between node.js and browser side JavaScript is the **ecosystem**.


**For example, in the browser you're...**
- Interacting with the DOM (Document Object Module)
- Utilizing Web Platform APIs (EX: Cookies)

These examples, of course, don't actually exist within Node. The DOM is a representational layer - it's a document object module that has been largely inspired by the need to create a visual user interface layer for the web via the power of browsers. 

Node.js is server-side, we don't have a DOM nor do we need Cookies. Cookie's are largely implemented to track users or save user information - we're on the server side and have direct access to the database or storage resources and are using node.js to control the server itself that backs the website - this is instead of interacting with the browser that is used to communicate with our website server on the front-end.

In the browser, JavaScript won't have access to several clean APIs/modules that node has. 

**For example, in node you're...** 
- Able to interact and access the the file system (fs)

---

Another huge difference is that Node.js allows you to control the environment itself. Unless you're building an open source application that anyone is allowed to build on to and deploy anywhere, you know which version of Node.js you will be running your application on. 

This is compared to the browser, where the environment is based on the browser version. You don't have the luxury of defining the environment your visitors will use on the front-end. On the back-end you do and this is very convenient as a developer.

This means that you can write all the modern ES6-7-8-9 and so on JavaScript that your Node version supports.


JavaScript advances as fast as any other software language out there - browsers seemingly always a little bit behind the JS curve (at least some of the many browsers out there are so you have to wait a bit to use the most up to date JavaScript releases to support compatibility of your application across front-end browsers to support all of your visitor's and their experience with your software).

Since JavaScript moves so fast, but browsers can be a bit slow to upgrade, sometimes on the web you are stuck with using older JavaScript / ECMAScript releases.

On the browser side, you can do a bit of extra leg work to alleviate this "browsers are always a bit behind" issue by using Babel to transform your code to be ES5-compatible before shipping it to the browser. This requires you to install webpack, make sure your using the proper transpiler(s), and have the correct configuration set up to ultimately reduce your modern JavaScript into an older version of JavaScript so that all browsers can use it. 

On the node.js side, you don't have to do this. You won't need to do this.

Another difference is that Node.js uses the CommonJS module system, while in the browser we are starting to see the ES Modules standard being implemented.

In practice, this means you may need to use `require()` in Node while using `import` within the browser - but this looks to be changing/standardizing in the future. 

---

### What is Node.js

---

Node.js is a JS runtime based on chrome’s JavaScript engine called V8. In simple terms, the V8 JS engine from chrome was extracted and using it a new technology has been made to run standing alone. Of course, there's a lot more that goes into something like this.

As stated earlier this is no DOM, there is no User Interface, and there are runtime differences. 


---

### Installing Node.js vs. Browser JS

---

Like Python or PHP, you actually have to install Node.js for it to work properly on your machine. You can install node.js [here](https://nodejs.org/en/). 

Node.js is supported on all major Operating systems (Windows, Mac, Ubuntu, etc...). 

On the other side, you have the browser. What's it look like installing JavaScript into the Browser? The answer is it doesn't look like anything. The browser is responsible for being able to use, interpret, and run JavaScript - you don't install it, it comes with the browser. 


---

### Running Node.js vs Browser JavaScript

---
Once installed (like PHP, python, or any other server-side language) node.js can be run directly through the command line or terminal. 

You can call a JavaScript file by executing `node {file_path.js}` via your terminal or command line. This works just like you're running PHP or Python from the terminal. 

You can call the file using `node {file_path.js}` or simply type in `node` and enter into an interactive `REPL`.

```
cmd> node ./test.js 
cmd> "hello world"
cmd>
cmd> node
node> console.log('hello world')
node> "hello world"
node> .exit
cmd>
```

On the browser side this of kind of direct execution of JavaScript file and/or terminal REPL environment doesn't work. 

You have the browser console, accessible via the inspection tool - but this browser console doesn't actually let you call JavaScript files to be executed directly nor give you a REPL to directly interact with server/machine resources. 

You don't have the ability to directly call a JS file and execute it's functionality from the browser. You need to load the JS file into an HTML document and then allow the browser to pull the source code and ultimately run the JavaScript.


---

### System Access

---

The browser sandboxes JavaScript for your safety.

Node.js provides developers with full access to the system like any other native application.

This means node.js can read and write directly to and from the file system, has unrestricted access to the network, and can execute software installed on the machine. 

This also means that you must treat node.js with more caution - you're not sand boxed, you can do all the things. With great power comes great responsibility.


---

### Global vs. Window

---

In browser-side JS we have the `window` object. This is the upmost parent object in front-end/client-side JS. 

In server-side JS we have the `global` object. This is the most publicly/globally accessible object in node.js. 


---

### Similarities between Node.js and Browser side JS

---

- Both have a single thread for running JavaScript
- Both use the Event Queue (Lookup Event loop for further details) 
- Both are non-blocking
- Both have sync and asyn capabilities 
- Both use exceptions, flow, and scoping identically