DEV Community: Hayk Sargsyan

Why JavaScript Engineers are Secretly C# Masters

Hayk Sargsyan — Mon, 09 Mar 2026 16:45:25 +0000

For a professional JavaScript developer, moving to TypeScript often feels like "cleaning up the room." But for those who look closer, TypeScript isn't just JavaScript with types; it is the spiritual successor to C# for the web. Understanding this connection is the shortcut to mastering backend architecture and high-scale systems.

The Hejlsberg Lineage

The most critical secret is that both languages share a father: Anders Hejlsberg.

Hejlsberg led the design of C# at Microsoft before creating TypeScript in 2012.
Because of this, the "feel" of the languages, how they handle generics, interfaces, and asynchronous patterns - is nearly identical.
Learning TypeScript is, in many ways, an onboarding process for modern C# and .NET.

Write Once, Understand Both

If you can read complex TypeScript, you can already read 80% of modern C#.

Async/Await: Both languages use the exact same keywords and mental model for non-blocking I/O.
Access Modifiers: Keywords like public, private, and protected function similarly in both environments to enforce encapsulation.
Arrow Functions vs. Lambdas: What you call an "arrow function" in JS, a C# dev calls a "lambda expression" using the same => token.
Generics: The syntax for reusable components - List in C# and Array in TS - is virtually interchangeable.

Photo by MJH SHIKDER on Unsplash

The "Erasure" vs. "Reified" Distinction

The realization for engineers is understanding where they diverge: The Runtime.

TypeScript uses Type Erasure. Types exist only at compile-time to help the developer, once it hits the browser/server, it’s just "naked" JavaScript.
C# uses Reified Types. Type metadata stays with the code at runtime, allowing for powerful features like Reflection (inspecting code at runtime) that TypeScript cannot do natively.

The Full-Stack Bridge

Engineers use this connection to bridge the gap between frontend and backend.

Frameworks like Nest.js (Node.js) are explicitly modeled after ASP.NET Core (C#). If you understand one’s Dependency Injection or Controller pattern, you understand the other.
The languages are actively borrowing from each other. C# recently added Pattern Matching, while JavaScript/TypeScript adopted Decorators, a staple of C# attributes for years.

The "lift" from TypeScript to C# is often smaller and more productive than moving to Go or Rust because the mental model remains consistent.

The "Awaitable" Pattern

Both languages implement asynchronous programming using a virtually identical mental and syntactic model:

A JavaScript Promise and a C# Task are ideologically equivalent, representing an ongoing operation that will complete in the future.
Both use the async and await keywords to flatten asynchronous callbacks into a synchronous-looking flow.

Photo by Michal Pokorný on Unsplash

Conclusion

The symmetry between C# and TypeScript represents a calculated evolution of industrial-scale engineering. By sharing a primary architect, both languages have aligned on a specific "developer ergonomics" that prioritizes predictability, maintainability, and architectural discipline.

React Concurrent Model is unstoppable

Hayk Sargsyan — Thu, 22 Jan 2026 11:42:14 +0000

React Lanes: The Internal Engine Powering Modern Concurrent Rendering

Hayk Sargsyan ・ Jan 22

#react #reactnative #javascript #frontend

React Lanes: The Internal Engine Powering Modern Concurrent Rendering

Hayk Sargsyan — Thu, 22 Jan 2026 09:32:39 +0000

We use React every day, but we haven’t been paying enough attention to one of the most important aspects of it: how React has evolved since v16, how the new concurrent model works.

Photo by Tim Mossholder on Unsplash

Wow.. React is unstoppable!

The Great Rewrite of v16

Before we talk about Lanes, we must acknowledge the foundation. In 2017, React v16 introduced Fiber, a complete rewrite of the reconciliation engine. Before Fiber, React used a "stack-based" reconciler that processed updates synchronously - once a render started, it couldn't be stopped until it finished.
Fiber changed the game by introducing a linked-list tree structure that allowed React to break rendering into small units of work. This was the birth of Incremental Rendering: the ability to pause work, yield to the browser for a high-priority task (like a user click), and then resume.

From Expiration Times to Lanes

Initially, Fiber used a linear "Expiration Time" model to prioritize work: the longer an update waited, the higher its priority. However, this model struggled with "IO-bound" updates where different tasks needed to be handled in separate "streams" without blocking each other.
In 2026, we don't just use Fiber; we use React Lanes. This is a 31-bit bitmask system that allows React to manage multiple updates with granular precision. Instead of a single "time to expire," React assigns updates to specific lanes (like a highway), allowing it to

OR (|) for Merging: When multiple state updates occur, React doesn't store them in an array. It merges them into a single pendingLanes integer using a | b.
AND (&) for Filtering: To check if a specific work cycle includes a particular priority, React uses (pendingLanes & SyncLane) !== NoLane.
Interrupt a low-priority "Transition Lane" (e.g., loading a search result) to process a "Sync Lane" (e.g., the user typing).
Merge tasks to ensure that the UI remains consistent across disparate state changes.

But why are bitmasks used? Because this allows React to use bitwise operators (&, |, ~) to merge or filter updates in constant time O(1) rather than iterating through arrays.

Because updates are grouped, React can pause a low-priority render (like a heavy data list) to handle a high-priority "SyncLane" event immediately. Once the urgent work is done, it resumes the lower-priority work using the same lane state.

A common issue with priority-based systems is starvation, where low-priority tasks (like an idle background task) never run because the user is constantly interacting with high-priority tasks (SyncLanes).

React tracks how long each lane has been pending. If a lane remains in the pendingLanes mask for too long, it "expires".
React then automatically merges that expired lane into the next SyncLane pass. This "promotes" the task, forcing it to render even if higher-priority work is still coming in, ensuring the UI eventually becomes consistent.

Hierarchical Propagation (childLanes)

Merging isn't just about combining updates, it's about signaling. When a child component has a pending update, its lane is merged into its parent's childLanes field.
This propagates all the way up to the Root Fiber.
During a render pass, if a parent component's lanes and childLanes bitwise intersection with the current "render lane" is zero (NoLanes), React can instantly skip (bail out) the entire subtree. It knows with 100% certainty that no urgent work exists below that point.

Photo by Bruce Tang on Unsplash

I'm getting stronger!

The Hierarchy of Lanes

React defines several categories of lanes to handle different types of user and system work:

SyncLane: Highest priority. Reserved for discrete user events like clicks and key presses that require immediate feedback.
InputContinuousLane: Used for continuous interactions like scrolling or mouse movement.
DefaultLane: The standard priority for general setState updates.
TransitionLanes: A set of 16 different lanes specifically for useTransition and startTransition. These are interruptible and can be processed in parallel.
IdleLane: Lowest priority for background tasks or offscreen content.

useTransition vs. useDeferredValue

As engineers, we must view these hooks not as "performance boosters," but as manual lane selectors for React's scheduler. Both hooks leverage Transition Lanes to move non-urgent work out of the SyncLane, preventing heavy renders from blocking user input.

useTransition (Imperative Orchestration): Use this when you have direct access to the state-updating code (e.g., setSearchTerm). By wrapping the update in startTransition, you explicitly tell React to assign this task a lower-priority lane. This is ideal for major UI shifts, like switching tabs or filtering lists, where you can also use the isPending flag to show a "Loading..." state. (https://react.dev/reference/react/useTransition)

The problem: The Heavy Data Dashboard

Imagine an enterprise dashboard where clicking a "Global Analytics" tab triggers a massive re-render involving thousands of data points or complex SVG charts.

Without useTransition (Blocking):

User clicks the "Analytics" tab.
React triggers an urgent state update.
The JavaScript main thread is locked for 500ms while React calculates the massive chart.

The Problem: If the user suddenly realizes they clicked the wrong tab and clicks "Home," the browser won't respond until the Analytics render finishes. The UI feels "frozen".

With useTransition (Concurrent/Interruptible):

We wrap the tab-switching logic in startTransition. This moves the "Analytics" render into a lower-priority Transition Lane.

const [isPending, startTransition] = useTransition();
const [tab, setTab] = useState('home');

function handleTabChange(nextTab) {
  // 1. High-priority: UI stays responsive to the next click

  startTransition(() => {
    // 2. Low-priority: This heavy render can be INTERRUPTED
    setTab(nextTab);
  });
}

return (
  <nav>
    <TabButton onClick={() => handleTabChange('analytics')}>
      {isPending ? <Spinner /> : 'Analytics'}
    </TabButton>
    <TabButton onClick={() => setTab('home')}>Home</TabButton>
  </nav>
);

useDeferredValue (Declarative Buffering): Use this when a value is passed down as a prop and you have no control over the source setState call. It creates a "lagging mirror" of a value. React will first re-render the UI with the old value (keeping the input responsive) and then, in the background, schedule a separate render for the new value in a Transition Lane. (https://react.dev/reference/react/useDeferredValue)

query:          r → re → rea → reac → react
deferredQuery:  "" → "" → r → re → react

The problem: expensive filtering blocks typing

Imagine a list with 10,000 items.

function Search() {
  const [query, setQuery] = useState("");

  const filteredItems = items.filter(item =>
    item.name.toLowerCase().includes(query.toLowerCase())
  );

  return (
    <>
      <input
        value={query}
        onChange={e => setQuery(e.target.value)}
      />
      <List items={filteredItems} />
    </>
  );
}

What goes wrong?

setQuery triggers a re-render on every keystroke

filter() runs every time
Large lists = input lag
Typing feels “sticky”

Now let’s introduce useDeferredValue.

import { useDeferredValue, useState } from "react";

function Search() {
  const [query, setQuery] = useState("");
  const deferredQuery = useDeferredValue(query);

  const filteredItems = items.filter(item =>
    item.name.toLowerCase().includes(deferredQuery.toLowerCase())
  );

  return (
    <>
      <input
        value={query}
        onChange={e => setQuery(e.target.value)}
      />
      <List items={filteredItems} />
    </>
  );
}

What changed? Only one thing:

- filter(query)
+ filter(deferredQuery)

While the user is typing:

Query updates immediately (high priority)
Input stays smooth

Meanwhile:

deferredQuery lags behind
Filtering runs less often
React schedules it as low priority

The Concurrent Model: Standardized in 2026

While Concurrent Mode was once an experimental opt-in, as we move through 2026, it is the default paradigm for high-performance React architecture. With React 19 now fully established, features like startTransition, useDeferredValue, and automatic batching aren't just "cool tricks" - they are the primary tools we use to orchestrate the "Update Streams" that Lanes manage under the hood.

What’s Next: The Priority Trilogy

Understanding Lanes is the first step in mastering React’s internal orchestration. However, Lanes are only the "logic" layer. To get the full picture of how React maintains 60fps in complex applications, we need to look at the systems on either side of the Lane bitmask.
In my upcoming articles, I will be doing deep-dives into:
The Event Priority System: How React translates physical user intent (clicks vs. scrolls) into Lane requests.
The Scheduler: How React negotiates with the browser's main thread to execute Lane-prioritized work without dropping frames.

Photo by Alex Kalinin on Unsplash

Understanding Promises and Coroutines in JavaScript

Hayk Sargsyan — Fri, 09 May 2025 13:42:08 +0000

As a JavaScript developer, you've probably heard terms like Promise, async/await, and maybe even coroutines thrown around a lot. Let’s break them down in a human way - no fancy words, just real-world explanations.

What is a Promise?

Think of a Promise as a placeholder for a value that you’ll get later.
Let’s say you order a pizza. You get a receipt — that's the promise. You don’t have the pizza yet, but the promise says, “Don’t worry, it’s coming.”
In code:

const pizzaOrder = new Promise((resolve, reject) => {
  setTimeout(() => {
    const isPizzaReady = true;
    if (isPizzaReady) {
      resolve("Pizza is ready!");
    } else {
      reject("Sorry, no pizza today.");
    }
  }, 3000);
});

pizzaOrder
  .then((message) => console.log(message))
  .catch((error) => console.error(error));

Here, .then() is like, “What do I do when the pizza arrives?” and .catch() is, “What if it doesn’t?”

Why Do We Use Promises?

JavaScript is single-threaded — it can do one thing at a time. Promises help us avoid blocking things while waiting for slower tasks (like API calls or timers).

Instead of freezing the app, Promises let JavaScript say, “I’ll come back to this when it’s ready,” and keep moving.

Async/Await = Cleaner Promises

Dealing with .then() and .catch() can get messy, especially with many steps.
So, JavaScript gave us a cleaner syntax: async and await.

async function makeDinner() {
  try {
    const pizza = await pizzaOrder;
    console.log(pizza); // "Pizza is ready!"
  } catch (error) {
    console.error(error);
  }
}

await tells JavaScript to pause until the promise is done — but it only works inside an async function.
This is where things start to feel like “coroutines.”

What’s a Coroutine?

In simple terms, a coroutine is a function that can pause and resume its execution.
JavaScript doesn’t have built-in coroutines like Python does with yield, but async/await gives us similar power.
With await, your function looks synchronous (step-by-step), but it actually runs asynchronously under the hood.

Coroutine Mechanics via Generators

Yielding Values:

function* greeter() {
  yield "Hi";
  yield "Hello";
  return "Bye";
}

const it = greeter();
console.log(it.next()); // { value: "Hi", done: false }
console.log(it.next()); // { value: "Hello", done: false }
console.log(it.next()); // { value: "Bye", done: true }

You can send values back into a coroutine using next(value).

async/await is JavaScript's native coroutine syntax. It abstracts away yield and generator handling.
Under the hood, async functions return a Promise and behave like auto-resuming coroutines.

When Should You Use Promises or Async/Await?

Use Promise when:

You want a task to run in the background.
You need to chain steps (.then().then().catch()).

Use async/await when:

You want cleaner, more readable async code.
You need to handle multiple async tasks step-by-step.

Final Thoughts

Promises and async/await make writing asynchronous code in JavaScript a lot easier than it used to be. Think of them as your way to say, “Do this thing, but let’s not freeze the app while we wait.”

If you're comfortable with Promises and async/await, you already know how to use coroutines - even if JavaScript doesn’t officially call them that.

Official Goodbye: The End of an Era for Create React App

Hayk Sargsyan — Sun, 16 Feb 2025 08:47:36 +0000

Hi!
A New Era Begins in the History of React.js!

Today, we’re deprecating Create React App for new apps, and encouraging existing apps to migrate to a framework. We’re also providing docs for when a framework isn’t a good fit for your project, or you prefer to start by building a framework.

As of February 13 2025, the recommended way to start a new React project is by using a framework that integrates seamlessly with React's architecture.

There are already involved variants of frameworks:

Next.js
React Router
Expo
Custom Builder

Next.js (App Router)
Next.js’s App Router is a React framework that takes full advantage of React’s architecture to enable full-stack React apps.

npx create-next-app@latest

React Router (v7)
React Router is the most popular routing library for React and can be paired with Vite to create a full-stack React framework. It emphasizes standard Web APIs and has several ready to deploy templates for various JavaScript runtimes and platforms.

npx create-react-router@latest

Expo (for native apps)
Expo is a React framework that lets you create universal Android, iOS, and web apps with truly native UIs. It provides an SDK for React Native that makes the native parts easier to use. To create a new Expo project, run.

npx create-expo-app@latest

You can build your custom framework according instructions here.

Unlocking the Power of React Server Components | Part 1

Hayk Sargsyan — Tue, 26 Nov 2024 12:55:01 +0000

👋 Hi, everyone!
React.js is one of the most popular JavaScript libraries for building user interfaces. While the React community well-documented, there are still some lesser-known themes and concepts.
Let's make tea or coffee, let's go!
React Server Components (RSC) are a new experimental feature introduced by the React team to optimize rendering performance. They allow developers to build parts of their app that are rendered on the server while still maintaining the React component model.
It's running in a separate environment from client or SSR server, and can be called once at build time on CI server, or they can be run for each request using a web server.
With power of React Server components we can read file content right in the our React component.
Below, there are a simple example, how can we do it.

import marked from 'marked'; // Not included in bundle
import sanitizeHtml from 'sanitize-html'; // Not included in bundle

async function Page({page}) {
  // NOTE: loads *during* render, when the app is built.
  const content = await file.readFile(`${page}.md`);

  return <div>{sanitizeHtml(marked(content))}</div>;
}

The client will only see the rendered output from the file. This means the content is visible during first page load, and the bundle does not include the expensive libraries (marked, sanitize-html) needed to render the static content.

Server Components with a Server

With Server Components we can communicate with database, fetch any data and use in the client. It's we can do it in Next.js applications too, integrate any ORMs.
Below is a simple example of the usage of Server Components for fetching data from database.

import db from './database';

async function Note({id}) {
  // NOTE: loads *during* render.
  const note = await db.notes.get(id);
  return (
    <div>
      <Author id={note.authorId} />
      <p>{note}</p>
    </div>
  );
}

async function Author({id}) {
  // NOTE: loads *after* Note,
  // but is fast if data is co-located.
  const author = await db.authors.get(id);
  return <span>By: {author.name}</span>;
}

In database file there can be implementation of data query from database.
For example:

const db = {
  notes: {
    get: async (id) => {
      return dbClient.query('SELECT * FROM notes WHERE id = ?', [id]);
    }
  },
  authors: {
    get: async (id) => {
      return dbClient.query('SELECT * FROM authors WHERE id = ?', [id]);
    }
  }
};

The bundler then combines the data, rendered Server Components and dynamic Client Components into a bundle. When the page loads, the browser does not see the original Note and Author components; only the rendered output is sent to the client. Server Components can be made dynamic by re-fetching them from a server, where they can access the data and render again.

The power of Async Components with Server Components

Server Components introduce a new way to write Components using async/await. When you await in an async component, React will suspend and wait for the promise to resolve before resuming rendering. This works across server/client boundaries with streaming support for Suspense.
The example of Server Component:

// Server Component
import db from './database';

async function Page({id}) {
  // Will suspend the Server Component.
  const note = await db.notes.get(id);

  // NOTE: not awaited, will start here and await on the client. 
  const commentsPromise = db.comments.get(note.id);
  return (
    <div>
      {note}
      <Suspense fallback={<p>Loading Comments...</p>}>
        <Comments commentsPromise={commentsPromise} />
      </Suspense>
    </div>
  );
}

// Client Component
"use client";
import {use} from 'react';

function Comments({commentsPromise}) {
  // NOTE: this will resume the promise from the server.
  // It will suspend until the data is available.
  const comments = use(commentsPromise);
  return comments.map(commment => <p>{comment}</p>);
}

The comments are lower-priority, so we start the promise on the server, and wait for it on the client with the *use * API. This will Suspend on the client, without blocking the note content from rendering.

In next parts, we will discuss Server Actions and Directives ("use client", "use server") power, and why "use server" doesn't have same role as "use client"🤔

See you soon!

While Server Components are still in the experimental phase, they are slowly gaining attention for their potential to improve large-scale applications. They eliminate the need for unnecessary JavaScript to be sent to the client, which results in faster loading times and a smoother user experience.