DEV Community: Neel-Vekariya

If You Think React Is Free to Use, You Are Wrong.

Neel-Vekariya — Wed, 04 Nov 2026 05:47:09 +0000

React Is Not Free. Let’s Clarify This.

When you use an abstraction over a complex task, it gives you convenience by moving complexity into a framework, which you learn through another mental model present in your mind.

This adds more concepts, like React mental model complexity, component/state complexity, and reconciliation/runtime complexity.

That’s why I say it: you move complexity into the mental model that is present in the mind.

Another trade-off is control.

You get maximum control when you work directly with DOM manipulation.

But in the case of React, control is given to React.

React manages all the operations, like insertion and deletion of DOM elements and updates to the DOM.

Now, you don’t have direct access to the DOM.

You exchange control for complexity.

If you lose control, then you lose ownership.

Now React becomes the owner of the rendering process.

It becomes a middleman between your application and the browser.

It creates the necessity to understand React’s rules.

That’s it.

Ummmm, really, don’t.

Another big trade-off is runtime overhead and memory.

Assume that React has some work pending to do.

Now, the question is: does React directly hand over this work to the browser?

Really, don’t.

It creates a virtual DOM, then uses reconciliation and updates the Fiber tree before reflecting the updates.

This can make the application slower due to runtime overhead.

Maintaining the React Fiber tree requires additional memory, which is not required in a vanilla JavaScript application due to its limited framework state.

In the case of React, it is not free to use.

You pay the cost through these trade-offs and mental models.

What Problem Does React Solve Better Than Other Alternatives

Neel-Vekariya — Mon, 02 Nov 2026 04:34:30 +0000

Did you ever think about what problem React actually tries to solve?

So, the problem starts when you need to build a complex layout, and this layout depends on multiple states.

Now, the problem starts. How do you keep this complex UI synchronized with changing application state without manually managing every DOM change?

Before React, you needed to figure out which DOM elements were affected by a particular state change. Then, you needed to find those elements and modify them manually. You had to make sure every affected element was updated properly so the UI remained consistent with the application state.

But React took a somewhat different approach. It changes the programming model, where the current state describes what the UI should look like. Now, React determines what needs to change and updates the host environment.

1. Direct DOM Manipulation

When the UI gets complicated and you need to change the UI in multiple places, the task becomes complicated because the developer has to manually maintain the relationships between application state and the UI.

React manages DOM manipulation itself.

2. Declarative UI

In other frameworks or libraries, you need to explicitly say:

Do this.
Find that element.
Change its text.
Add the class.
Remove this button.
Show that button.
Hide that element.

This is imperative UI.

But React uses Declarative UI, where React takes responsibility for keeping the actual UI consistent with that declaration. This becomes the responsibility of the framework/runtime instead of the application's responsibility.

3. Change Propagation Problem

Change propagation means how you propagate this change throughout the UI.

If you do this task manually, then there might be some chances of forgetting the changes in the UI.

To eliminate this, React establishes a model where changes in state automatically re-render the relevant component tree and reconcile the result.

These are the changes that React solves perfectly, but other frameworks or libraries miss out on.

What Abstraction Does React Introduce?

Neel-Vekariya — Sat, 31 Oct 2026 05:08:46 +0000

JavaScript could already update the DOM.

So why did we need React?

In my previous post, we discussed the history of Web UI and how it evolved from HTML to React.

But there are many misconceptions about React.

One of them is that React removes DOM manipulation.

That’s not the proper way to understand it.

Instead, React abstracts DOM manipulation.

So, what is abstraction?

The bigger picture of React's abstraction is where you describe UI declaratively as a function of application state, organize UI into components, and then let React handle the synchronization between that description and the React rendering environment.

That is about the overall abstraction, which abstracts many underlying tasks.

Let's understand that.

Abstractions

1. DOM Mutations

DOM mutations mean abstracting low-level concepts and thinking about that abstraction.

Before React, you need to think about the DOM nodes, properties, DOM methods, and DOM events.

React abstracts that and introduces concepts like Components, Props, UI, and State.

This is similar to how higher-level programming languages abstract machine instructions.

2. Declarative UI

Declarative means you describe what the result should be.

You are describing the desired UI.

You don't need to explicitly describe:

Create dashboard DOM.
Insert dashboard.
Update Button.

Instead, React tracks your declaration and manages the transition between them.

This separates "What" from "How".

3. Component and State Abstraction

Before React, you needed to create reusable JavaScript functions intentionally.

But React makes UI itself composable.

This introduces the component abstraction.

State abstraction abstracts the tracking of what changed, which element depends on it, and what should I update.

4. Abstraction as a Contract

In React, you describe the UI corresponding to the current state.

Now React is responsible for reconciling that description with the rendered UI.

Now the developer's responsibility becomes:

What should the UI look like?
What state does it depend on?
How are components composed?

And React manages the responsibility for rendered work, reconciliation, scheduling, commit, and host environment updates.

What Existed Before React?

Neel-Vekariya — Wed, 28 Oct 2026 06:06:09 +0000

If you are interested in reading about the evolution of technology,
then you might know that every technology has its own evolution phases,
where the technology evolves more and more over time.

In the recent post, we discussed how the ecosystem evolved from a
low-level HTTP Node.js server to Express.

Now this is the right time to discuss how web UI evolved from HTML to React.

1. The Early Web: HTML Documents

In the early web, websites were primarily documents.

The page was mostly static.

If you wanted another page, the browser would request another HTML document.

2. JavaScript and the DOM

Then JavaScript entered the picture.

JavaScript gave us the ability to execute code.

Now the browser wasn't just displaying static web pages or documents; it was also executing behavior, which led to interactive web pages.

At this time, the browser also exposed a programming interface called the DOM (Document Object Model).

The use of the DOM and JavaScript enabled changing elements without requesting a completely new HTML document.

At this time, if you wanted to change elements when a user interacted with a web page, the flow was like this:

A user action executes JavaScript, which finds and modifies the DOM elements, and the page becomes interactive.

This worked perfectly for websites.

3. The Rise of Web Applications

But the web evolved from websites to applications, such as Gmail, Facebook, Google Maps, and online shopping.

Those applications have lots of state, and the application needs to behave according to that state.

Maintaining the UI according to the state using DOM manipulation became complicated.

4. jQuery and Easier DOM Manipulation

To overcome this problem, developers started building JavaScript libraries to make browser programming easier.

One of them was jQuery.

jQuery simplified browser operations, which made working with the DOM easier.

It provided tools for DOM selection, DOM manipulation, events, AJAX, and animations.

Now you only needed to think about the elements that needed to change, and jQuery made selecting and modifying elements easier.

5. The Era of JavaScript Frameworks

As applications became even more complex, developers wanted something more structured.

This led to the development of JavaScript frameworks and libraries around Model, View, and Controller.

The era of MVP, MVVM, and MV* began.

From this era, one important framework became influential: AngularJS, developed by Google.

6. AngularJS and Two-Way Data Binding

It introduced concepts like controllers, scopes, services, dependency injection, directives, templates, and two-way binding.

It solved many problems, but large applications could still become difficult to reason about because of data flow and complex relationships between components and state.

In large applications, data flows in multiple directions.

7. React and a Different Approach

At the peak of AngularJS, React came into the picture, taking a somewhat different approach to maintaining multi-directional data flow and complex relationships between components and state.

React's philosophy was different:

The UI should be a function of state.

Instead of thinking, change this element, change that element, update the template, and synchronize this model, you only need to think about what the UI should look like given this state.

8. The Era of Interactive Web Applications

This helped create the era of highly interactive web applications.

Now web applications became more like desktop applications.

9. Client-Side Rendering and Server-Side Rendering

One important thing is that this evolution was not only about client-side rendering; server-side rendering also evolved.

But we are only discussing the evolution of client-side rendering.

Why React exist?

Neel-Vekariya — Mon, 26 Oct 2026 10:49:12 +0000

Why React exist?

When I started learning frontend then I picked React for frontend. Why, because everyone talks about React. To get into FOMO, I started learning React, and I also learned.

I learned useState. I learned useEffect. I built stuff. It worked. And I think it's done.

But somehow, one question exposed my real situation of what I learned. And the question is: why does it exist? I never thought about that type of question. I think it works, I learned frontend.

Then I started to look at why things exist, why someone built this, what problem motivated them to build that, like a lens. Now I got my lens. Can you have one? Ask yourself: can I answer why React exists?

Don't worry if you don't answer. We will discuss why React exists and which problem it tries to solve.

So the main problem is to build and maintain complex, interactive user interfaces. Direct DOM manipulation becomes difficult as an application complexity grows.

The problem is to build a button. The problem is how do I keep a large, constantly changing user interface with application state consistent without manually managing every DOM update?

Using vanilla JavaScript, you can also build complex applications, so complexity itself is not the problem React was trying to solve.

The difference is that, with vanilla JavaScript, you manually tell the browser what to do. You constantly say, find that card, change it, find button, change it. You are responsible for knowing which DOM elements need to change. For a huge application, this becomes difficult and complex. Means the problem is in complexity and maintainability.

Now React comes to the picture. React is based on giving the new state what the UI should look like.

React introduces Componentization. Use of componentization, you break the interface into components instead of one enormous file. Which gives ability of reuse that component. You need to build a component once and use multiple times in the application, which also gives you predictable UI, where the component should have one UI which shows different-different data, which makes UI more predictable.

React works like a layer of abstraction over DOM nodes, events, element injection, element removal, and many more. With the use of layer, you work with components, props, state, and events, not with things in the layer below.

Virtual DOM

Neel-Vekariya — Thu, 22 Oct 2026 05:16:20 +0000

In the previous post, we discussed what React really is, the meaning of declarative UI, and its tree-like structure. Now, let’s continue that discussion further.

If you have worked with React, you have probably heard about state, how and why it is used. Don’t worry if you don’t know about it yet.

What is State in React?

State is information that can change over time and affects what a component renders.

Now, assume React renders the component and the user clicks a button. The information about whether the button is clicked or not is stored in this state.

Whenever the user clicks the button, the information in the state changes from its default value to clicked.

The state changes, so React schedules an update. The component is evaluated again. React compares the previous UI and the new UI to determine what needs to change in the actual DOM.

Previous UI vs. New UI

Here, you can see the two UIs: the previous UI and the new UI. So, what is the difference between them?

Understanding the Virtual DOM

To understand the difference, we need to discuss the Virtual DOM.

Assume you already have a UI. Now, you perform some action, and the UI changes.

To track the changes in the UI, React uses an in-memory representation of the updated UI.

To perform reconciliation, React compares both UIs: the previous UI that needs to be updated and the new UI created by React. This is commonly described as the Virtual DOM.

Note: I know this is an oversimplification, but to understand the idea of the Virtual DOM, this mental model is useful.

Using the Virtual DOM, React can determine the required changes instead of rebuilding the entire browser DOM every time the state updates.

The new UI we talked about is the Virtual DOM. Using reconciliation and the Virtual DOM, React updates the specific changes.

What is Reconciliation?

Now, I have used the word reconciliation many times. So, what is reconciliation?

Reconciliation is the process React uses to determine how the current rendered tree, which is the host tree, should change when new data or state produces a new tree, which is commonly referred to as the Virtual DOM.

In a web application, the host environment is generally the browser DOM. React is responsible for the UI programming model and reconciliation.

React, Full overview

Neel-Vekariya — Tue, 20 Oct 2026 09:31:00 +0000

Recently, we discussed a lot about Express, like what it really is, what
abstraction it gives, what cost we pay, and many other things.

Those perspectives give us a mental model to understand the technology in
depth, rather than just from a working level. I think we need to continue
that discussion further on other technologies.

So, I decided to continue those discussions with React.js.

Firstly, to understand those discussions deeply, you need some knowledge
about React. And I assume that you have that exposure.

What Is React Actually?

Firstly, technical definition:

React is a declarative, component-based JavaScript library for constructing
user interfaces from a tree of reusable components, where UI output is
derived from application state and React efficiently updates the DOM when
that state changes.

The first technical word you see is declarative, and surely you are confused
by that word. So, what is declarative?

To describe UI, there are two broad ways, which are imperative and
declarative.

1) Imperative

In imperative, you tell the computer how to do something. You explicitly
describe the operation and UI.

2) Declarative

This is amazing. In declarative, you describe what you want. You don’t
manually say, find that button, change this text, add class. Instead, you
describe what you want.

React is based on declarative. You describe what UI you want, React
determines what changes are necessary.

Now, what is a tree of reusable components?

In React, we have a hierarchical structure to render individual components.
The top-level component, called the root component, renders first, which
then renders its child components. This becomes a structure like a tree,
where data flows in one direction, from the root, meaning the parent, to the
child.

React provides mechanisms for building UI with components, props, state,
hooks, reconciliation, and event handling. The reconciliation is
interesting, which we talk later on in a specific post.

You listen about component and also use this component, but what is
component actually?

The component is commonly a JavaScript function that accepts inputs and
returns a description of the UI. With the use of multiple components, we
construct the User Interface.

The Cost of Using Express

Neel-Vekariya — Mon, 19 Oct 2026 04:47:38 +0000

The Cost of Using Express

If you started thinking about the engineering perspective, then you might know that every technology comes with cost.
Every technology gives you certain advantages, but it also introduces the trade-offs.

The real engineering skill is not simply choosing technology because it solves a problem.
It is understanding what you gain, what you give up, and when those trade-offs are worth it.

Express is no different.

It gives a higher-level abstraction over Node.js’s http module.
It makes routing, middleware, request processing, and composition much easier to work with.

But it also comes with cost.

To understand those trade-offs gives better thinking of why I use this technology in a project,
instead of how to use the technology.

The Cost You Pay With:

*) Control

Express sits between Node.js HTTP primitives and the application.
When you use Express, you are no longer working directly with the raw HTTP server model.
Express decides how that request-processing abstraction works,
and your application has to work within that model.

*) Hidden Work

Express implements some work behind the scenes.
Something is happening that you didn’t explicitly write.
The general property of the abstraction is that the less code you write,
the more framework behavior you need to understand.

*) Performance Cost

Express adds a layer of processing on top of Node’s primitives.
That means additional function calls, middleware traversal, and routing logic.
This is additional CPU work and latency compared to doing everything directly at a lower level.
It doesn’t drop that much performance compared to database, external APIs, and networking latency.

*) Complexity

The behavior of the request depends on the middleware chain.
Middleware can modify req, res, and also terminate the request call.
Now, to understand why this behaves this way can require tracing in the middleware chain.

*) Mental Complexity

Now you use Express, so you have to understand Express itself.
Once you choose Express, you need knowledge of middleware, routing, router, middleware,
request/response APIs, framework conventions, and version-specific behavior.
To use Express, you don’t eliminate complexity;
you move some complexity into the framework and its mental model.

*) Dependency Cost

Express becomes part of your application dependency graph.
Now you need to care about:

Express versions
Compatibility
Security updates
Migration between major updates

The abstraction works beautifully until a problem crosses the abstraction boundary.

What Does Express.js Abstract Away?

Neel-Vekariya — Wed, 14 Oct 2026 06:00:12 +0000

In the past, we talked about the general deeper understanding about what Express.js actually is, what problem it tries to solve, and what existed before Express. But another question is: what abstraction does it introduce?

If you've read my previous posts, you know that Express.js provides an abstraction over Node.js's HTTP module. In this post, we'll go deeper and explore what those abstractions actually are.

The most common central abstraction, the low-level processing of an HTTP request into a programmable pipeline of middleware and routes. This is a broad perspective of the Express.js abstraction. But this broad abstraction has many small abstractions. And those abstractions are:

*) Route Matching

Express abstracts manually route matching. It takes responsibility for matching routes for incoming requests. It abstracts that task and gives a simple way to use routes without the complexity of matching routes.

*) Route Parameters:

The next abstraction Express.js provides is parsing request parameters for us, so we don't have to handle them manually. It hides the mechanics of matching and extracting that value. Without it, you might have to manually parse the parameters.

*) Request Processing:

Express abstracts raw HTTP request information into data that is easily accessible to the application. The task of processing raw information of the request is abstracted by Express.

*) Middleware:

Express allows you to represent cross-cutting request processing as reasonable functions. Instead of manually deciding everything inside one HTTP callback, it gives functionality to compose the application out of functions that process the request sequentially.

*) Composition Model:

Express gives you compose behaviour where each piece has a focused responsibility. That’s much more scalable than putting everything into one request.

Express makes application development easier by abstracting some of the complexity, but it does not abstract away everything involved in building an application.

It doesn’t decide:

How my business should work
How I should store users
Which database I should use
How an order should be calculated
How payment should work

What Existed Before Express?

Neel-Vekariya — Sat, 10 Oct 2026 04:04:14 +0000

I already made a post about what Express really is and which problem Express tries to solve. But do you think about what existed before Express? How did developers build servers in the JavaScript ecosystem?

I had this question, and I found out a really interesting thing.

In the JavaScript ecosystem, Node.js was released in 2009, and its standard library already allowed developers to create HTTP servers directly.

Think about the complexity and repetition of code for building servers using the Node.js HTTP module. I saw code for handling different routes, where you handle different types of requests and routes using the if-else block.

Like this:

const server = http.createServer((req, res) => {

  if (req.method === "GET" && req.url === "/") {

    res.writeHead(200, { "Content-Type": "text/plain" });

    res.end("Home page");

  } else if (req.method === "GET" && req.url === "/about") {

    res.writeHead(200, { "Content-Type": "text/plain" });

    res.end("About page");

  } else {

    res.writeHead(404, { "Content-Type": "text/plain" });

    res.end("404 - Page not found");
  }
});

You repetitively write which data type you send and what the actual data (response) will be sent by the server. And this process becomes cumbersome as the application grows.

Developers therefore built higher-level abstractions around Node.js HTTP capabilities, which are frameworks and libraries. Express is one of those abstractions and became particularly influential.

Node.js brought JavaScript to the server, and Express provided a popular web framework abstraction for that environment.

The Engineering Problem Express Tries to Solve

Neel-Vekariya — Wed, 07 Oct 2026 14:36:07 +0000

The Engineering Problem Express Tries to Solve

If you don’t know, we can also build an HTTP application using Node.js low-level HTTP APIs. The application is working properly and able to handle requests and generate responses. So, why do we need to build Express?

The reason behind that is that building an HTTP application using Node.js low-level HTTP APIs becomes repetitive and cumbersome (difficult) as the application grows. The repetition of writing code for request parsing, routing, middleware, and handling the logic becomes more complex.

The Problem Express Solves:

How can we build an HTTP application on top of Node.js without repeatedly implementing the same request parsing, routing, middleware, and response handling logic ourselves?

Express introduces reusable abstractions for those common problems. In application building, the repeated infrastructure, such as routing, middleware composition, request parsing, response handling, and error handling, is directly provided by those reusable abstractions.

If you are confused by reusable abstractions, don’t worry. It simply means a ready-made piece of code or concept that solves a common problem.

This reusable abstraction gives us the ability to write actual business logic instead of writing complex application infrastructure for every project.

This is the actual problem that Express tries to solve. And it exists to provide a higher-level abstraction over Node.js low-level HTTP APIs.

What is Express, really?

Neel-Vekariya — Sun, 04 Oct 2026 06:46:33 +0000

What is Express, really?

In my last blog, I shared some of my personal experience and the thinking that led me from “How?” to “Why?”

So, I’m going to assume you already know the “how” of Express.

Now, let’s start understanding the “why” behind Express.

First, let’s understand what Express really is.

As per the technical definition:

Express.js is a minimal, unopinionated web application framework for Node.js that provides abstractions and APIs for handling HTTP requests, generating HTTP responses, routing, middleware composition, and building web/API applications.

🤦‍♂️🤦‍♂️ Very technical, right?

Don’t worry, I’ll explain it to you.

In simple terms, Express.js is a web application framework that provides the bare minimum (small set of core abstractions) tools to build your applications while giving you maximum freedom in how you structure your application.

It does not force you to follow a specific file structure.

It provides tools for handling requests, responses, routing, and other application tasks instead of making you manually handle those lower-level tasks.

Now you get the idea of what Express is.

But another confusing phrase came up:

“Lower-level application tasks.”

What does that actually mean?

To understand this, you first need to understand what problem Express is solving.

And that is another big topic, which we’ll discuss in the next post.

For now, assume there are some repeated tasks involved in building and setting up HTTP APIs.

Express handles many of these tasks under the hood.

This provides a layer of abstraction over those difficult tasks and gives developers a convenient way to work with:

1. Routing:

Deciding which code should handle a particular URL and HTTP method.

2. Middleware:

Creating a pipeline of functions that process requests and responses.

3. Request Handling:

Handling parameters, headers, and request bodies.

4. Response Handling:

Sending JSON, HTML, status codes, and other data.

5. Error Handling:

Handling errors consistently within the application.

But this brings us to another question:

What problem was Express actually trying to solve?

That’s what we’ll understand in the next blog.