DEV Community: nishchal singh

I Built AI Streaming With Too Many Layers. Here’s What Broke

nishchal singh — Mon, 14 Sep 2026 12:16:34 +0000

I was working on the AI assistant for an NGO application when I ran into a streaming problem that took me through a few different layers of the system.

The chat worked locally.

In production, it didn't.

Then I fixed a platform timeout and found another timeout. After that, I found something even stranger: OpenRouter was returning 200, but my application was receiving zero usable streaming events.

Eventually, I realized the bigger problem wasn't one broken request.

I had made the streaming architecture more complicated than it needed to be.

This is how I found it, what I changed, and what I'm still investigating.

The setup

The application uses Next.js App Router, React, TypeScript, MongoDB/Mongoose, Clerk, TanStack Query, Cloudinary and OpenRouter.

The AI assistant is available at:

https://www.pssmumbai.org/ai

The public chat endpoint is:

POST /api/ai/chat

The assistant uses reviewed application knowledge to answer questions around PSS teachings, meditation and related topics.

There is quite a bit happening before and after the model call:

Authentication
Rate limiting
Quota
Conversation history
Knowledge retrieval
AI response
Conversation persistence
Usage tracking

For the model interaction, I use:

openai/gpt-5-mini

through OpenRouter.

I wanted the response to stream to the browser rather than waiting for the complete answer.

That's where my architecture had become unnecessarily complicated.

The streaming setup I had built

The application already had an AI SDK implementation using:

streamText()

and:

@openrouter/ai-sdk-provider

But there was also an older custom streaming implementation.

The older path used an OpenAI-compatible wrapper in:

src/lib/openai.ts

That wrapper made its own request to OpenRouter and requested:

Accept: text/event-stream

The API route then manually handled the provider response.

It had to read chunks, parse SSE events, extract token deltas, detect completion and usage, accumulate the response, and eventually convert the result into our own NDJSON format.

The browser then had another custom parser to consume that NDJSON stream.

So the flow was roughly:

Browser
  ↓
fetch()
  ↓
Custom NDJSON parser
  ↓
Next.js API route
  ↓
Custom OpenRouter wrapper
  ↓
Custom SSE parser
  ↓
OpenRouter
  ↓
GPT-5 Mini

There was also an AI SDK path sitting alongside it.

That was the first thing I should have questioned.

The system had multiple layers that understood the same stream.

Then production failed

The first error I saw in the browser was:

Unexpected token 'A', "An error o"... is not valid JSON

At first, I thought I had a JSON/API response problem.

Maybe the server was returning an unexpected response.

Maybe the frontend parser was wrong.

Maybe the error response itself wasn't valid JSON.

So I opened the Network tab.

The important part was:

POST /api/ai/chat

returned:

504 Gateway Timeout

The JSON error was only a symptom.

The actual request wasn't completing.

This was a good reminder that browser errors don't always tell you where the failure started. Sometimes you have to follow the request one layer deeper.

The Vercel timeout

The Vercel logs made the first problem much clearer:

FUNCTION_INVOCATION_TIMEOUT

The execution was:

10.37s / 10s

The function was being terminated before the AI request could complete.

I checked the repository for anything that might have configured this limit.

There was no:

vercel.json

There was no route-level:

maxDuration

and no runtime override that I had intentionally added.

So I checked the Vercel project settings.

Fluid Compute was disabled.

I enabled it and redeployed.

The function now had a much larger execution window.

That fixed the platform-level timeout.

But it also exposed another problem.

Fixing the timeout didn't fix the request

After the deployment, the application started reaching its own timeout instead.

The response was now a controlled application error:

AI_TIMEOUT

with:

The AI service took too long to respond. Please try again.

The application-level timeout was around:

20 seconds

This was actually useful.

The first problem had been:

Platform timeout

Now I was looking at:

Application/provider streaming latency

Increasing the available function duration hadn't made the streaming implementation correct.

It had simply allowed the request to get further.

So I added more timing and streaming logs.

The strange part: OpenRouter returned 200

This was the most interesting trace.

The request successfully passed the application stages:

auth_end
rate_limit_end
quota_reserve_end
conversation_lookup_end
retrieve_context_end

Then:

openrouter_request_start
streaming=true

And OpenRouter responded:

openrouter_stream_headers
status=200

That sounds good.

But immediately after that, the stream counters told a very different story:

chunkCount=0
parsedEventCount=0
deltaCount=0
accumulatedChars=0
sawFinishReason=false
sawUsage=false
sawDone=false

Eventually:

openrouter_stream_unexpected_eof

The API eventually returned:

POST /api/ai/chat 200

but the browser received:

The AI service disconnected before completing the response.

So I had an HTTP 200 from the provider, but no usable streamed content made it through my custom streaming path.

That was the clue I needed.

I couldn't reasonably conclude that OpenRouter itself was broken.

The evidence pointed me toward the path I had built around the provider.

Instead of patching the parser, I made a smaller test

At this point, I could have kept modifying the custom SSE parser.

But I wanted a simpler answer first:

Can the AI SDK receive a stream from OpenRouter correctly?

So I created an isolated test using:

AI SDK v6
+
@openrouter/ai-sdk-provider
+
OpenRouter
+
openai/gpt-5-mini

The test successfully produced streamed deltas.

The result included things like:

success: true
model: openai/gpt-5-mini
deltasCount: 4
accumulatedChars: 21
finishReason: stop
usage present
providerRequestId present

I wouldn't rely on the exact timing from that isolated test because the instrumentation lifecycle around it wasn't reliable enough.

But the important result was much simpler:

The AI SDK + OpenRouter combination could successfully receive streamed output.

That changed how I looked at the problem.

I didn't necessarily need to find the exact line where my custom parser was failing.

I needed to ask whether I should have that parser in the first place.

The actual architectural problem

Looking back, I was solving too much myself.

The application had custom code handling:

Provider streaming
SSE parsing
Transport conversion
Client stream parsing
Message accumulation
Cancellation
Completion handling

And there was already a mature abstraction available for the model streaming part.

The problem wasn't that custom streaming code is always wrong.

The problem was that I had multiple layers responsible for the same thing.

The browser understood one streaming protocol.

The API route translated between protocols.

The OpenRouter wrapper understood another streaming protocol.

The SSE parser interpreted provider events.

And the AI SDK had its own streaming abstraction.

That creates more places where a response can be transformed, misunderstood or dropped.

It also makes debugging harder because the error you see may be several layers away from where the problem started.

The change: one authoritative streaming path

I decided to stop using the legacy custom streaming path for the public chat route.

The new flow is much simpler:

Browser
  ↓
POST /api/ai/chat
  ↓
Authentication
  ↓
Rate limiting
  ↓
Quota
  ↓
Conversation lookup
  ↓
Knowledge retrieval
  ↓
streamText()
  ↓
@openrouter/ai-sdk-provider
  ↓
OpenRouter
  ↓
GPT-5 Mini
  ↓
Stream back to browser
  ↓
Save completed response
  ↓
Persist usage

The public route no longer calls:

getOpenAIClient().chat.completions.stream()

and it no longer manually parses OpenRouter's raw SSE response.

The existing OpenAI-compatible wrapper wasn't removed completely because other non-streaming/admin functionality still uses it.

The change was specifically about the public streaming path.

The important architectural decision was:

There should be one authoritative implementation responsible for the model stream.

I didn't change the frontend at the same time

There was another problem I wanted to avoid.

The frontend already understood our NDJSON protocol:

{ "type": "delta", "text": "..." }

{ "type": "done", "..." }

{ "type": "error", "..." }

I could have changed the server transport, frontend parser and message handling in one large refactor.

I didn't.

For the first change, I kept the existing browser contract and replaced the provider-side streaming implementation.

So temporarily, the architecture became:

AI SDK
  ↓
AI SDK stream
  ↓
Small compatibility layer
  ↓
Existing NDJSON client

This wasn't intended to be the final architecture.

It was a way to change one layer at a time and reduce the number of variables involved in the debugging.

The longer-term plan is to move the frontend away from custom fetch() + NDJSON parsing and eventually use the AI SDK's React transport.

But that can happen separately.

The first successful end-to-end test

After changing the public route, I tested the actual chat with:

Guide me through a 5-minute mindful meditation.

The browser successfully streamed the response.

The application produced the expected answer, including the guided practice and knowledge sources.

The logs now showed:

ai_stream_selected
stream_path = ai_sdk_openrouter

stream_started

stream_first_text
firstDeltaMs = 10568

The response was then persisted:

conversation_save:
~472 ms

usage persistence:
~166 ms

And the request completed with:

stream_finished

POST /api/ai/chat 200 in 18584ms

Just as important, the old streaming failure events were gone.

There was no:

openrouter_stream_unexpected_eof

No:

openrouter_stream_error

And the browser didn't show the disconnect message.

That gave me the first proper end-to-end confirmation that the new path was working.

But it's still too slow

This is where I want to be careful about the conclusion.

The streaming problem is fixed.

The performance problem isn't.

The successful request took approximately:

First text: ~10.568s
Total request: ~18.584s

That's still too much waiting before the user sees the first useful text.

I don't want to hide that behind a nicer loading animation.

The next question is:

Why is the first text taking around 10.5 seconds?

That's now a performance investigation rather than a streaming correctness problem.

I'm looking at things such as:

Model reasoning configuration
OpenRouter/provider routing
Prompt size
Conversation history size
Retrieved context size
Duplicated instructions/context
Work happening before the provider call
AI SDK/provider configuration

The model remains:

openai/gpt-5-mini

I'm not planning to switch models just because another model might produce a nicer benchmark.

First I want to understand where the time is actually going.

What I learned from this

The biggest lesson wasn't that I should always use the AI SDK.

It's this:

If a mature library already handles a difficult infrastructure problem, think twice before rebuilding that responsibility yourself.

The application still needs to own plenty of things.

For example:

Authentication
Permissions
Quota
Rate limiting
Knowledge retrieval
Source filtering
Conversation persistence
Business rules
Observability

Those are application concerns.

The model streaming abstraction doesn't need to know how the application's quota works or where its knowledge comes from.

Likewise, the application doesn't need to understand every detail of the provider's streaming protocol.

That separation makes the system easier to reason about.

Another lesson: don't change everything at once

One thing I'm glad I didn't do was rewrite the entire streaming system in one go.

The frontend already had a working NDJSON contract.

So I kept it temporarily.

That gave me a smaller change:

Old provider streaming
        ↓
New AI SDK provider streaming
        ↓
Existing browser contract

Once that worked, I had a known-good baseline.

I can now replace the client transport separately.

This is especially useful when debugging systems with several moving parts.

If you change the provider integration, API response format, client parser and UI state management at the same time, a successful result doesn't tell you much about which change actually mattered.

Smaller changes give you better evidence.

Working and fast are two different problems

This distinction is probably the most useful thing I'll carry forward from this work.

The first successful test answered:

Does the stream work?

Yes.

It did not answer:

Is the stream fast enough?

Not yet.

Those are different engineering problems.

The next stage is to measure time to first text, completion time and the work happening before the provider request.

I also want better request-level observability around:

request ID
stream start
first text
completion
abort
failure
latency

That should make the next performance investigation much less dependent on guesswork.

What's next

There are a few things I want to improve from here.

First, I want to understand the roughly 10-second first-text delay.

Then I'll look at the prompt, conversation history and retrieved context sizes, along with the model and provider configuration.

On the frontend, I eventually want to remove the custom NDJSON transport and move to the AI SDK React transport rather than maintaining our own client-side streaming state machine.

There is also UX work to do.

The current chat works, but the preparing/generating state still needs improvement. I'd like it to feel more natural while the application is waiting for the first response, without turning the interface into a collection of animations.

But that's separate from the architecture fix.

For now, the important part is that the stream itself is working again.

The part I'd change if I built it again

I wouldn't start with a pile of streaming infrastructure.

I'd first decide which layer should own the stream.

For this application, that means keeping the responsibilities roughly separated:

Application
→ auth, quota, retrieval, persistence, business rules

AI SDK
→ model streaming and stream lifecycle

Provider
→ OpenRouter/model communication

UI
→ displaying and interacting with the response

The mistake wasn't writing custom code.

The mistake was allowing several layers to take responsibility for the same problem.

Once I removed that overlap, the system became much easier to understand.

And that's probably the part I'll remember from this debugging session:

Sometimes the useful architectural change isn't adding another layer.

It's deciding which layer doesn't need to be there.

The NGO App's AI Worked Locally. Then Vercel Gave Me a 504.

nishchal singh — Wed, 09 Sep 2026 01:49:08 +0000

I was testing the AI assistant locally, and everything was working.

Then I deployed it.

I opened the production app and asked:

how start meditation. im a beginner

Instead of an answer, I got:

Unexpected token 'A', "An error o"... is not valid JSON

At first, I thought I had broken something in the frontend.

I hadn't.

The error was hiding the actual problem

I checked the browser Network tab.

The request was:

POST /api/ai/chat

and the response was:

504 Gateway Timeout

So the JSON error wasn't the actual problem. The frontend was trying to parse an error response as JSON, while the request itself had already timed out.

That changed my debugging path.

Instead of looking at the JSON parser, I needed to find out why the server request was timing out.

But it worked locally

This was the confusing part.

The same AI request worked on my local machine.

The local terminal showed:

POST /api/ai/chat 200 in 21994ms

The logs showed:

AI context retrieved
model: openai/gpt-5-mini

The AI completion itself took around 17.76 seconds.

The usage was:

promptTokens: 1663
completionTokens: 1500
totalTokens: 3163
finishReason: "length"

So the complete local request was taking roughly 22 seconds, but it still succeeded.

That was an important clue.

The model wasn't simply broken.

OpenRouter wasn't obviously unreachable.

The application could make the request and receive a response.

Something was different in production.

Vercel gave me the useful error

I checked the Vercel production logs.

This time, the error was much more useful:

FUNCTION_INVOCATION_TIMEOUT

And there was a number that immediately stood out:

Execution Duration / Maximum
10.37s / 10s

The logs also showed that parts of the request had already completed:

Clerk authentication succeeded
AI context retrieval succeeded
POST request to OpenRouter was made
AI completion did not return before the function was terminated

So the function wasn't failing immediately.

It was running out of time while waiting for the AI completion.

That explained the 504.

Where was that 10-second limit coming from?

I checked the repository first.

There was no:

vercel.json

There was no route-level:

maxDuration

There was no runtime override.

And there wasn't a Next.js configuration setting a 10-second function duration.

So I hadn't configured this timeout in the application code.

I checked the Vercel project settings next.

That's where I found it.

Fluid Compute was disabled.

Screenshot: Vercel Functions settings showing Fluid Compute disabled

That was the missing piece.

The fix

I enabled Fluid Compute in the Vercel project settings and redeployed the application.

After the redeployment, the execution numbers changed from:

10.37s / 10s

to:

26.31s / 5m

The AI request could now finish.

The browser displayed the generated response instead of the 504.

The production logs also showed the rest of the request completing:

conversation_save_start
conversation_save_end
usage_persist_start
usage_persist_end
ai_chat_request_end

The application recorded:

totalElapsedMs: 25384

Vercel reported approximately:

26.31s

And the API returned:

Screenshot: successful production request / Vercel execution metrics

So the first production problem was fixed.

One important clarification

I don't want to turn this into the wrong Vercel lesson.

I'm not saying:

"Vercel cannot run AI functions longer than 10 seconds."

That's not what I observed.

What I observed was that this deployment was running with a 10-second maximum while Fluid Compute was disabled.

After enabling Fluid Compute and redeploying, the same function was allowed to run for up to 5 minutes, and the request completed.

The fix wasn't making OpenRouter faster.

It removed the execution limit that was killing the request before the AI response could return.

But then I noticed something else

The 504 was gone.

The AI was working in production.

So I could have stopped there.

But the successful request was still taking around 25–26 seconds.

The local request was around 22 seconds.

So fixing one problem exposed another one.

I don't know the cause yet, and I don't want to guess.

Instead, I added temporary timing logs around different parts of the request:

authentication
rate limiting
quota reservation
database connection
conversation lookup/create
AI context retrieval
OpenRouter request start
OpenRouter response headers
OpenRouter full response
conversation save
usage persistence
total request duration

Now I'm measuring each part instead of assuming where the time is going.

That's the next problem.

What I learned from this

Don't trust the first error

The browser showed a JSON parsing error.

The actual problem was a 504.

The Network tab gave me the next clue.

Local success doesn't guarantee production success

Locally, the request took around 22 seconds and worked.

Production was terminating it after 10 seconds.

The application code wasn't the only thing that mattered. The execution environment mattered too.

Check the platform before changing your code

There was no 10-second timeout configured in my repository.

The useful information was in the Vercel runtime logs and project settings.

Don't immediately blame the AI provider

The request reached OpenRouter, and the same model worked locally.

There wasn't enough evidence to blame the provider.

Don't blindly increase timeouts

First find out which layer is timing out.

In this case, the function itself was being terminated before the AI completion could return.

Measure again after every fix

Enabling Fluid Compute fixed the 504.

It also made the next problem visible:

Why is the request still taking ~25 seconds?

Measure first. Change second.

That's probably the simplest way I can describe this debugging session.

I started with a strange frontend error.

Then I checked the Network tab.

Then the production logs.

Then the repository configuration.

Then the Vercel project settings.

Each step removed another assumption.

Eventually, the 504 made sense.

The actual fix was only one setting.

Finding that setting was the debugging work.

The application is live here if you want to have a look:

https://www.pssmumbai.org/

Part 2: Why is the AI still taking ~25 seconds?

The timeout is fixed.

The request now completes successfully in production.

But waiting 25+ seconds for an AI response isn't something I want to leave alone.

So now I'm trying to find out where those seconds are actually going.

Is it the AI request?

Context retrieval?

Database work?

Something else?

I don't know yet.

That's what I'm measuring now.

Part 2 will be about finding that answer.

I Spent $5 on OpenRouter While Building AI Features for an NGO App

nishchal singh — Thu, 03 Sep 2026 13:01:15 +0000

I've been working on the PSS website for quite some time, and recently a lot of my work went into its AI features.

The application already handles sessions, events, staff, blog posts, gallery, testimonials, donations, settings, and an admin CMS.

For the AI work, I wanted two things:

PSS-specific information available to the user-facing AI
AI-assisted content creation inside the admin CMS

The stack is Next.js, React, TypeScript, MongoDB, Mongoose, Clerk, Cloudinary, Tailwind CSS, shadcn/ui, TanStack Query and OpenRouter.

During development, my OpenRouter dashboard reached about $4.99 in total spend.

The $5 isn't the interesting part.

What happened while building the features is.

Giving the AI PSS-specific knowledge

I didn't want the AI to answer PSS-related questions only from its general knowledge.

I needed information that the application could control and update.

So I built a knowledge flow around approved PSS content:

Approved PSS knowledge
        ↓
     Chunking
        ↓
    Embeddings
        ↓
     MongoDB
        ↓
Relevant knowledge retrieved
        ↓
    AI context
        ↓
 Response / content generation

The stored knowledge includes the content plus details such as its source, authority, status and visibility.

That also gives me a way to separate public knowledge from internal AI guidance and policies.

The idea I ended up using is simple:

The knowledge base decides what PSS teaches. The model decides how to communicate it.

That became much more important once I started checking the generated content.

AI inside the admin CMS

The admin CMS also has AI-assisted blog creation.

AI can help generate:

title/context
tags
SEO title
SEO description
excerpt
full article

I didn't want one button to generate an entire blog post from nothing.

For smaller fields, the admin can run individual AI actions. Full article generation is a separate flow.

The article generation can use the information already entered in the editor:

Title
Category
Tags
SEO title
SEO description
Excerpt
Writing instruction
Relevant PSS knowledge
        ↓
     AI model
        ↓
 Generated article
        ↓
   Article editor

This is much more useful than sending something generic like:

"Write a blog post about meditation."

The application already has context. The AI should use it.

The first problem: the article stopped halfway

My first full-article generation didn't finish.

The logs showed:

model: openai/gpt-5-mini
task: full_article
promptTokens: 1013
completionTokens: 1800
finishReason: length

The application reported:

AI generation reached the model's output limit.

I increased:

AI_CONTENT_MAX_TOKENS

from 1800 to 2000, and after testing again, the generation completed.

It was a small configuration issue, but it reminded me that an AI feature has limits that a normal API call doesn't have.

The request can succeed while the output is still incomplete.

The application needs to detect and handle that.

Then I found a bigger problem

The generated article looked good.

That was actually the problem.

When I compared it with the approved PSS knowledge, I found some contradictions.

The approved information included specific guidance around:

clasped/interlaced hands
closed eyes
natural breathing
avoiding breath manipulation
other PSS-specific meditation instructions

The generated article introduced more general meditation advice, including things like resting the hands in the lap or on the knees, allowing the eyes to remain open, and suggesting specific practice durations.

Those suggestions may sound reasonable for meditation in general.

But the website isn't publishing generic meditation advice.

It represents PSS.

So the output can be well written and still be wrong for the application.

That was the most useful thing I found during testing.

RAG became more than a search problem

Before this work, I mostly thought of retrieval as a way to give the model better information.

Now I also see it as a way to keep the application's content under control.

The embeddings help find relevant information, but the application still needs to know:

Is the information approved?
Is it public?
Where did it come from?
Who is the authority?
Is the document active?
Should this information be used for this AI workflow?

So it isn't simply:

documents → embeddings → model

There is an application around it.

The admin UI mattered too

Getting the backend generation working wasn't enough.

While using the admin workflow, I also found that the AI actions needed to behave like normal application features.

I worked on things such as:

clearer generation states
disabling relevant fields while generation is running
loading/progress feedback
better AI action buttons
separate actions for smaller fields
clearer error messages
keeping the writing instruction separate from generated content
putting generated content into the article editor

Adding AI doesn't remove normal UX problems.

It gives you a few more.

What did the $4.99 actually show?

My OpenRouter dashboard showed approximately:

Total spend: $4.99
Requests: ~1K
Token volume: 73.5M
Cache hit rate: 94.7%
Blended cost: $0.07 / 1M

The dashboard also showed usage from GPT-5.4, GPT-5 Mini and Text Embedding 3 Small.

One clarification: 73.5M is the token-volume metric shown by the dashboard. I wouldn't describe it as 73.5M tokens of generated text.

Most of this usage came from development, testing AI flows, model calls and embeddings.

The useful part wasn't getting a lot of AI work done for $5.

It was being able to see what experimentation actually costs.

The 94.7% cache hit rate also made me think more about repeated context and what these costs could look like with more traffic.

What I'm checking now

I'm trying not to judge an AI feature only by whether the API returns a successful response.

I also need to ask:

Does the generated content use the right knowledge?
Can it introduce unsupported information?
Can it contradict approved information?
What happens when the output limit is reached?
Does the UI clearly show that generation is running?
What happens when generation fails or hits a rate limit?
Should a person review generated content before publishing?

Some of these are things I've already encountered during development. Others are areas I still want to make more systematic with testing.

The AI system isn't finished.

What I'd do earlier next time

If I started this part of the project again, I'd think about the knowledge and failure cases earlier.

Not only:

Which model should I use?

But also:

What information should the AI use?

What information should it never use?

What happens when there is no relevant information?

What happens when the model doesn't finish?

How do I know the generated content is acceptable?

The model is only one part of the feature.

The rest is application engineering.

Final takeaway

The biggest thing I learned wasn't about a particular model.

It was that adding AI to an existing application means dealing with a lot more than an API call:

knowledge retrieval
embeddings
prompt context
content generation
token limits
model selection
caching
cost
admin UX
error handling
validation
testing
human review

The AI can generate a very good-looking article.

I still have to ask:

Is this actually what we want the application to say?

For this project, that question matters more than whether the model produced a polished paragraph.

You can see the application here:

https://www.pssmumbai.org/

If you're building AI into an existing application, I'd be interested to hear what surprised you after the first successful API response.

Why Your Nextjs UI Flickers: TanStack Query vs useEffect

nishchal singh — Wed, 13 May 2026 03:04:49 +0000

A page can load quickly and still feel unstable.

That usually happens when the initial render strategy is fine, but client-side data updates are handled poorly.

In this article, we’ll compare two common approaches:

A basic useEffect fetch
A production-ready pattern using TanStack Query

Both fetch the same API under the same network conditions.

One flickers.

The other stays smooth.

The Experiment

I built a small Next.js Rendering Lab to visualize:

SSR
CSR
SSG
ISR
Hydration
Cached background refetching
UI flicker caused by naive fetching

Both components:

call the same endpoint
refetch every few seconds
run under throttled network conditions
display live telemetry

Naive `useEffect` Fetching

A common pattern looks like this:

useEffect(() => {
  setLoading(true);

  fetch("/api/data")
    .then((res) => res.json())
    .then((data) => {
      setData(data);
      setLoading(false);
    });
}, []);

This works, but on every refetch:

loading state resets
content disappears
layout shifts
charts blink

The data may arrive quickly, but the interface feels unstable.

TanStack Query

TanStack Query handles updates differently.

It:

keeps previous data visible
fetches in the background
updates only changed values
avoids unnecessary loading states

The result is a much smoother experience.

Users continue seeing the existing UI while fresh data is being fetched.

Rendering Strategy vs Data Strategy

These are two separate concerns.

Rendering Strategy

Determines how the page initially loads.

Data Strategy

Determines how the UI behaves after hydration.

useEffect
TanStack Query
SWR
caching
background refetching

A page can be server-rendered and still flicker if data updates are handled poorly.

Why This Matters

This becomes obvious in:

dashboards
analytics tools
admin panels
live metrics
stock tickers
collaborative applications

Users may not understand hydration or caching, but they notice:

flicker
disappearing content
layout shifts
unstable interfaces

Good frontend UX is often about preserving visual stability.

Try the Rendering Lab

Live Demo:
Next.js Rendering Lab

Source Code:
GitHub Repository

Watch the YouTube Short

I also recorded a short visual comparison showing both patterns side by side under Slow 4G throttling.

Final Thoughts

The biggest lesson from this experiment:

Performance is not only about speed. It is also about stability.

Two apps can fetch data at almost the same speed but feel completely different depending on how updates are handled.

TanStack Query does not make your API faster.

It makes your UI behave better.

And users notice that immediately.

Why Date and Time Bugs Happen in JavaScript (And How Apps Actually Get It Right)

nishchal singh — Tue, 10 Feb 2026 11:46:37 +0000

If you’ve ever seen reminders fire early, late, or on the wrong day,

this post is for you.

I used to think date and time bugs were just edge cases.

They’re not.

Most of the time, they come from a slightly wrong mental model of how
time actually works in JavaScript. The problem only becomes visible
when an app starts dealing with real users, real schedules, and real
expectations.

This post explains why these bugs happen so often, how JavaScript really
handles date and time, and how production apps avoid them.

No heavy theory.
No library comparisons.
Just the parts that matter.

The illusion: “I used `Date()`, so time should be correct”

Most developers start with this:

new Date()

It prints a date and time that looks correct, so we assume everything
underneath is local and intuitive.

That assumption is where many bugs begin.

JavaScript dates are not stored as local time.

Internally, they are stored as:

Milliseconds since January 1, 1970 (UTC)

Local time, timezone, and formatting are applied only when the date is
read or displayed.

This sounds like a small detail.
In real apps, it isn’t.

What JavaScript is actually doing

A useful mental model is this:

JavaScript stores one number
That number represents a moment in UTC
Local time is calculated only at display or formatting time

For example:

new Date("2026-02-10T09:00:00")

This does not mean “9am in my timezone”.

It means “9am UTC, converted to the user’s local timezone”.

If your app does not control that context explicitly, time slowly drifts.

The three most common time mistakes

1. Assuming `Date()` is local internally

Date behaves like a local clock, but it is not one.

It is a UTC timestamp with a local view layered on top.

This becomes a problem when:

users are in different timezones
servers run in UTC
background jobs don’t share locale information

2. Mixing server time and client time

A very common pattern:

server schedules something
client displays or adjusts it
background job runs later

If these layers don’t agree on what “now” means, reminders drift.

This is especially dangerous for:

recurring schedules
weekly reminders
“tomorrow at 9am” logic

3. Generating dates without context

Any logic that generates dates needs to know:

today’s date
the user’s timezone
daylight saving rules

Without this context, it’s easy to generate reminders:

in the past
on the wrong day
in the wrong year

Why this gets worse in PWAs

These problems become much more visible in Progressive Web Apps.

Browsers are not designed to guarantee precise scheduling.
They optimize for:

battery life
performance
security

As a result:

background execution is delayed
service workers wake unpredictably
scheduled logic runs in time windows, not exact moments

I ran into this while building a productivity app where reminders and
check-ins were core features.

Notifications worked.
Nothing crashed.
But timing was unreliable.

I wrote about that experience here:

When Notifications Matter, PWAs Start to Show Their Limits

https://dev.to/nishchaldev/when-notifications-matter-pwas-start-to-show-their-limits-5ebl

That post explains where things broke.
This post explains why.

How mature apps avoid time bugs

Once I looked at how established reminder apps work, a clear pattern
emerged.

One clear definition of “now”

There is exactly one source of truth for current time:

based on the device timezone
or an explicit user setting

No guessing.
No hidden defaults.

Store in UTC, schedule in local time

This is the most important rule.

Store timestamps in UTC
Convert to local time for display
Schedule alarms using local context

This avoids:

daylight saving bugs
timezone drift
unexpected early or late triggers

Let the OS handle scheduling

On native platforms, reminders are scheduled using system services.

The operating system:

reschedules after reboots
adjusts for timezone changes
guarantees delivery timing

JavaScript logic does not need to stay alive.

The shift that fixed my app

After understanding these patterns, I changed the architecture:

the web app handles dashboards and planning
the native layer handles scheduling and notifications
the backend stores everything in UTC
time context is always explicit

The same product logic runs everywhere, but time-sensitive
responsibilities live where they belong.

The app is still evolving, but the difference is noticeable.

Live app:

https://wio-dev.vercel.app

A simple rule that helps

If you remember only one thing, remember this:

Time is not a utility. It’s a product feature.

If your app depends on time being correct:

model it deliberately
pass context explicitly
let the platform handle scheduling

Closing thought

JavaScript dates are not broken.
Browsers are not broken.

Most time bugs come from assumptions that feel reasonable until real
users and real schedules expose them.

Once your mental model matches how time actually works, things become
much simpler.

A question for you

Have you run into confusing date or timezone bugs?
How are you handling reminders or schedules today?
Did this explanation match what you’ve seen in practice?

I’d genuinely love to hear how others are dealing with this.

When notifications matter, PWAs start to show their limits

nishchal singh — Sat, 07 Feb 2026 08:37:57 +0000

I was getting notifications at 3am.

Users were confused.

I hadn’t changed anything.

That’s when I realized something uncomfortable:

PWAs don’t really understand time the way we expect them to.

Nothing was “broken” in the obvious sense.

Reminders worked. Notifications appeared. Logs looked fine.

But for a productivity app — where reminders and check-ins are the product —

“mostly works” isn’t good enough.

This post is about what went wrong, why it wasn’t actually a bug, and why I eventually stopped relying on a pure PWA setup for time-critical notifications.

When PWAs work great (and when they don’t)

If your app needs:

in-app banners
occasional push notifications
background sync when possible

PWAs are an excellent choice.

They’re fast to build, easy to ship, and good enough for many products.

But reminders are different.

A reminder isn’t just a notification.

It’s a promise about time.

And time is where PWAs start to show their limits.

How PWA notifications really behave

When a PWA is open:

JavaScript is running
the user’s local time is known
scheduling logic is predictable

Things feel solid.

The problems start once the app is closed or backgrounded.

At that point:

the browser decides when background work runs
service workers wake up only under certain conditions
push delivery is best-effort
timing happens in windows, not exact moments

A “scheduled” notification often looks like this:

a backend job checks reminder time
timezone logic runs on the server
a web push is sent
the browser decides when (or if) to wake the service worker
the OS eventually shows the notification

Each step makes sense on its own.

Together, they introduce uncertainty.

This isn’t bad engineering.

It’s how browsers are designed.

Browsers optimize for battery life, performance, and security —

not precise scheduling guarantees.

Where things actually broke for me

At first, I assumed this was just a PWA limitation.

Then I wrapped the app with a native Android container and refactored the notification flow.

Some issues still showed up.

That’s when it became clear:

Notification reliability isn’t just about platform choice.

It’s also about how your app understands time itself.

Looking at how mature reminder apps work made the gaps obvious.

What real reminder apps get right

Apps like Google Calendar, TickTick, and Any.do all follow the same principles.

One clear definition of “now”

There is a single authoritative source of current time —

based on device timezone or an explicit user setting.

No guessing.

No hidden defaults.

Store in UTC, schedule in local time

Events are stored in UTC.

They’re converted to local time only for display and scheduling.

This avoids slow, painful bugs around daylight saving and timezone changes.

OS-level scheduling

Reminders are scheduled using system services (for example, AlarmManager on Android).

They’re automatically rescheduled when:

the device restarts
the timezone changes
daylight saving rules shift

The OS owns delivery — not JavaScript.

No dates without context

Any AI planner or automation that generates dates is explicitly told:

“Today is YYYY-MM-DD in this timezone.”

Without this, it’s surprisingly easy to generate reminders in the past or wrong year without noticing.

The real issues in my app

Once I stepped back, the problems were surprisingly basic:

timezone defaulting to UTC instead of user locale
AI planner not receiving current date and timezone explicitly
weekly reminders drifting due to timezone conversion
limited control over notification channels and sounds

These aren’t exotic bugs.

They’re the kind that appear only after real users and real time collide.

Why Android behaves more predictably

On Android, the mental model is simpler:

the app schedules the reminder locally
the OS owns the timing
the notification fires when expected

Even if:

the app is closed
the process is killed
the device restarts

Notifications are first-class system features.

That’s why:

sound and vibration are consistent
notification channels behave correctly
widgets are possible
background behavior is predictable

This isn’t about Android being “better”.

It’s about using the platform for what it was designed to do.

The setup that finally made sense

For this app, reminders and check-ins aren’t optional.

They are the product.

So the architecture that aligned best was:

Web app (desktop)

dashboards
insights
planning and review

Android app (Capacitor wrapper)

native scheduling
OS-level notifications
background reliability

Same backend.

Same database.

Same product logic.

Different delivery mechanisms — matched to platform strengths.

A simple rule of thumb

If notifications are a nice-to-have → PWAs are usually fine
If notifications are a core promise → let the OS handle timing

That distinction would have saved me weeks.

Final thought

PWAs aren’t unreliable.

They’re just not designed to guarantee time.

Native platforms are.

Once you align product expectations with what a platform can realistically promise, a lot of confusion — and frustration — disappears.

Quick question for you

Have you faced random notification timings in PWAs?
How are you handling scheduled reminders today?
Would you still choose a PWA if notifications were critical?

I’m genuinely curious how others are solving this.

Live app (still evolving):

👉 https://wio-dev.vercel.app

Object Cloning in Javascript

nishchal singh — Fri, 01 Mar 2024 05:43:13 +0000

While coding in Javascript have you ever encountered a situation where you needed to copy an object? and when you try to copy an object, you face some issues like all of the properties are not cloned, or when changing the copied object somehow the original object is changed, leaving you without the desired results. Well, In this article we'll explore some simple solutions to these issues.

First thing that came to your mind is that why not simply use 🟰 to copy objects, but it'll not work b'coz Javascript objects are reference type values. worry not, there are 3 basic ways of object cloning:

const originalObject = { name: 'John', age: 30 };

// Using Spread Operator (...)
const spread_Cloned = { ...originalObject };

// Using Object.assign() Method
const assign_Cloned = Object.assign({}, originalObject);

// Using JSON.stringify() and JSON.parse() 
const cloned_JSON = JSON.parse(JSON.stringify(originalObject));

console.log(spread_Cloned); // { name: 'John', age: 30 }
console.log(assign_Cloned); // { name: 'John', age: 30 }
console.log(cloned_JSON); // { name: 'John', age: 30 }

Introduction

If you're dealing with tricky data setups, making exact copies, or just want to keep things from changing unexpectedly, copying objects can be super helpful in JavaScript. This article is all about diving into object cloning in JavaScript. We'll check out different ways to do it and figure out when and why it's important. By the time you finish reading, you'll totally get how to clone objects and be ready to use it in your own coding projects.

Shallow Clone vs Deep Clone

When you shallow clone something in JavaScript, you're basically making a copy that only goes skin-deep. It means you get a new object with the same basic stuff as the original, but if those basic things include other objects, those aren't copied – they're just referenced. Now, deep cloning is like making a photocopy of everything. You get a brand-new object where every little thing, even the stuff inside other stuff, gets copied over completely. So, you end up with a totally separate copy of everything from the original.

Techniques for Object Cloning

Using Spread Operator (...)

The spread operator in JavaScript is a concise and efficient way to clone objects. It allows us to create a copy of an object, including all its enumerable properties, into a new object.

const originalObject = { name: 'John', age: 30 };
const clonedObject = { ...originalObject };

console.log(clonedObject); // { name: 'John', age: 30 }

Advantages:

Very simple syntax
Supports cloning both Shallow and moderately nested objects

Limitations:

Cannot handle deeply nested objects
Does not clone non-enumerable properties or methods

Using Object.assign() Method

The Object.assign() method is another powerful technique to clone objects. It copies the values of all enumerable properties from one or more source objects into a target object, returning the target object.

const originalObject = { name: 'John', age: 30 };
const clonedObject = { ...originalObject };

console.log(clonedObject); // { name: 'John', age: 30 }

Advantages:

Handles cloning of non-enumerable properties and methods
Supports cloning moderately nested objects

Limitations:

Cannot clone deeply nested objects directly
Overwrites properties if they already exist in the target object

Using JSON.stringify() and JSON.parse()

The combination of JSON.stringify() and JSON.parse() methods can be used as a workaround for cloning complex objects. By converting the object to a JSON string and then parsing it back into an object, we can achieve a Deep Clone of the original object.

const originalObject = { name: 'John', age: 30 };
const clonedObject = JSON.parse(JSON.stringify(originalObject));

console.log(clonedObject); // { name: 'John', age: 30 }

Advantages:

Supports cloning deeply nested objects
Can be used to clone objects with circular references

Limitations:

Does not preserve non-enumerable properties or methods
May not preserve certain data types (e.g., dates, regular expressions) during cloning
.

Using Third-party Library

Lodash is a popular JavaScript utility library that provides a powerful method called cloneDeep() for object cloning. It performs a deep copy of the entire object hierarchy, ensuring accurate replication of the original object's structure.

const originalObject = { name: 'John', age: 30 };
const clonedObject = _.cloneDeep(originalObject);

console.log(clonedObject); // { name: 'John', age: 30 }

Advantages:

Can handle cloning of any level of object nesting
Preserves non-enumerable properties and methods

Limitations:

Adds a dependency on an external library (Lodash)
May have performance implications for large objects due to deep copying

If you don't want to use any third-party library, there is an alternate solution: using a custom deep cloning function we'll discuss it further in this article. Both have their advantages and limitations.

Shallow Cloning

Shallow cloning is the simplest form of object cloning. It creates a new object with the same top-level properties as the original object. However, if those properties are themselves objects, they are still references to the original objects. Shallow cloning is a quick and easy way to duplicate objects when there's no need to clone nested objects.

Shallow Clone Example:

const originalObject = {
  name: 'John',
  age: 25,
  hobbies: ['reading', 'swimming'],
};

const clonedObject = { ...originalObject };

In this example, the spread operator (...) creates a shallow clone of originalObject. Although clonedObject appears to be an identical copy, modifying the hobbies property in either object will affect both, as they still share a reference to the same array.

We can fix this issue by Deep Cloning.

Deep Cloning

Deep cloning is a more thorough form of object cloning. It creates a new object and recursively clones all nested properties and their descendants, ensuring each object is an independent copy. Deep cloning is indispensable when working with complex data structures and avoiding unintended side effects.

Using JSON.stringify() and JSON.parse():

//Deep Clone Using JSON.stringify() and JSON.parse()
const originalObject = {
  name: "John",
  age: 30,

  // Nested object
  address: {
    city: "New York",
    state: "NY",
  },

  // Method
  doAction: function () {
    console.log(this.name + " is walking in " + this.address.city);
  },
};
const clonedObject = JSON.parse(JSON.stringify(originalObject));

console.log(clonedObject);
 // { name: 'John', age: 30, address: { city: 'New York', state: 'NY' } }

As we can see in the above example we are losing our data, the method "doAction" is not cloned b'coz it does not preserve non-enumerable properties or methods. The solution for this issue is given below.

Using Custom Recursive Function:

// Deep Clone Using Custom Recursive Function
// Custom Recursive Function 
function deepClone(obj, visited = new WeakMap()) {
  // Handle non-object types and null
  if (obj === null || typeof obj !== 'object') {
    return obj;
  }

  // Handle circular references
  if (visited.has(obj)) {
    return visited.get(obj);
  }

  // Handle dates
  if (obj instanceof Date) {
    return new Date(obj.getTime());
  }

  // Handle regular expressions
  if (obj instanceof RegExp) {
    return new RegExp(obj);
  }

  // Handle arrays
  if (Array.isArray(obj)) {
    const cloneArray = [];
    visited.set(obj, cloneArray);
    obj.forEach((item, index) => {
      cloneArray[index] = deepClone(item, visited);
    });
    return cloneArray;
  }

  // Handle objects
  const cloneObj = {};
  visited.set(obj, cloneObj);
  for (let key in obj) {
    if (Object.prototype.hasOwnProperty.call(obj, key)) {
      cloneObj[key] = deepClone(obj[key], visited);
    }
  }
  return cloneObj;
}

const clonedObject = deepClone(originalObject);
console.log(clonedObject); /*{
  name: 'John',
  age: 30,
  address: { city: 'New York', state: 'NY' },
  doAction: [Function: doAction]
}*/

console.log(clonedObject.doAction()); // John is walking in New York

In this example, deepClone is a recursive function that clones all properties and nested objects of originalObject. The resulting clonedObject is a deep copy, ensuring no changes made to original one and no object will impact the other.

We use a WeakMap to keep track of visited objects to handle circular references.
We add support for cloning Date objects and RegExp objects.
We handle cloning of arrays and objects separately to ensure correct cloning and handling of circular references.
We use Object.prototype.hasOwnProperty.call(obj, key) to ensure that properties from the object's prototype chain are not mistakenly cloned.

This deepClone function can handle a wider range of data types and scenarios.

Let's see another example of 'deepClone' function with different data types:

// Define an object with various data types including arrays, objects, dates, and regular expressions
const originalObject = {
  string: "Hello",
  number: 123,
  boolean: true,
  array: [1, 2, 3],
  object: { a: 1, b: 2 },
  date: new Date(),
  regexp: /test/g,
};

// Add circular reference
originalObject.circular = originalObject;

// Clone the original object
const clonedObject = deepClone(originalObject);

// Modify the cloned object
clonedObject.string = "Modified";
clonedObject.number = 456;
clonedObject.array.push(4);
clonedObject.object.c = 3;

// Log both original and cloned objects
console.log("Original Object:", originalObject);
/*Original Object: <ref *1> {
  string: 'Hello',
  number: 123,
  boolean: true,
  array: [ 1, 2, 3 ],
  object: { a: 1, b: 2 },
  date: 2024-02-23T13:18:38.521Z,
  regexp: /test/g,
  circular: [Circular *1]
}*/
console.log("Cloned Object:", clonedObject);
/*Cloned Object: <ref *1> {
  string: 'Modified',
  number: 456,
  boolean: true,
  array: [ 1, 2, 3, 4 ],
  object: { a: 1, b: 2, c: 3 },
  date: 2024-02-23T13:18:38.521Z,
  regexp: /test/g,
  circular: [Circular *1]
}*/

in this example:

We define an originalObject containing various data types including arrays, objects, dates, and regular expressions.
We add a circular reference to the originalObject.
We then clone the originalObject using the deepClone function.
We modify some properties of the cloned object to demonstrate
that the original object remains unaffected by the modifications to the clone.
Finally, we log both the original and cloned objects to see the differences.

The deepClone function has several advantages and limitations:

Advantages:

Deep Cloning: The function can recursively clone nested objects and arrays, ensuring a deep copy of the original object.
Support for Various Data Types: It supports cloning of various data types including objects, arrays, dates, and regular expressions, making it versatile for different use cases.
Handling Circular References: It can handle circular references gracefully by keeping track of visited objects using a WeakMap, preventing infinite recursion.
Maintains Object Structure: It maintains the structure of the original object, including nested objects and arrays, ensuring the cloned object has the same structure.
Flexible and Customizable: It can be extended to support additional data types or custom cloning logic based on specific requirements.

Limitations:

Performance: Deep cloning can be computationally expensive, especially for large and deeply nested objects, potentially leading to performance issues.
Prototype Chain: It does not preserve the prototype chain of objects. Cloned objects will lose their original prototype chain and inherit from Object.prototype.
Non-Clonable Properties: Certain properties like non-enumerable properties or properties with getters/setters may not be cloned accurately.
External References: If the original object contains references to external resources or mutable shared state, the cloned object will still reference the same external resources, potentially leading to unintended side effects.
Memory Consumption: The use of a WeakMap for handling circular references may consume additional memory, especially for large datasets with many circular references.

Overall, while the deepClone function provides a robust solution for deep copying objects, it's important to be aware of its limitations and potential impact on performance and memory usage, especially in scenarios involving large or complex data structures.

Conclusion

Remember, when cloning objects, it's crucial to choose the appropriate method based on your specific needs. Whether you opt for native JavaScript techniques or leverage external libraries like Lodash or Immer, object cloning is a valuable tool for maintaining data integrity and preventing unintended side effects.

So, the next time you find yourself needing to duplicate an object in JavaScript, don't go down the path of manual copying and mutation. Instead, harness the power of object cloning and unlock a world of possibilities.

"Object cloning in JavaScript is the key to maintaining data integrity and avoiding unintended side effects."

Overview of ReactJs

nishchal singh — Tue, 12 Dec 2023 14:14:59 +0000

Whenever the development community talks about modern web development stacks, the word "ReactJS" is often mentioned. It's one of the widely used tech stacks for web development, In this article, we'll take an overview of ReactJS.

What is ReactJs?

ReactJS, or simply React, is like a superhero or supertool for building websites and web applications. It's a special set of tools and rules that helps people create websites that are not only really cool but also super fast and easy to work with.

React is a JavaScript-based front-end library used for UI(user interface) development. It's used to create modular user interfaces and promotes the development of reusable UI components that display dynamic data. React is often used to build single-page applications (SPAs).

Concept of ReactJS

his is Hashnode's homepage as we can see here a react application is made from independent components that together make a whole web application. The search bar in the top header is a reusable component. the same search bar component is used in the other sections of this app.

Key concepts and principles of ReactJS include:

Component-Based Architecture: React is built around the idea of breaking down user interfaces into reusable, self-contained components. These components can range from simple elements like buttons or form inputs to complex parts of the user interface like navigation bars or entire pages. By building UIs as components, development becomes modular, maintainable, and scalable.

Virtual DOM (Document Object Model): React introduced the concept of a Virtual DOM which is like a lightweight copy of the actual DOM. virtual DOM is an abstract representation of the actual DOM in the browser. When data in a React application changes, React doesn't directly manipulate the real DOM. Instead, it creates a virtual representation of the changes and efficiently updates only the parts of the real DOM that need to change. This approach minimizes browser reflows and enhances performance.

The image below is a visual representation of the concept of the virtual DOM:

Unidirectional Data Flow: React follows a unidirectional data flow, where data moves in one direction, usually from parent components to child components. Child components cannot send data back to their parent components. This design minimizes errors and gives us greater control over our code.

As shown in the diagram below, data can only flow from top to bottom:

Component Lifecycle: React components have a lifecycle that includes various methods such as componentDidMount, componentDidUpdate, and componentWillUnmount. These lifecycle methods allow developers to hook into different stages of a component's existence and perform actions like data fetching, DOM manipulation, or cleanup.

State in React: In ReactJS, "state" refers to a built-in feature that allows you to manage and store data within a component. State represents the internal data of a component that can change during the component's lifecycle, and when it does change, React will automatically re-render the component to reflect the updated state.

State acts as a storage space for data essential for a component's functioning. It's versatile, capable of holding different data types like numbers, strings, arrays, or objects. Unlike props, which are unchangeable and flow from parent to child components, state is changeable. Components have the power to modify their own state through React's setState method.

Reactivity: React encourages a reactive approach to UI development. When the state or props of a component change, React automatically re-renders the component to reflect those changes. This reactivity simplifies UI updates and ensures that the UI always matches the application's data.

State Management: React components can effectively handle their internal state using either the useState hook for functional components or class-based state for class components. These approaches allow components to store and update data within themselves.

For more intricate applications, developers often turn to state management libraries like Redux or Mobx. These libraries centralize and manage state across the entire application, making it easier to handle complex data interactions.

For instance, consider a web application with dynamic notification functionality. State management ensures that notifications can be added, removed, and displayed in real-time without the need for complex manual updates. Similarly, in an online shopping cart, managing the dynamic count of items and their state helps ensure a seamless and responsive user experience.

JSX (JavaScript XML): JSX, which stands for JavaScript XML, is a powerful feature in React. It's like a special language that React developers use to describe how a component should look. Imagine it as a blend of HTML and JavaScript that makes building user interfaces more intuitive.

With JSX, you can write your user interface code in a way that closely resembles HTML. This not only makes it easier to understand but also helps you visualize your UI components. However, under the hood, JSX gets converted into regular JavaScript using tools like Babel before it's shown in the browser.

One of the cool things about JSX is that you can embed JavaScript expressions within curly braces {}. This means you can include dynamic content, variables, and calculations right alongside your JSX code. It's a flexible way to create dynamic and interactive user interfaces in React.

import React from 'react';

function Greeting(props) {
  const name = props.name;
  const isLoggedIn = props.isLoggedIn;

  // Define a JavaScript function to conditionally render a greeting message
  function getGreeting(name) {
    if (isLoggedIn) {
      return <p>Hello, {name}!</p>;
    } else {
      return <p>Please log in.</p>;
    }
  }
  return (
    <div>
      {/* Embed JavaScript expression to render the greeting message */}
      {getGreeting(name)}
    </div>
  );
}
export default Greeting;

Community and Ecosystem: React has a vast and active community, resulting in a rich ecosystem of third-party libraries, tools, and extensions. These resources make it easier for developers to build feature-rich and performant applications.

How Does ReactJS Work?
ReactJS works by utilizing a component-based architecture to build user interfaces efficiently. It uses a Virtual DOM to optimize updates, enforces a unidirectional data flow for predictable behavior, and allows developers to define UI components using JSX, which is transpiled into JavaScript. React updates the actual DOM efficiently, making it ideal for creating dynamic and interactive web applications.

Conclusion
ReactJS stands as a powerful and pivotal force in modern web development. Its component-based architecture, Virtual DOM, and unidirectional data flow provide developers with a robust toolkit to create dynamic and responsive user interfaces. React's flexibility, combined with a thriving community and extensive ecosystem, makes it a top choice for building web applications that are not only efficient and maintainable but also user-friendly. As we've explored in this overview, ReactJS empowers developers to bring their web projects to life with elegance and precision, setting new standards for web development in the digital age. Whether you're a seasoned developer or just beginning your journey, ReactJS remains a technology worth exploring and mastering.

DEV Community: nishchal singh

I Built AI Streaming With Too Many Layers. Here’s What Broke

The setup

The streaming setup I had built

Then production failed

The Vercel timeout

Fixing the timeout didn't fix the request

The strange part: OpenRouter returned 200

Instead of patching the parser, I made a smaller test

The actual architectural problem

The change: one authoritative streaming path

I didn't change the frontend at the same time

The first successful end-to-end test

But it's still too slow

What I learned from this

Another lesson: don't change everything at once

Working and fast are two different problems

What's next

The part I'd change if I built it again

The NGO App's AI Worked Locally. Then Vercel Gave Me a 504.

The error was hiding the actual problem

But it worked locally

Vercel gave me the useful error

Where was that 10-second limit coming from?

The fix

One important clarification

But then I noticed something else

What I learned from this

Don't trust the first error

Local success doesn't guarantee production success

Check the platform before changing your code

Don't immediately blame the AI provider

Don't blindly increase timeouts

Measure again after every fix

Measure first. Change second.

Part 2: Why is the AI still taking ~25 seconds?

I Spent $5 on OpenRouter While Building AI Features for an NGO App

Giving the AI PSS-specific knowledge

AI inside the admin CMS

The first problem: the article stopped halfway

Then I found a bigger problem

RAG became more than a search problem

The admin UI mattered too

What did the $4.99 actually show?

What I'm checking now

What I'd do earlier next time

Final takeaway

Why Your Nextjs UI Flickers: TanStack Query vs useEffect

The Experiment

Naive useEffect Fetching

TanStack Query

Rendering Strategy vs Data Strategy

Rendering Strategy

Data Strategy

Why This Matters

Try the Rendering Lab

Watch the YouTube Short

Final Thoughts

Why Date and Time Bugs Happen in JavaScript (And How Apps Actually Get It Right)

If you’ve ever seen reminders fire early, late, or on the wrong day,

The illusion: “I used Date(), so time should be correct”

What JavaScript is actually doing

The three most common time mistakes

1. Assuming Date() is local internally

2. Mixing server time and client time

3. Generating dates without context

Why this gets worse in PWAs

How mature apps avoid time bugs

One clear definition of “now”

Store in UTC, schedule in local time

Let the OS handle scheduling

The shift that fixed my app

A simple rule that helps

Closing thought

A question for you

When notifications matter, PWAs start to show their limits

I was getting notifications at 3am.

When PWAs work great (and when they don’t)

How PWA notifications really behave

Where things actually broke for me

Naive `useEffect` Fetching

The illusion: “I used `Date()`, so time should be correct”

1. Assuming `Date()` is local internally