Forem: Taron Vardanyan

Risks When Business Logic Is Forgotten

Taron Vardanyan — Sat, 07 Feb 2026 13:15:58 +0000

Sometimes, the system remembers more than the people managing it.

In legacy or large projects, team changes happen frequently. New product managers arrive, stakeholders may forget key details, and important business logic risks being overlooked.

This can lead to feature duplication, conflicts, or unintended behavior if the technical team doesn’t step in.

Key Risks

Existing business rules get ignored or reimplemented
Features may conflict with hidden dependencies
Product behavior can become inconsistent or unpredictable

How Technical Teams Can Mitigate

Here are key approaches and considerations:

1️⃣ Document & Communicate

Keep technical documentation and system diagrams updated
Document existing features and dependencies clearly
Provide explanations when rejecting or modifying requests

2️⃣ Analyze Existing Features First

Before implementing a new request, check if the functionality already exists
Identify potential conflicts or redundancies
Suggest leveraging existing systems rather than building from scratch

3️⃣ Provide Trade-off Analysis

Explain implications: performance, maintenance, and user experience
Highlight risks: breaking legacy flows, introducing regressions
Give estimates of cost vs benefit

4️⃣ Use Controlled Rollouts

For features that might overlap with existing logic, implement in stages
Monitor for unexpected interactions
Provide stakeholders with real feedback before fully committing

5️⃣ Share Historical Context

Encourage onboarding sessions for new team members about historical decisions, product rationale, and technical constraints
This reduces future redundant requests and misaligned expectations

6️⃣ Roadmap Awareness

Maintain a clear roadmap outlining product direction, upcoming features, and priorities
Helps the team understand which features are planned and critical
Reduces redundant requests and confusion, aligning technical decisions with business goals

7️⃣ Respect Stakeholder Philosophy

Developers and technical teams care deeply about the product vision and the mindset of stakeholders
If stakeholders or executives focus only on adding features or profit without understanding the product, the team may face frustration
The value developers bring is in creating thoughtful, meaningful features, not just executing requests
Features implemented exactly according to a user story should not be blamed if the outcome does not satisfy stakeholders who are not fully involved in creation

Final Thought

When knowledge about business logic is lost or overlooked, the technical team becomes the guardian of continuity. A clear roadmap, proper documentation, and stakeholder engagement ensure the product evolves safely and efficiently even as teams change. Developers rely on stakeholder involvement to maintain meaningful outcomes and avoid misaligned expectations.

How do you handle business logic risks and stakeholder alignment in changing teams? 💬

Legacy Code: Refactor or Rewrite? Deciding From Business & Engineering Perspectives

Taron Vardanyan — Sat, 07 Feb 2026 11:44:52 +0000

Every production system has a story. Every decision has a cost.

Legacy code isn’t just “messy code.” It’s revenue, customers, and trust. It works — maybe not elegantly, maybe not consistently — but it works. And now, the question hits:

Should we refactor it… or rewrite it completely?

Let’s explore the decision from both business and development management angles.

1️⃣ When Refactoring Makes Sense

Refactoring is like cleaning and reorganizing a house while still living in it.

It’s ideal when:

The product is actively used and generating revenue
The system works correctly most of the time
Business logic is critical and well-understood only by existing teams
You want incremental improvement with minimal risk

From a business perspective:

Lower immediate cost compared to a full rewrite
Reduces risk of breaking something important
Preserves historical knowledge embedded in the code

From a development perspective:

Allows gradual improvement of code quality
Makes onboarding new engineers easier
Keeps architectural improvements aligned with real usage patterns

2️⃣ When Rewriting Becomes the Better Option

A rewrite is like building a new house from scratch. It’s costly, risky, but sometimes inevitable.

It becomes sensible when:

The current architecture cannot support future business goals
Technical debt is so high that feature development is slowed dramatically
Multiple inconsistent patterns exist that are impossible to unify safely
Legacy dependencies are obsolete or impossible to maintain

From a business perspective:

Higher short-term cost, but potentially lower long-term maintenance
Allows new features to be implemented faster in the future
Provides a clean slate for integrating AI tools, modern frameworks, or cloud infrastructure

From a development perspective:

Avoids patching fragile, inconsistent code repeatedly
Enables modern best practices and standards
Improves team morale — no one enjoys patching a brittle system forever

3️⃣ The Middle Ground: Strategic Refactor + Targeted Rewrite

Often the best path isn’t purely one or the other.

Critical paths can be rewritten gradually
Stable parts are refactored incrementally
Business logic is preserved while architecture is modernized

This approach balances risk, cost, and speed, keeping the system live and the business running.

4️⃣ Key Takeaways

Legacy code is not a problem — it’s a historical artifact of business and technology decisions
Refactoring is cheaper, safer, and ideal for incremental improvements
Rewriting is justified when technical debt blocks business growth or agility
AI and modern tools can amplify both approaches, but cannot replace the human understanding of business logic and system design

Final Thought:

Every system has its own “story.” Understanding why it exists, how it evolved, and where it must go next is the most important skill in software engineering. Refactoring and rewriting are just the tools — knowing when and how to use them is what separates good engineers from great ones.

Curious how others decide between refactor and rewrite in their legacy systems? Let’s discuss. 💬

Front-End Engineering in 2026: Evolution, Saturation, and the Untapped Paths

Taron Vardanyan — Sun, 01 Feb 2026 16:15:50 +0000

Being “just” a front-end developer is no longer a long-term strategy.

Front-end engineering has gone through multiple eras: from jQuery-powered websites, to SPA dominance, to framework specialization. In 2026, we’re entering a new phase — one defined by AI assistance, market saturation, and specialization pressure.

This post is not about panic. It’s about realism, positioning, and choosing the right evolutionary path.

The End of the One-Framework Career

For a long time, being really good at a single framework (React, Angular, Vue) was enough. That era is ending.

Today:

AI agents can scaffold, refactor, and debug across multiple frameworks
Switching between React, Vue, or Svelte is no longer a multi-month learning curve
Framework knowledge alone is becoming commoditized

AI doesn’t replace engineers — but it compresses skill gaps. A mid-level engineer with strong fundamentals and AI assistance can move faster than a specialist locked into one ecosystem.

That’s powerful.

But it creates a new problem.

The Market Reality: Too Many Front-End Engineers

If many engineers can now:

Build similar UIs
Ship features faster
Work across frameworks

Then the obvious question arises:

Why should companies hire all of them?

The truth is uncomfortable:

Front-end developers are numerous
Open positions are limited
Competition is brutal, especially for generic roles

Being “a front-end engineer” is no longer a differentiator.

The Usual Advice — And Why It’s Breaking

The classic recommendation is:

“Become a full-stack engineer.”

On paper, it makes sense. In practice, it’s splitting into two difficult paths.

Path 1: Full-Stack with Node.js

Yes, JavaScript knowledge transfers nicely to Node.js.

But reality check:

Most existing products are legacy systems
Backends are written in C#, Java, PHP, Ruby, Python
Node.js is still a newcomer in enterprise and long-lived systems

The chance that you:

Join a greenfield project
Choose Node.js freely
Grow as a JS full-stack engineer

…is much smaller than people think.

And the market is already full of experienced full-stack engineers.

Path 2: Learn a Second Backend Language

This path is even harder.

You must:

Learn a new language from scratch
Compete with backend-first engineers
Accept junior-level backend responsibility
Often not touch real production systems

This path is slow, risky, and heavily competitive.

Backend Awareness Still Matters (A Lot)

Let’s be clear: front-end engineers must understand backend concepts.

But not just REST.

In 2026, strong front-end engineers should be comfortable with:

GraphQL and schema-driven thinking
Apollo Client and cache strategies
RPC / tRPC patterns
Data ownership, contracts, and boundaries

This is not about writing backend services — it’s about understanding how data flows.

That knowledge is now baseline.

The Overlooked Evolution Path: Advanced Front-End Domains

There is another path. A bigger one. And it’s wildly underestimated.

Complex, High-Skill Front-End Applications

Not all front-end work is CRUD dashboards.

There are domains where:

AI helps less
Abstraction is thinner
Skill gaps are massive

Examples:

Construction & engineering visualization apps
Data-heavy analytical platforms
Real-time systems
2D and 3D animation-driven applications

And most importantly…

Game Development: The Front-End Gold Mine

Game development is one of the richest and least saturated front-end domains.

Especially in:

Web-based games
Gambling & casino platforms
Interactive entertainment

Why this matters:

Still heavily based on JavaScript
Requires deep rendering, timing, and state knowledge
Very few strong front-end engineers specialize here

Technologies worth learning:

PixiJS
Three.js
WebGL concepts
Animation lifecycles
Performance optimization

Compared to learning a new backend language, this path is:

Faster
More aligned with front-end thinking
Far less competitive

And demand?

Constant. Global. Well-paid.

The Competitive Advantage Nobody Talks About

In animation-heavy and game-oriented front-end work:

There is no crowd
Specialists are always in demand
Projects are long-running
Budgets are high

You don’t restart as a junior.
You evolve as an engineer.

You already know:

JavaScript
Rendering lifecycles
State management
Performance constraints

You’re just applying them in a deeper, more technical domain.

Final Thoughts

If you are a front-end engineer in 2026:

You are already an engineer — that part is done
Generic roles will keep shrinking
Backend knowledge is necessary, but not always the escape route

The real opportunity lies in specialized front-end universes:

Animation
Visualization
Game development
High-performance UI systems

There is less competition.
There is more depth.
And there is real long-term value.

Sometimes, the next step forward isn’t becoming more general —

It’s going deeper where others won’t go.

Thanks for reading. Curious to hear how others are navigating front-end careers in 2026.

AI Won’t Replace Software Engineers — It Will Terraform How We Build

Taron Vardanyan — Sat, 31 Jan 2026 10:37:57 +0000

AI will absolutely do the work of coders.
It will not replace software engineers.

This is a take shaped by years of working inside real, running, revenue‑generating legacy systems — the kind no one wants to rewrite, but everyone depends on.

A Quick Time Travel Through Web Development

From the early days of web development, we’ve accumulated a massive amount of legacy code.

Different eras.
Different teams.
Different skill levels.
Different pressures.

And as a result:

One file uses a clean pattern
The next file uses a completely different algorithm
Another file ignores architecture entirely
Naming conventions drift
State flows sideways
Business logic leaks into UI

Not because people were lazy — but because:

Standards didn’t exist yet
Deadlines were brutal
Experts weren’t always available
Products had to ship to survive

And here’s the important part:

👉 These systems still work.

They’re in production.
They make money.
They have users.
They cannot simply be “rewritten from scratch.”

This is the reality AI is walking into.

Legacy Chaos Is Not a Bug — It’s a Historical Artifact

Many modern engineers open a legacy project and think:

“Who wrote this?”

The real answer is:

Time did.

Legacy projects are not just codebases — they’re archaeological layers:

Old frameworks mixed with new ones
Patterns half‑adopted
Business rules encoded in strange places
UX decisions driven by domain constraints outsiders don’t see

And yet — the system behaves correctly.

That correctness is not accidental.

This Is Where AI Enters the Picture

AI is perfectly positioned to handle one specific kind of work:

🔧 The Work of Coders

AI can:

Refactor inconsistent files
Normalize styles and patterns
Translate between paradigms
Explain what a piece of code does in isolation
Generate boilerplate safely and fast
Fill in missing implementation details

In other words:

AI is exceptional at local reasoning.

Give it a file.
Give it a function.
Give it a pattern.

It will help.
A lot.

But Software Engineering Is Not Local Reasoning

Here’s the hard boundary.

Software engineering is about global understanding:

Why this system exists
What problem it actually solves
Which parts must never break
How files interact indirectly
How business logic flows across layers
How UX expectations shape architecture
What constraints come from the domain itself

This knowledge lives between files.

Not inside them.

The Invisible Glue: Business Logic & Domain Knowledge

Legacy systems often look chaotic until you understand the business.

Then suddenly:

That weird conditional makes sense
That duplicated logic exists for a reason
That “bad” abstraction protects a fragile workflow

AI does not own this context.

Software engineers do — together with:

Product managers
UX designers
Domain experts

This is not accidental.
This is human‑centered knowledge.

AI Will Terraform Software Engineering — Not Erase It

AI is not here to delete engineers.

It’s here to reshape the terrain:

Less time fighting syntax
Less time decoding messy files
Less time re‑implementing known patterns

More time spent on:

System design
Architecture decisions
Domain modeling
UX trade‑offs
Product thinking
Long‑term evolution

This is not replacement.

This is amplification.

The Real Shift: From Coders to Engineers

Historically, many roles were forced to blur:

Coders had to be engineers
Engineers had to be historians
Everyone had to fight the codebase

AI absorbs the mechanical load.

What remains is the work that:

Requires judgment
Requires responsibility
Requires understanding consequences

That work has always belonged to software engineers.

Final Thought

AI will 100% do the work of coders.

But software engineering is not just writing code.

It’s understanding:

Why the system exists
How it survives change
Where it must bend
Where it must never break

Legacy systems aren’t chaos.

They’re stories.

AI can help us read them faster.

But humans still decide how the story continues.

Curious how others are using AI inside legacy projects without breaking production? Let’s discuss. 💬

Redux Toolkit vs React Query: Do You Really Need Both? 🤔

Taron Vardanyan — Wed, 12 Nov 2025 17:49:27 +0000

For years, Redux was the go-to for state management in React apps.

Then came React Query (now TanStack Query) — and it changed how we handle server state forever.

But here's the confusion many developers face:

“If I’m using React Query, do I still need Redux?”

“Can Redux Toolkit replace React Query?”

Let’s clear the fog. 🌫️

🧠 First — Two Different Problems

Before comparing them, it’s crucial to understand what each tool actually manages.

Type of State	Description	Example
Client State	Data that exists only in the UI or app memory.	Modal open/close, filters, active tab
Server State	Data fetched from APIs or databases, often cached.	Users list, product data, comments

🧩 Redux Toolkit (RTK) → best for client state
🌐 React Query → best for server state

🧩 Redux Toolkit Overview

Redux Toolkit (RTK) is the official, modern way to write Redux — without the boilerplate.

It’s great for:

Local or global UI state
Caching small API responses
Complex app logic
Predictable, centralized state updates

Installation

npm install @reduxjs/toolkit react-redux

Example

import { createSlice, configureStore } from '@reduxjs/toolkit'
import { Provider, useSelector, useDispatch } from 'react-redux'

const counterSlice = createSlice({
  name: 'counter',
  initialState: { value: 0 },
  reducers: {
    increment: (state) => { state.value++ },
  },
})

const store = configureStore({
  reducer: { counter: counterSlice.reducer },
})

function Counter() {
  const count = useSelector((state) => state.counter.value)
  const dispatch = useDispatch()
  return (
    <button onClick={() => dispatch(counterSlice.actions.increment())}>
      Count: {count}
    </button>
  )
}

✅ Pros

Predictable, centralized store
Time-travel debugging and middleware
Immutable updates via Immer
Integration with async logic via createAsyncThunk
Scales beautifully for enterprise apps

⚠️ Cons

Boilerplate compared to local hooks
Manual caching and invalidation for API data
More setup for smaller apps

🌐 React Query (TanStack Query) Overview

React Query manages remote data fetching, caching, and syncing — not app logic.

It automates the painful parts of server-state management:

Fetching
Caching
Stale data invalidation
Background updates
Pagination & optimistic updates

Installation

npm install @tanstack/react-query

Example

import { useQuery, QueryClient, QueryClientProvider } from '@tanstack/react-query'

const queryClient = new QueryClient()

function Todos() {
  const { data, error, isLoading } = useQuery({
    queryKey: ['todos'],
    queryFn: () => fetch('/api/todos').then(res => res.json())
  })

  if (isLoading) return <p>Loading...</p>
  if (error) return <p>Error: {error.message}</p>

  return (
    <ul>
      {data.map(todo => <li key={todo.id}>{todo.title}</li>)}
    </ul>
  )
}

✅ Pros

Automatic caching and refetching
Handles background sync and retry logic
No reducers or actions — pure hooks
Amazing devtools for debugging
Ideal for data-heavy apps (dashboards, SaaS)

⚠️ Cons

Not designed for client UI state
No central store or global reducer logic
Limited control over global mutation side-effects

⚔️ Head-to-Head Comparison

Feature	Redux Toolkit	React Query
Primary Focus	Client/Global State	Server/Remote State
Data Source	Local or manual API calls	Fetched via queries
Caching	Manual	Automatic
Invalidation	Manual	Automatic
Setup Complexity	Moderate	Simple
Global Store	Yes	No
DevTools	Redux DevTools	React Query Devtools
Best For	State logic, app-wide control	Fetching & syncing backend data

🔀 Can You Use Both Together?

Absolutely — and many real-world apps do. 💪

They solve different concerns, and together they shine:

Use React Query for all server communication
Use Redux Toolkit for UI and app logic

Example integration:

// react-query handles data
const { data: todos } = useQuery(['todos'], fetchTodos)

// redux handles UI
const filter = useSelector(state => state.filter.value)
const filteredTodos = todos?.filter(todo => todo.status === filter)

This approach keeps your data layer and UI layer cleanly separated.

🧩 TL;DR

You Need...	Use
To manage app-wide UI state	Redux Toolkit
To handle API fetching and caching	React Query
To replace Redux entirely	React Query + local state
To handle everything with structure	Combine both

💬 Final Thoughts

Redux Toolkit and React Query aren’t competitors — they’re complements.

Think of them like this:

🧠 Redux: Your app’s brain (logic, actions, state)

🌍 React Query: Your app’s bloodstream (data flow and sync)

Use the right tool for the right job — and your React app will stay clean, fast, and predictable.

If you liked this post, follow me for more deep dives on React architecture and state management!

👉 @taronvardanyan

Node Package Managers Compared: npm vs Yarn vs pnpm vs Bun ⚙️

Taron Vardanyan — Wed, 12 Nov 2025 12:40:49 +0000

Every JavaScript developer installs packages — but not everyone realizes how different package managers really are.

Whether you’re building a side project or maintaining a massive monorepo, the choice between npm, Yarn, pnpm, and Bun can affect your speed, storage, and developer experience.

Let’s explore what sets them apart.

🧩 npm — The Classic Default

npm (Node Package Manager) is the original and still most widely used tool for managing Node.js dependencies.

It ships with Node.js, making it the easiest to start with.

✅ Pros

Comes preinstalled with Node.js
Huge ecosystem (1M+ packages)
Reliable package-lock.json for deterministic installs
Workspaces support for monorepos

❌ Cons

Slower installs compared to modern alternatives
Historically prone to dependency duplication
Larger node_modules size

📦 Example commands

npm install lodash  
npm uninstall lodash  
npm run build  
npm ci

⚡ Yarn — Speed and Reliability

Created by Facebook, Yarn was a response to npm’s early performance and consistency issues.

It introduced lock files, parallel installs, and offline caching, setting new standards for package management.

✅ Pros

Faster installs than npm (especially v1)
Predictable dependency trees (yarn.lock)
Offline caching
Great for monorepos with Yarn Workspaces

❌ Cons

Multiple major versions (v1, v2, v3) can cause confusion
Plug’n’Play (PnP) may break some tools
Slightly steeper learning curve

📦 Example commands

yarn add lodash  
yarn remove lodash  
yarn build  
yarn install --immutable

🪶 pnpm — Performance and Efficiency

pnpm (short for performant npm) takes a smart approach to dependency storage.

Instead of duplicating packages for every project, it uses a global content-addressable store and symlinks, saving tons of disk space.

✅ Pros

Blazing fast installs
Minimal disk usage via global cache
Strict dependency isolation — avoids “phantom dependencies”
Excellent monorepo support via pnpm workspaces

❌ Cons

Some CI/CD or tooling setups need extra tweaks
Learning curve if you’re coming from npm

📦 Example commands

pnpm add lodash  
pnpm remove lodash  
pnpm run build  
pnpm install --frozen-lockfile

🧈 Bun — The New All-in-One Runtime

Bun is more than a package manager — it’s a complete JavaScript runtime, written in Zig.

It bundles, runs, and installs dependencies at lightning speed.

✅ Pros

Incredibly fast installs and scripts
Bundler + test runner + runtime in one
Fully npm-compatible
Zero setup — works out of the box

❌ Cons

Still evolving; some Node APIs aren’t 100% supported
Smaller ecosystem than Node/npm
Potential compatibility issues for older packages

📦 Example commands

bun install  
bun add lodash  
bun remove lodash  
bun run build

⚔️ Benchmark Snapshot

Package Manager	Cold Install (s)	Reinstall (s)	Disk Space (MB)	Notes
npm	25–30	10–15	250+	Reliable but slower
Yarn	15–20	8–10	220+	Balanced and mature
pnpm	10–15	4–6	100–120	Ultra-efficient
Bun	3–5	2–3	100–110	Fastest overall

(Results vary based on network and hardware.)

🧠 Which One Should You Use?

Scenario	Recommended Tool
You want stability and compatibility	npm
You need a balance of speed and features	Yarn
You work with monorepos or large projects	pnpm
You love cutting-edge performance	Bun

🧭 TL;DR

npm → The standard and safest default.
Yarn → Familiar, stable, and faster than npm.
pnpm → Efficient and ideal for large-scale apps.
Bun → Future-facing speed demon.

Each tool has a unique philosophy — your best choice depends on team size, workflow, and ecosystem compatibility.

💬 Final Thoughts

The Node.js world is evolving fast.

What used to be a single choice (npm) is now a diverse ecosystem of package managers that prioritize speed, reliability, and efficiency.

If you haven’t yet, try running your next install with pnpm or Bun — the difference might surprise you.

Happy coding! ⚙️✨

Follow me for more deep dives into the modern JavaScript ecosystem!

👉 @taronvardanyan

Atomic State Management in React: Zustand vs Jotai vs Recoil ⚛️

Taron Vardanyan — Wed, 12 Nov 2025 07:37:55 +0000

React’s built-in useState and useContext work great — until they don’t.

When your app scales, managing shared and deeply nested state becomes messy. That’s where atomic state management libraries come in.

In this post, we’ll explore three of the most popular libraries that embrace this model:

Let’s dive into how each works, their strengths, and which might fit your project best.

🧩 What is Atomic State Management?

Traditional state managers like Redux rely on a single global store — all data flows through a central structure.

Atomic state flips that idea.

Instead of one big store, your state is composed of independent atoms — small, isolated units of state that can be subscribed to directly.

Each atom updates only the components that use it — no global re-renders, no boilerplate, no reducers.

⚡ Zustand: Minimal and Fast

Zustand is a tiny, unopinionated state manager that feels like using plain React hooks — but with superpowers.

npm install zustand

Example

import { create } from 'zustand'

const useStore = create((set) => ({
  count: 0,
  increase: () => set((state) => ({ count: state.count + 1 })),
}))

function Counter() {
  const { count, increase } = useStore()
  return (
    <button onClick={increase}>
      Count: {count}
    </button>
  )
}

✅ Pros

Minimal API (~1KB gzipped)
Direct, predictable mutations
Excellent for medium-to-large apps
Works outside React (e.g. vanilla JS)

⚠️ Cons

No built-in async or atom logic (you write it manually)
Less declarative than Jotai/Recoil

🧬 Jotai: Primitives for React State

Jotai (which literally means “atom” in Japanese) provides atomic state primitives — tiny pieces of state managed independently.

npm install jotai

Example

import { atom, useAtom } from 'jotai'

const countAtom = atom(0)

function Counter() {
  const [count, setCount] = useAtom(countAtom)
  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count}
    </button>
  )
}

✅ Pros

Simple mental model (like Recoil, but smaller)
Derivable atoms (atom(get => get(otherAtom) + 1))
SSR-friendly
Built on React’s native useSyncExternalStore

⚠️ Cons

Requires you to think atomically — might feel verbose for simple apps
Lacks centralized debugging tools (yet)

🪶 Recoil: Facebook’s Take on Atoms and Selectors

Recoil was built by Facebook to solve React’s global state challenges.

It introduces atoms and selectors for derived data.

npm install recoil

Example

import { atom, selector, useRecoilState, useRecoilValue } from 'recoil'

const countAtom = atom({
  key: 'count',
  default: 0,
})

const doubleCount = selector({
  key: 'doubleCount',
  get: ({ get }) => get(countAtom) * 2,
})

function Counter() {
  const [count, setCount] = useRecoilState(countAtom)
  const double = useRecoilValue(doubleCount)

  return (
    <div>
      <p>Count: {count}</p>
      <p>Double: {double}</p>
      <button onClick={() => setCount(count + 1)}>Increase</button>
    </div>
  )
}

✅ Pros

Mature, production-ready (used at Meta)
Powerful selectors (derived/computed state)
Great dev tools and debugging

⚠️ Cons

Larger bundle (~15KB)
Requires RecoilRoot provider
Still React-only (no vanilla JS usage)

⚖️ When to Choose What

Library	Best For	API Style	Size	Ecosystem
Zustand	Scalable apps needing minimal setup	Mutations	~1KB	Strong (PMNDRS)
Jotai	Declarative atomic apps	Primitives	~3KB	Moderate
Recoil	Large apps needing selectors and tooling	Atoms + Selectors	~15KB	Mature

🧠 TL;DR

Zustand → If you want simplicity and speed.
Jotai → If you want minimalism with atomic reactivity.
Recoil → If you want structure, selectors, and dev tools.

All three are excellent — the “best” choice depends on your project’s scale and mental model preference.

💬 Final Thoughts

Atomic state management isn’t just a buzzword — it’s a mindset shift.

It helps React apps stay predictable, performant, and modular as they grow.

If you haven’t tried these yet:

Start with Zustand to grasp the basics.
Move to Jotai or Recoil for more reactive patterns.

Happy coding! ⚛️✨

If you enjoyed this, follow me for more deep dives on modern React state patterns!

👉 @taronva

Atomic State Management in React: Zustand vs Jotai vs Recoil ⚛️

Taron Vardanyan — Wed, 12 Nov 2025 07:37:55 +0000

In this post, we’ll explore three of the most popular libraries that embrace this model:

Let’s dive into how each works, their strengths, and which might fit your project best.

🧩 What is Atomic State Management?

Traditional state managers like Redux rely on a single global store — all data flows through a central structure.

Atomic state flips that idea.

Instead of one big store, your state is composed of independent atoms — small, isolated units of state that can be subscribed to directly.

Each atom updates only the components that use it — no global re-renders, no boilerplate, no reducers.

⚡ Zustand: Minimal and Fast

Zustand is a tiny, unopinionated state manager that feels like using plain React hooks — but with superpowers.

npm install zustand

Example

import { create } from 'zustand'

const useStore = create((set) => ({
  count: 0,
  increase: () => set((state) => ({ count: state.count + 1 })),
}))

function Counter() {
  const { count, increase } = useStore()
  return (
    <button onClick={increase}>
      Count: {count}
    </button>
  )
}

✅ Pros

Minimal API (~1KB gzipped)
Direct, predictable mutations
Excellent for medium-to-large apps
Works outside React (e.g. vanilla JS)

⚠️ Cons

No built-in async or atom logic (you write it manually)
Less declarative than Jotai/Recoil

🧬 Jotai: Primitives for React State

Jotai (which literally means “atom” in Japanese) provides atomic state primitives — tiny pieces of state managed independently.

npm install jotai

Example

import { atom, useAtom } from 'jotai'

const countAtom = atom(0)

function Counter() {
  const [count, setCount] = useAtom(countAtom)
  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count}
    </button>
  )
}

✅ Pros

Simple mental model (like Recoil, but smaller)
Derivable atoms (atom(get => get(otherAtom) + 1))
SSR-friendly
Built on React’s native useSyncExternalStore

⚠️ Cons

Requires you to think atomically — might feel verbose for simple apps
Lacks centralized debugging tools (yet)

🪶 Recoil: Facebook’s Take on Atoms and Selectors

Recoil was built by Facebook to solve React’s global state challenges.

It introduces atoms and selectors for derived data.

npm install recoil

Example

import { atom, selector, useRecoilState, useRecoilValue } from 'recoil'

const countAtom = atom({
  key: 'count',
  default: 0,
})

const doubleCount = selector({
  key: 'doubleCount',
  get: ({ get }) => get(countAtom) * 2,
})

function Counter() {
  const [count, setCount] = useRecoilState(countAtom)
  const double = useRecoilValue(doubleCount)

  return (
    <div>
      <p>Count: {count}</p>
      <p>Double: {double}</p>
      <button onClick={() => setCount(count + 1)}>Increase</button>
    </div>
  )
}

✅ Pros

Mature, production-ready (used at Meta)
Powerful selectors (derived/computed state)
Great dev tools and debugging

⚠️ Cons

Larger bundle (~15KB)
Requires RecoilRoot provider
Still React-only (no vanilla JS usage)

⚖️ When to Choose What

Library	Best For	API Style	Size	Ecosystem
Zustand	Scalable apps needing minimal setup	Mutations	~1KB	Strong (PMNDRS)
Jotai	Declarative atomic apps	Primitives	~3KB	Moderate
Recoil	Large apps needing selectors and tooling	Atoms + Selectors	~15KB	Mature

🧠 TL;DR

Zustand → If you want simplicity and speed.
Jotai → If you want minimalism with atomic reactivity.
Recoil → If you want structure, selectors, and dev tools.

All three are excellent — the “best” choice depends on your project’s scale and mental model preference.

💬 Final Thoughts

Atomic state management isn’t just a buzzword — it’s a mindset shift.

It helps React apps stay predictable, performant, and modular as they grow.

If you haven’t tried these yet:

Start with Zustand to grasp the basics.
Move to Jotai or Recoil for more reactive patterns.

Happy coding! ⚛️✨

If you enjoyed this, follow me for more deep dives on modern React state patterns!

👉 @taronva

React 19.2: Deep Dive into Activity and useEffectEvent

Taron Vardanyan — Mon, 10 Nov 2025 10:52:47 +0000

React 19.2: Deep Dive into Activity and useEffectEvent

React 19.2 introduces two exciting new developer APIs: Activity and useEffectEvent.

These features make it easier to manage hidden UI, preserve component state, and handle effects without stale closures or unnecessary re-renders.

In this post, we’ll explore each in detail.

🚀 Activity Component

What it is

The Activity component allows you to manage parts of your UI that you want to hide or defer without fully unmounting them, while controlling effect behavior and update priority.

It provides a middle ground between:

Conditional rendering ({visible && <Component />}), which unmounts the component and loses state.
CSS-based hiding (display: none), which preserves state but keeps effects running and consuming resources.

The Activity component lets you preserve state while pausing effects when a subtree is hidden.

How it works

Wrap a subtree inside <Activity mode={...}>.
Supported modes in v19.2 are visible and hidden.
- visible: the component is shown, and effects run normally.
- hidden: effects are paused/unmounted, but state is preserved. Updates may be deprioritized.

This makes Activity ideal for components that:

Are hidden temporarily (tabs, modals, sidebars).
Need their internal state preserved while not actively rendering or running effects.
Benefit from deferred updates for performance optimization.

Key Use Cases

Tab panels that preserve forms or input state when switching tabs.
Sidebars or drawers that toggle visibility but keep scroll position and input data.
Pre-rendering non-critical UI to improve perceived responsiveness.

Important Considerations

Hidden components won’t run effects, so data fetching or subscriptions must be handled carefully.
Updates are deferred, so background updates may not occur until visible.
Behavior differs from unmounting — components expecting cleanup on hide may need adjustment.
Check compatibility with SSR and frameworks like Next.js.

🧠 useEffectEvent Hook

What it is

The useEffectEvent hook allows you to define callbacks that always see the latest props and state without causing unnecessary effect re-runs.

It solves the common “stale closure” problem in React hooks, where callbacks inside useEffect may reference outdated state or require overly broad dependency arrays.

How it works

Define an event callback using useEffectEvent.
Inside the callback, you can safely access the latest state and props.
The callback does not trigger the effect to re-run unnecessarily.
This separates reactive effect setup/cleanup from event logic that depends on dynamic values.

Benefits

Avoids stale closures in callbacks inside effects.
Reduces unnecessary effect re-executions.
Cleans up code by separating setup/cleanup logic from event handling.

Key Considerations

Still requires proper effect dependencies; it is not a shortcut to ignore dependency arrays.
Event callbacks should not be treated as general-purpose functions passed around arbitrarily.
Test behavior carefully with SSR and concurrent rendering scenarios.

🔑 Summary

React 19.2 introduces:

Activity component: Hide UI while preserving state and pausing effects.
useEffectEvent hook: Define event callbacks that always see the latest props/state without unnecessary effect reruns.

These tools improve developer ergonomics and app performance, particularly in complex UI-heavy applications and server-rendered environments.

💬 Have you tried using Activity or useEffectEvent in your projects yet?

How do you see them fitting into your component patterns? Let’s discuss in the comments below.

Arcjet: Developer-First Security for Modern Apps

Taron Vardanyan — Mon, 10 Nov 2025 09:41:51 +0000

In today’s world of serverless architectures, edge deployments, and AI-driven applications, security needs to evolve.

Arcjet is a new player aiming to make security painless for developers.

It brings intelligent protection like bot blocking, rate limiting, and abuse prevention directly into your code — not just around it.

In this post, we’ll explore what Arcjet does, why it matters, and where it fits in a modern developer workflow.

🚨 The Modern Security Challenge

Traditional app security used to rely on the fortress model — one monolithic app behind one big firewall.

But that approach no longer works in 2025.

Today’s applications are distributed across microservices, edge functions, and serverless runtimes.

They face threats like automated scraping, signup abuse, API misuse, and token spam.

Developers now need security that integrates with their code, not an external layer they have to maintain separately.

Arcjet’s philosophy is simple:

“Bring security into your runtime — where your logic already lives.”

🧰 What Arcjet Offers

Arcjet focuses on giving developers modern, programmable security tools that work the way they build software.

Key features

Bot detection and blocking — identify and stop malicious automated traffic.
Context-aware rate limiting — throttle requests dynamically based on user role, plan, or endpoint.
Email validation — catch disposable or spammy signups before they reach your database.
Abuse prevention and data redaction — safeguard sensitive routes and forms.
Developer-first SDKs — built for Node.js, Deno, Bun, and Next.js environments.
Generous free tier — includes multiple rules and developer seats for small teams or startups.

Because Arcjet operates directly in your code, it has full request context — meaning it can make smarter decisions than a traditional external firewall.

🚀 Getting Started at a High Level

Setting up Arcjet typically follows a few straightforward steps:

Sign up at arcjet.com and create a project.
Install the SDK that matches your runtime (for example, Node.js or Next.js).
Define rules that control how your app reacts to different traffic or abuse conditions.
Monitor events, blocked bots, and rate limits from the Arcjet dashboard.

This design lets you manage security as part of your normal development workflow — versioned, testable, and easy to evolve.

🧩 Where Arcjet Fits Best

Arcjet fits particularly well in use cases where developers need contextual, fine-grained control:

SaaS applications with different usage tiers or quotas.
Public APIs that need protection from bots and scrapers.
Serverless or edge-hosted applications without a traditional network perimeter.
Teams looking to shift security “left” — building it directly into their codebase.

💡 Why Arcjet Stands Out

Built for developers: Unlike most security tools aimed at ops teams, Arcjet integrates right into your code.
Modern threat coverage: It tackles issues like API abuse, automated scraping, and even AI token misuse.
Strong early momentum: Arcjet raised a $3.6M seed round in 2024 to expand SDK support and developer features. Source: Seedcamp’s announcement

It’s security that feels like a natural extension of your app — not a separate piece of infrastructure you have to fight with.

⚙️ Questions to Consider

Before adopting Arcjet, it’s worth exploring:

How expressive and flexible is the rule engine?
What’s the performance impact in serverless or edge environments?
How reliable and accurate is the bot detection?
Can its logs integrate with tools like Sentry or Datadog?
What happens if the SDK or API is temporarily unavailable?

As with any embedded system, understanding its behavior under load or failure conditions is key.

🧭 My Take

Arcjet addresses a real gap in the modern security stack: the need for application-aware protection that developers can actually use and control.

For SaaS, APIs, or serverless applications, Arcjet provides:

Granular, programmable rate limits
Smarter abuse prevention
Faster, code-driven iteration on security policies

It’s not meant to replace traditional network or infrastructure protections — but it’s a powerful addition for anyone building modern apps.

✨ Final Thoughts

Security shouldn’t be an afterthought or a blocker.

With Arcjet, developers can treat security as part of the application logic itself — configurable, testable, and deployable right alongside the rest of their code.

If you’re building APIs, SaaS tools, or edge apps, Arcjet is worth a look.

🔗 Learn more: https://arcjet.com

💬 Have you tried embedding security logic directly into your applications?

What do you think of the “developer-first” approach Arcjet promotes?

Let’s discuss in the comments 👇

Create a UI Kit with Vite + React + TypeScript + Tailwind CSS + shadcn/ui + NPM Linking

Taron Vardanyan — Fri, 27 Jun 2025 12:35:14 +0000

Step-by-step guide to building and locally linking your own UI component kit using modern frontend tools.

🧰 Build a UI Kit with Vite + React + TypeScript + Tailwind CSS + shadcn/ui + NPM Linking

If you're working on multiple projects or collaborating with teams, building your own UI Kit helps create reusable, consistent components across apps.

In this tutorial, you'll learn to build one using:

⚡ Vite.js with React + TypeScript
🎨 Tailwind CSS
🧱 shadcn/ui
📦 Local NPM linking (to share across apps)

✅ Prerequisites

Before we begin, ensure the following are installed on your system:

Node.js (v18 or newer)
pnpm (recommended) or you can use npm or yarn

1️⃣ Create Project with Vite + React + TypeScript

Start by scaffolding the project using Vite:

pnpm create vite ui-kit --template react-ts
cd ui-kit
pnpm install

📁 This will create a project with:

React
TypeScript
Fast Vite dev server

2️⃣ Install and Configure Tailwind CSS

Tailwind CSS is a utility-first CSS framework that lets you rapidly build custom designs.

📦 Install Tailwind and dependencies

Run the following command to install Tailwind CSS along with PostCSS and Autoprefixer:

pnpm install -D tailwindcss postcss autoprefixer
npx tailwindcss init -p

This will create two configuration files in your project root:

tailwind.config.ts — Tailwind configuration
postcss.config.js — PostCSS configuration

⚙️ Configure tailwind.config.ts

Edit the tailwind.config.ts file to specify where Tailwind should look for class names:

import type { Config } from 'tailwindcss'

const config: Config = {
  content: [
    './index.html',
    './src/**/*.{ts,tsx}', // Scan all TS and TSX files in src
  ],
  theme: {
    extend: {},
  },
  plugins: [],
}

export default config

🎨 Add Tailwind directives to your CSS

Create or open src/index.css and add the following:

@tailwind base;
@tailwind components;
@tailwind utilities;

🧵 Import Tailwind CSS in your app entry point

Open src/main.tsx and import the stylesheet:

import React from 'react'
import ReactDOM from 'react-dom/client'
import App from './App'
import './index.css' // Import Tailwind CSS styles

ReactDOM.createRoot(document.getElementById('root')!).render(
  <React.StrictMode>
    <App />
  </React.StrictMode>
)

Now your project is configured to use Tailwind CSS!

3️⃣ Setup shadcn/ui

The shadcn/ui toolkit provides a beautiful, accessible set of React components styled with Tailwind CSS and powered by Radix UI primitives. It helps you quickly build consistent UI elements in your project.

🔧 Run the shadcn/ui installer

Use the following command to initialize shadcn/ui in your project:

pnpm dlx shadcn-ui@latest init

Answer the CLI prompts:

Select tailwind.config.ts
Set your component path to src/components
Choose components like Button, Card, Input, etc.

Now you’ll have ready-to-use UI primitives inside your project!

4️⃣ Create Your Own Components

With your UI Kit project set up, you can start building custom reusable components tailored to your design system.

📁 Organize components

Create a folder inside src/components/ui to hold your custom components, for example:

src/components/ui/

🛠️ Example: Creating a `Badge` component

Here’s a simple Badge component that uses Tailwind CSS utility classes and supports additional styling via props:

// src/components/ui/Badge.tsx
import { cn } from '@/lib/utils' // Utility for conditional classNames (optional)

interface BadgeProps extends React.HTMLAttributes<HTMLDivElement> {}

export function Badge({ children, className, ...props }: BadgeProps) {
  return (
    <div
      className={cn(
        'inline-block px-2 py-1 text-sm rounded bg-gray-200 text-gray-800',
        className
      )}
      {...props}
    >
      {children}
    </div>
  )
}

🧩 Usage example

Import and use your Badge component anywhere in your app:

import { Badge } from '@/components/ui/Badge'

export default function Demo() {
  return <Badge>New</Badge>
}

5️⃣ Setup NPM Linking for Local Use

To reuse your UI Kit components across multiple local projects during development, you can set up local npm linking. This lets you work on your UI Kit and consume it in other projects without publishing to the npm registry.

✍️ Prepare your `package.json`

Make sure your UI Kit's package.json includes the following important fields:

{
  "name": "@your-scope/ui-kit",
  "version": "0.0.1",
  "main": "./dist/index.js",
  "types": "./dist/index.d.ts",
  "files": ["dist"],
  "scripts": {
    "build": "tsc"
  }
}

name: Use a unique package name, preferably scoped (e.g., @your-scope/ui-kit)
main and types: Point to your build output files
files: Include only your build folder when publishing
scripts.build: Build script to compile TypeScript to JavaScript

🧠 Add a build tsconfig.json

Create or update tsconfig.json for building your UI Kit as a library:

{
  "compilerOptions": {
    "target": "ESNext",
    "module": "ESNext",
    "declaration": true,
    "outDir": "./dist",
    "jsx": "react-jsx",
    "moduleResolution": "Node",
    "esModuleInterop": true,
    "skipLibCheck": true,
    "strict": true
  },
  "include": ["src"]
}

Run the build command to generate your compiled files:

pnpm run build

🔗 Link your package globally

In your UI Kit project root, run:

pnpm link --global

This registers your UI Kit package globally on your machine.

🔗 Link your package in a consuming project

In any project where you want to use your UI Kit, run:

pnpm link --global @your-scope/ui-kit

This links the global UI Kit package into the local project’s node_modules.

🚀 Use your UI Kit components

Now you can import and use your UI Kit components as if they were installed from npm:

import { Badge } from '@your-scope/ui-kit'

export default function Demo() {
  return <Badge>Linked Badge</Badge>
}

🔄 Keep in mind

After making changes in your UI Kit, rebuild it (pnpm run build) to update the linked files
Some bundlers/watchers may require restarting to pick up changes from linked packages
When ready, you can publish your UI Kit to npm for easier sharing

Local linking allows seamless iterative development of your UI Kit and consuming apps together!

🪟 How to Open and Communicate with a Popup Window in React (with TypeScript)

Taron Vardanyan — Thu, 26 Jun 2025 11:38:07 +0000

Opening a popup window in React isn't hard—but managing communication between your app and that popup can get tricky. In this article, you'll learn how to:

Open a new browser window (popup)
Send data from the parent React app to the popup
Detect when the popup is closed

We’ll be using React Function Components with TypeScript to make this solution strongly typed and future-proof.

🧠 What You’ll Learn

How to open a popup window with specific dimensions
How to communicate with that popup window using postMessage
How to watch for popup closure using setInterval
A clean, reusable TypeScript implementation

📦 Let’s Build It!

1. Create the Popup Component

This component will live inside the popup window and receive data from the parent window using message events.

// PopupPage.tsx
import { useEffect, useState } from 'react';

const PopupPage = () => {
  const [message, setMessage] = useState<any>(null);

  useEffect(() => {
    const handleMessage = (event: MessageEvent) => {
      // Optionally: restrict to same-origin in production
      if (event.origin !== window.location.origin) return;

      console.log('Received message:', event.data);
      setMessage(event.data);
    };

    window.addEventListener('message', handleMessage);
    return () => window.removeEventListener('message', handleMessage);
  }, []);

  return (
    <div style={{ padding: 20 }}>
      <h2>Popup Window</h2>
      <p>
        <strong>Message from parent:</strong>
      </p>
      <pre style={{ background: '#eee', padding: '10px' }}>
        {message ? JSON.stringify(message, null, 2) : 'No message received'}
      </pre>
    </div>
  );
};

export default PopupPage;

2. Create the Main App with Popup Logic

This component handles the logic to open the popup, send a message, and watch for closure.

// App.tsx
import React, { useRef, useState } from 'react';

const App: React.FC = () => {
  const popupRef = useRef<Window | null>(null);
  const timerRef = useRef<NodeJS.Timer | null>(null);
  const [popupOpen, setPopupOpen] = useState(false);

  const openPopup = () => {
    if (popupRef.current && !popupRef.current.closed) {
      popupRef.current.focus();
      return;
    }

    const width = 400;
    const height = 300;
    const left = window.screenX + (window.outerWidth - width) / 2;
    const top = window.screenY + (window.outerHeight - height) / 2;

    popupRef.current = window.open(
      '/popup',
      'MyPopup',
      `width=${width},height=${height},left=${left},top=${top}`
    );

    if (popupRef.current) {
      setPopupOpen(true);
      startWatcher();
    }
  };

  const sendMessage = () => {
    popupRef.current?.postMessage('Hello from parent!', window.origin);
  };

  const startWatcher = () => {
    timerRef.current = setInterval(() => {
      if (!popupRef.current || popupRef.current.closed) {
        clearInterval(timerRef.current!);
        timerRef.current = null;
        popupRef.current = null;
        setPopupOpen(false);
        alert('Popup was closed');
      }
    }, 500);
  };

  return (
    <div style={{ padding: 20 }}>
      <h1>React Popup Communication (TS)</h1>
      <button onClick={openPopup}>Open Popup</button>
      <button onClick={sendMessage} disabled={!popupOpen}>
        Send Message
      </button>
    </div>
  );
};

export default App;

🛣️ Setting Up the Route for the Popup

If you're using React Router, you can route the popup like this:

// index.tsx
import React from 'react';
import ReactDOM from 'react-dom/client';
import { BrowserRouter, Routes, Route } from 'react-router-dom';
import App from './App';
import PopupPage from './PopupPage';

const root = ReactDOM.createRoot(document.getElementById('root')!);

root.render(
  <BrowserRouter>
    <Routes>
      <Route path="/" element={<App />} />
      <Route path="/popup" element={<PopupPage />} />
    </Routes>
  </BrowserRouter>
);

☕ Enjoyed this post?

If you'd like to support my work, you can buy me a coffee — it really helps and means a lot!