DEV Community: Alimur Razi Rana

React Doesn't Need Node.js — Until It Does

Alimur Razi Rana — Mon, 08 Jun 2026 16:44:03 +0000

The Truth Nobody Tells You When You Start React

Most React tutorials for beginners start the same way

"First, install Node.js..."

And every beginner obeys without question. Most of them never challenge it. It's just accepted as part of the ritual.

But here's the thing — React doesn't actually need Node.js to work.

And understanding why that's true, and where it stops being true, will completely change how developers think about the entire React ecosystem — including Vite, Next.js, and npm itself.

Let's start with a proof.

Part 1: React With Zero Node.js

Create a plain .html file on your desktop. Paste this in:

<!DOCTYPE html>
<html>
  <head>
    <title>React, no Node.js</title>
  </head>
  <body>

    <div id="root"></div>

    <!-- React from CDN -->
    <script src="https://unpkg.com/react@18/umd/react.development.js"></script>
    <script src="https://unpkg.com/react-dom@18/umd/react-dom.development.js"></script>

    <!-- Babel to handle JSX in the browser -->
    <script src="https://unpkg.com/@babel/standalone/babel.min.js"></script>

    <script type="text/babel">
      function App() {
        const [count, setCount] = React.useState(0);
        return (
          <div>
            <h1>Hello from React!</h1>
            <p>Count: {count}</p>
            <button onClick={() => setCount(count + 1)}>Click me</button>
          </div>
        );
      }

      ReactDOM.createRoot(document.getElementById('root')).render(<App />);
    </script>

  </body>
</html>

Double-click the file. Open it in your browser.

It works. State works. JSX works. React works.

No Node.js. No npm. No terminal. No installation.

Just a file and a browser.

This isn't a trick or a hack. This is how React was used in its early days. React is, at its core, just a JavaScript library — the same as jQuery or Lodash. It can be loaded with a <script> tag like anything else.

So if that's true... why does every guide tell you to install Node.js?

Part 2: Where the CDN Approach Breaks Down

The CDN approach works perfectly for small experiments. But the moment the app grows beyond a single file, it hits its real limitations.

First, a common misconception worth clearing up:

Modern browsers actually support ES module imports natively:

<script type="module">
  import Header from './Header.js'
  import Footer from './Footer.js'
</script>

So imports themselves aren't the problem. The real limitations are deeper than that.

1. JSX Needs Compilation

Browsers understand JavaScript. They do not understand JSX:

// ❌ Browser has no idea what this is
function App() {
  return <h1>Hello</h1>
}

// ✅ Browser only understands this
function App() {
  return React.createElement("h1", null, "Hello")
}

Every JSX file needs to be compiled into plain JavaScript before a browser can run it. Native ES modules don't solve this — the browser still can't parse the JSX syntax itself.
This compilation step is handled by different tools depending on setup:

Babel — the original JSX compiler, still widely used in plain React projects
Vite — the popular choice for modern plain React projects
Next.js SWC — Next.js ships with its own built-in compiler

2. npm Packages Aren't ES Module Compatible Out of the Box

Most npm packages are written in CommonJS format — Node.js's own module system:

// CommonJS — how most npm packages are written
const axios = require('axios')
module.exports = something

This is completely different from ES modules:

// ES Modules — what browsers understand
import axios from 'axios'
export default something

Browsers cannot run CommonJS. A bundler is needed to convert and reconcile these formats before they reach the browser.

3. Dependency Management Becomes a Nightmare

Want to use axios? You'd manually find its CDN link. Then manually find CDN links for all of axios's dependencies. Then their dependencies. A single real-world package can pull in dozens of sub-dependencies — tracking all of them by hand is completely unworkable.

4. Performance Suffers With Many Module Files

Even if everything was ES module compatible, loading 200 separate JavaScript files means 200 separate network requests — each with its own overhead. A bundler combines them into one or a few optimized files, which loads dramatically faster.

Part 3: What Node.js Actually Is

Before understanding why Node.js solves these problems, you need to understand what Node.js actually is — because most developers use it for years without knowing this.

Operating system cannot run JavaScript.

OS can run Python (if installed). It can run compiled C++ binaries. But JavaScript? No. Most operating systems don't include a built-in JavaScript runtime that can execute JavaScript files directly.

Only two environments have been able to execute JavaScript:

1. The Browser
   → Chrome, Firefox, Safari all have a built-in JS engine
   → Chrome uses V8 (built by Google)
   → Firefox uses SpiderMonkey

2. Node.js
   → Takes Chrome's V8 engine
   → Strips out the browser parts (DOM, window, etc.)
   → Adds OS-level access (file system, network, processes)
   → Runs as a standalone program on your computer

That's literally all Node.js is. It's Chrome's JavaScript engine, liberated from the browser and given the ability to talk to your operating system.

Ryan Dahl, who created Node.js in 2009, had one core insight:

"JavaScript is already a great language. Why does it only run in browsers? What if it could run anywhere?"

So when you install Node.js, you're essentially installing a JavaScript interpreter directly onto your machine — the same engine that powers Chrome, just without the browser.

This is why npm packages need Node.js.

npm packages are JavaScript files. OS can store them just fine — it's great at storing files. But it cannot execute them. It has no JavaScript engine. Node.js provides that engine. Without it, those JavaScript files just sit there on your disk doing nothing.

Part 4: What npm Actually Solves

After Node.js, let's talk about npm — because it's far more than just a package downloader.

When you run npm install axios, npm doesn't just download axios. It:

1. Downloads axios
2. Reads axios's list of dependencies
3. Downloads those dependencies
4. Reads THEIR dependencies
5. Downloads those too
6. Resolves any version conflicts across the whole tree
7. Builds a complete, working dependency graph
8. Stores everything in node_modules

This process — called dependency resolution — is genuinely complex. Packages depend on other packages, which depend on other packages, which might conflict with each other's version requirements. npm handles all of this automatically.

Without npm, developers would need to do this by hand. For a real project with dozens of dependencies, each with their own sub-dependencies, that would be thousands of files to track manually. It would be completely unworkable.

And critically — npm itself is built on Node.js. It needs Node.js to run the resolution logic, download packages, execute install scripts, and manage the entire node_modules directory.

So the chain is clear:

You need npm
  → npm needs Node.js to run
    → Node.js provides the JS engine
      → JS engine executes npm's logic
        → npm manages your packages
          → packages can now be used in your app

Remove Node.js from this chain and the whole thing collapses.

Part 5: In Production, Node.js Disappears (For Plain React)

Here's something that surprises many developers.

When you run npm run build in a plain React + Vite project, Vite does all its work and produces a /dist folder:

/dist
  index.html
  assets/
    main.abc123.js     ← plain JavaScript, no JSX
    styles.abc123.css  ← plain CSS
    logo.abc123.png    ← optimized image

These are completely static files. Plain HTML, CSS, and JavaScript that any browser understands natively.

At this point, Node.js is completely out of the picture. You can take this /dist folder and host it on:

AWS S3
GitHub Pages
Netlify
Cloudflare Pages
A basic Apache server
Literally any file hosting service

No Node.js required. No server running. No ongoing processes. Just files being served.

Node.js was only needed during development — to run the JSX compiler, manage packages, and transform your code. Once the build is done, it has no role left.

Think of it like a printing press:

The printing press (Node.js + JSX compiler) prints the book (HTML/CSS/JS). Once printed, you don't need the press anymore. You just distribute the book. The reader (browser) never knew or cared about the press.

Part 6: Next.js Changes Everything

Everything we've covered so far describes plain React — a client-side application where the browser does all the rendering work.

Next.js fundamentally changes this model.

How Plain React Renders

User visits your site
        ↓
Server sends an almost empty HTML file:

<html>
  <body>
    <div id="root"></div>  ← nothing here
    <script src="bundle.js"></script>
  </body>
</html>
        ↓
Browser downloads bundle.js (can be 1-2MB)
        ↓
JavaScript runs, React builds the UI
        ↓
User finally sees content

The server does almost nothing. The browser does all the work. This means:

Users on slow connections wait a long time before seeing anything
Search engines see an empty page — bad for SEO
The user's device carries all the rendering cost

How Next.js Renders

User visits react site
        ↓
Request hits the Next.js SERVER (Node.js running live)
        ↓
Server executes React components
        ↓
Produces complete HTML with actual content:

<html>
  <body>
    <div id="root">
      <h1>Your Product Name</h1>   ← already here
      <p>Price: $49</p>            ← already here
      <button>Buy Now</button>     ← already here
    </div>
    <script src="bundle.js"></script>
  </body>
</html>
        ↓
Browser receives full HTML instantly
        ↓
User sees content immediately ✅
        ↓
React "hydrates" — attaches event listeners
        ↓
App becomes interactive ✅

The key difference: the server does the rendering work before the browser gets involved.

The Browser Has No Idea

The browser doesn't know — and doesn't care — whether it received HTML from a Next.js server, a plain React build, a WordPress site, or hand-written HTML. It just renders what it gets.

The difference is entirely in what the server sends. Next.js sends richer, fuller HTML. Plain React sends almost nothing and lets the browser figure it out.

Node.js Stays Alive in Production

This is the critical difference from plain React.

In a plain React app, Node.js is a development-only tool that disappears after the build.

In Next.js, Node.js runs permanently in production ( Next.js can also run project with little or no traditional node server, depending on how the application is configured ) — processing every user request, rendering components on the server, fetching data from databases, and generating HTML in real time.

Plain React:
Node.js role → Development only → Gone after build

Next.js:
Node.js role → Development AND Production → Always running

This is why Next.js cannot be deployed to a static file server (unless exported it as fully static). It needs a live Node.js process running 24/7 to handle incoming requests.

Found this useful? Share it with the developer who just ran npm install without knowing why.

Guide to Integrating Cypress and Cucumber with Angular

Alimur Razi Rana — Sun, 03 Mar 2024 08:57:39 +0000

In software engineering, despite developers' confidence in their code, comprehensive testing is indispensable for determining its efficacy. Developers and QA engineers must navigate through diverse testing phases to ascertain the comprehensive functionality of their applications. Two widely embraced methodologies for this purpose, are End-to-End (E2E) testing and Behavior-Driven Development (BDD) testing.

While Cypress and Cucumber are favored tools for such testing, integrating them poses challenges due to their differing configurations. If developers try to work with typescript, it creates one extra configuration layer. Cypress’s configuration changed a lot from their pre-10 version. So maybe this blog can help others when they need to work later.

Numerous tutorials and blogs cover the importance and procedures of E2E testing or BDD testing. However, This article focuses specifically on integration procedures for these testing methodologies.

Now it's time to make our hands dirty. Cypress and cucumber will be integrated into an angular project which by default maintains typescript. So ensure that you have already installed Node.js, npm, and ng package in your work environment.

Create a new angular project. ng new angular-cypress-cucumber
E2E testing needs your project running, so you need to run this angular project by npm start
Install @cypress/schematic package, this will help the angular project to run with Cypress. ng add @cypress/schematic

During installation, @cypress/schematic automatically includes necessary npm packages. Additionally, it generates a Cypress configuration file, "cypress.config.ts" and adjusts the "angular.json" configuration file accordingly. Furthermore, it establishes a dedicated "cypress" sub-directory, including sample test files to help the developer get started.

We will execute test cases on a user list page. On this basic listing page, we can envision below scenarios:

Initially, the page will display no users.
Following the click of the "Get Users" button, an API call will be triggered. If the API returns a valid response, the list will appear.
In case of an error returned by the API, the page will remain unchanged.

Now it is time for BDD
npm i @badeball/cypress-cucumber-preprocessor @cypress/webpack-preprocessor -d

Replace the whole cypress.config.ts with below configuration content

import { defineConfig } from 'cypress';
const webpack = require("@cypress/webpack-preprocessor");
const preprocessor = require("@badeball/cypress-cucumber-preprocessor");

async function setupNodeEvents(on, config) {
  await preprocessor.addCucumberPreprocessorPlugin(on, config);
  on(
    "file:preprocessor",
    webpack({
      webpackOptions: {
        resolve: {
          extensions: [".ts", ".js"],
        },
        module: {
          rules: [
            {
              test: /\.feature$/,
              use: [
                {
                  loader: "@badeball/cypress-cucumber-preprocessor/webpack",
                  options: config,
                },
              ],
            },
          ],
        },
      },
    })
  );
  return config;
}

export default defineConfig({
  e2e: {
    'baseUrl': 'http://localhost:4200', // this will be the default page for e2e testing
    specPattern: ["**/e2e/**/*.feature"], // all e2e test file’s name should be in this pattern
    setupNodeEvents
  },
  component: {
    devServer: {
      framework: 'angular',
      bundler: 'webpack',
    },
    specPattern: '**/*.cy.ts'
  }
})

The configuration file facilitates the preprocessing of Cucumber-generated test cases, preparing them for execution by Cypress. Furthermore, it adjusts the spec locations, allowing Cypress to discover .feature files for test execution. These feature files encapsulate BDD test cases written in the Gherkin syntax.

In the package.json file add this new property too

"cypress-cucumber-preprocessor": {
    "stepDefinitions": "cypress/e2e/bdd-cucumber/step-defination/*.step.cy.ts"
},

Within the existing cypress/e2e directory, create a new folder named bdd-cucumber and create another folder inside bdd-cucumber named features. Navigate to the cypress\e2e\bdd-cucumber\features directory and create a new file named user-page.feature. As previously noted, Cucumber or BDD operates with the Gherkin language. The features within this folder will adhere to its syntax.

user-page.feature

Feature: User List functionality
  Background: Prepare user page
    Given I am on the user page

  Scenario: Users appear in UI when API call succeeds
    When I click the "Get Users" button
    Then A api call will be requested with valid response
    And user list will be appear on successful api request

  Scenario: Users do not appear in UI when API call fails
    When I click the "Get Users" button to check failed response
    Then A api call will be requested with failed response
    And User list will not appear on failed api request

You can also install highlight-cucumber vscode extension to colorize those features.

In the bdd-cucumber folder create another folder named step-defination . Cypress test files will be added to this folder.

user-page.step.cy.ts

import {
  Given,
  When,
  Then,
} from '@badeball/cypress-cucumber-preprocessor';

const apiUrl = 'https://jsonplaceholder.typicode.com/users';

Given('I am on the user page', () => {
  cy.visit('/');
});

When('I click the "Get Users" button', () => {
  cy.intercept('GET', apiUrl).as('getUserList');
  cy.contains('Get User').click();
});

Then('A api call will be requested with valid response', () => {
  cy.wait('@getUserList').then((interception) => {
    expect(interception.request.url).to.eq(apiUrl);
    expect(interception.response?.statusCode).to.eq(200);
  });
});

Then('user list will be appear on successful api request', () => {
  cy.get('span.user-name').its('length').should('be.greaterThan', 0);
});

When('I click the "Get Users" button to check failed response', () => {
  cy.intercept('GET', apiUrl, { forceNetworkError: true }).as('getUserList');
  cy.contains('Get User').click();
});

Then('A api call will be requested with failed response', () => {
  cy.wait('@getUserList').then((interception) => {
    expect(interception.request.url).to.eq(apiUrl);
    expect(interception.error).to.exist;
    expect(interception.error?.message).to.eq('forceNetworkError called');
  });
});

Then('User list will not appear on failed api request', () => {
  cy.get('span.user-name').should('not.exist');
});

As we have already written our test cases, the next step is to implement a user list page. For simplicity, the Angular project comprises solely html and typescript code to retrieve user data via API.

app.component.ts

import { Component } from '@angular/core';
import { HttpClient } from '@angular/common/http';

type User = {
  name: string;
}

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.scss']
})

 export class AppComponent {
  title = 'angular-cypress-cucumber';
  url = "https://jsonplaceholder.typicode.com/users";
  users: User[] = [];
  constructor(private httpClient: HttpClient) {}

  getUsers() {
    this.httpClient.get<User[]>(this.url).subscribe(
      {
        next: (res) => {
          this.users = res;
        },
        error: (err: any) => {
          alert("Something went wrong!");
         },
        complete: () => { }
      }
    );
  }
}

app.component.html

<div>
  <button (click)="getUsers()">Get User</button>
  <ul>
    <li *ngFor="let user of users">
      <span class="user-name">{{user.name}}</span>
    </li>
  </ul>
</div>

Now navigate to the project's directory, and run the command npm run cypress:open. Before that, ensure that the angular project is running in http://localhost:4200 which is declared as the base URL in the cypress configuration.

Github Link