DEV Community: AbhiJsDev

Beyond Basic RAG: The Ultimate Guide to Vector, Vectorless, and Hybrid AI Architectures

AbhiJsDev — Sun, 19 Jul 2026 13:03:19 +0000

As developers, we’ve all experienced the magic of watching a Large Language Model (LLM) stream a human-like response in real time. But the moment you ask it about something outside its training data—like your company’s private travel policy, real-time inventory, or yesterday’s news—the magic fades.

Left to its own devices, a standard LLM won't say, "I don't know." Instead, it will confidently invent a highly convincing lie.

Your first instinct might be to jam all your data straight into the system prompt. While modern context windows are scaling massively, loading an entire knowledge base into a prompt introduces a mountain of problems:

The Cost Bottleneck: Processing hundreds of thousands of tokens for every single query leads to astronomical API bills.
The "Lost in the Middle" Phenomenon: LLMs suffer from positional bias. Their retrieval accuracy drops by 20% to 40% when the answer is buried deep within the center of an enormous prompt.
Context Window Poisoning: Flooding a model with uncurated raw data introduces noise, causing the model to lose track of explicit system instructions.

To solve this, the engineering community fell in love with Retrieval-Augmented Generation (RAG). Instead of forcing a model to rely purely on memorization, RAG gives the model an "open-book exam."

1. What is RAG & How Does It Work?

Retrieval-Augmented Generation (RAG) is an AI framework that enhances LLMs by fetching relevant facts from external data sources before generating a response.

Think of it like trying to find information across 20 heavy PDF files:

You scan the titles and reject the files that clearly don't apply.
You check the contents page of the remaining files to isolate the correct chapter.
You jump straight to that page, read the text, and synthesize your answer.

A basic RAG pipeline automates this process using two primary workflows:

The Indexing Pipeline (Offline)

Chunking: Large documents are broken down into smaller textual segments called chunks (typically 200 to 500 words).
Embeddings: These chunks pass through an embedding model, turning text strings into high-dimensional numerical vectors (e.g., "Hello" ──► [12, 0, 345, 67]) representing semantic meaning.
Vector DB Storage: These mathematical vectors are stored in specialized vector databases (like Qdrant, Pinecone, or Chroma) alongside their raw text metadata.

The Querying Pipeline (Online)

[ User Query ] ──► [ Convert to Embedding Vector ] ──► [ Vector DB Search ]
                                                             │
                                                             ▼ (Context Found)
[ Grounded Answer ] ◄── [ LLM Brain ] ◄── [ Augment Prompt with Chunks ]

Visual 1: The standard architecture flow of an online RAG pipeline.

When a user types a prompt, the system converts the question into a vector, runs a similarity search across the vector database to locate contextually matching chunks, sticks those chunks directly into the prompt payload, and lets the LLM read them to write a grounded answer.

2. Where Traditional RAG Shines

When properly configured, standard vector-based RAG is the gold standard for applications dealing with static, document-grounded text retrieval:

Document Q&A: Interacting directly with uploaded user manuals, financial statements, or academic research papers.
Enterprise Knowledge Bases: Allowing employees to seamlessly search across vast, internal company wikis and HR policies.
Customer Support Automation: Grounding customer chatbots strictly in official product documentation to protect companies from AI liability.

3. The Breakdown: Why Traditional RAG Fails in Production

On paper, RAG looks flawless. In production, it can be incredibly fragile. Having an open textbook during an exam helps, but if someone hands you the wrong page, or if you misread the paragraph, you will still write down the wrong answer.

Most real-world RAG failures stem from systemic data preparation and retrieval issues long before the prompt ever reaches the LLM.

A. Poor Retrieval and Missing Context

If the retrieval stage skips or misses the exact chunk containing the necessary information, the LLM is left guessing.

👍 GOOD RETRIEVAL:
User: "What are our cancellation charges?"
  └──► DB Searches for "cancellation charges"
  └──► Vector match finds: "Termination Policy: Fees apply..."
  └──► LLM reads text and outputs accurate answer.

👎 POOR RETRIEVAL:
User: "What are our cancellation charges?"
  └──► DB Searches for "cancellation charges" (Document uses the term "termination fees")
  └──► Weak similarity matching fails ──► Returns unrelated "General Account Info" chunks
  └──► LLM guesses blindly or says "Information not found."

Visual 2: How semantic retrieval quality directly dictates the accuracy of the final answer.

B. Poor Chunking & Semantic Fragmentation

Splitting a document into pieces requires a careful balance. If you use "naive chunking" (splitting text at rigid, fixed character counts), you run the risk of cutting a critical sentence or mathematical concept precisely in half.

❌ RIGID CHARACTER CHUNKING CUTS PARAGRAPHS MID-THOUGHT:
┌────────────────────────────────────────────────────────────────────────┐
│ [Chunk 1]: "Refunds are fully allowed within a window of 30 days..."   │
└───────────────────────────────────┬────────────────────────────────────┘
                                    ✂️ (Context Fragmented)
┌───────────────────────────────────▼────────────────────────────────────┐
│ [Chunk 2]: "...unless the item was purchased during a clearance sale." │
└────────────────────────────────────────────────────────────────────────┘

Visual 3: When an exception clause is structurally isolated, the meaning of the data is compromised.

If a user asks about returning a clearance item, the database might only retrieve Chunk 1. The LLM, completely missing the critical exception clause in Chunk 2, will confidently serve an incorrect answer.

C. The Illusion of Massive Context Windows

As we move through 2026, state-of-the-art flagship models boast staggering context limits handling upwards of 1.5 million tokens. This has led some developers to make an entry-level assumption: "Why build a complex RAG database? Let's just dump our entire 800-page manual right into the prompt context window!"

This approach hits a physical wall:

[ 1,500,000 Token Document Dump ] ──► [ Stuffed Prompt Context Window ]
                                             │
              ┌──────────────────────────────┴──────────────────────────────┐
              ▼                                                             ▼
    ⚠️ Extreme API Costs & Latency               📉 Factual Retrieval Drops 20-40%
 (Transformer mechanism scales quadratically)     ("Lost in the Middle" positional bias)

Visual 4: The heavy performance penalties of overloading large context windows.

D. Hallucinations Are Not Fully Eliminated

An LLM is a probabilistic word predictor, not a database query engine. RAG provides relevant context, but it doesn't force the model to copy it exactly.

The Friend Analogy: Imagine helping a friend during an open-book exam by handing them a textbook page that explicitly states: "The museum is open Monday to Friday, 9 AM to 5 PM." Your friend reads it but summarizes: "The museum is open every day from 9 AM to 5 PM."
The textbook was correct, the right page was fetched, but the final answer is still wrong because your friend injected outside assumptions. LLMs do this constantly when combining mismatched chunks or defaulting back to their original pre-trained biases.

E. Stale Knowledge Bases

RAG is only as good as the data embedded in it. If a company changes a pricing rule or an HR policy at 2:00 PM, but your RAG database relies on traditional nightly batch re-indexing, your AI will spend the remaining ten hours confidently serving outdated, incorrect information to your users.

4. The Next Evolution: Vectorless RAG (The Tree Approach)

To completely bypass the issues of rigid chunk boundaries and "vibe-based" vector similarity math, engineers developed Vectorless RAG. Instead of vectors and vector databases, this architecture organizes data logically using hierarchical tree structures.

                        [ Root: Full Story / Dataset ]
                                       │
                  ┌────────────────────┴────────────────────┐
                  ▼                                         ▼
      [ Heading Node: Part 1 ]                  [ Heading Node: Part 2 ]
                  │                                         │
         ┌────────┴────────┐                       ┌────────┴────────┐
         ▼                 ▼                       ▼                 ▼
   [Sub-Topic Node]  [Sub-Topic Node]        [Sub-Topic Node]  [Sub-Topic Node]

Visual 5: A hierarchical node tree structure mapping themes instead of vector coordinates.

Indexing Phase: Raw documents are analyzed by a high-end reasoning LLM to extract logical headings, themes, and conceptual structures, mapping them into an interconnected tree of text nodes stored in a traditional database.
Querying Phase: When a user asks a question, a reasoning model analyzes the user's intent and performs a Tree Traversal (navigating down the relevant conceptual branches), retrieving the exact text blocks required without looking at mathematical coordinate spaces.

Problems Vectorless RAG Solves

Zero Data Loss: It eliminates rigid character limits, keeping context completely intact within logical headings.
Reasoned Search: It uses language models to understand the true structural intent of a query, outperforming traditional vector lookups which can easily pull the wrong text if a user's phrasing doesn't match the database's "vibe."

Limitations of Vectorless RAG

Higher Costs & Latency: Navigating a tree structure requires multiple sequential LLM reasoning calls, which takes more time and tokens than a direct database lookup.
Unstructured Data Struggles: If your raw source data is a chaotic, messy dump of unorganized notes, an LLM cannot reliably generate a clean hierarchical tree layout.

5. The Ultimate Balance: Hybrid RAG

Because Vector RAG is fast and cost-effective, while Vectorless RAG is highly precise and logical, production-grade applications are converging on Hybrid RAG.

Hybrid RAG integrates multiple search strategies simultaneously—such as pairing Semantic Vector Search (to capture conceptual meaning) with traditional Keyword Search (BM25) (to capture exact technical codes, serial numbers, or product SKUs).

                     [ User Complex Query ]
                               │
               ┌───────────────┴───────────────┐
               ▼                               ▼
     ┌───────────────────┐           ┌───────────────────┐
     │  Vector Search    │           │  Keyword Search   │
     │  (Semantic Vibe)  │           │   (Exact Terms)   │
     └─────────┬─────────┘           └─────────┬─────────┘
               │                               │
               └───────────────┬───────────────┘
                               ▼
                    ┌─────────────────────┐
                    │  Fusion & Reranking │ 🔄 (Merges & reorders chunks via relevance)
                    └──────────┬──────────┘
                               ▼
                    ┌─────────────────────┐
                    │  LLM Context Window │
                    └──────────┬──────────┘
                               ▼
                    [ Precise Grounded Resp ]

Visual 6: The comprehensive workflow of a modern Hybrid RAG architecture.

How Hybrid RAG Works

Parallel Retrieval: The user's query triggers a semantic vector search and a keyword-based search at the same time to ensure no critical structural data is dropped.
Fusion & Re-ranking: Because different retrieval strategies return overlapping, noisy results, a specialized Reranker model analyzes the combined text pool, filters out duplicates, and reorders the chunks by exact contextual relevance.
Generation: The LLM receives a highly curated, ultra-dense payload of perfect context, resulting in fast, low-cost, and completely grounded answers.

6. Knowing When to Walk Away: When RAG is the Wrong Solution

RAG is an incredible architecture, but it is frequently applied to problems it was never built to solve. Introducing a RAG pipeline adds significant infrastructure complexity, so you should avoid it if:

The Task Requires Mathematical Precision: Vector search is approximate. If a user asks, "Sum up all open invoices," RAG might fetch documents about invoices, but it cannot calculate math. Use Function Calling (Text-to-SQL) to let the AI query a structured relational database directly for deterministic precision.
You Need Behavioral Tone Consistency: RAG provides facts; it doesn't change how a model thinks or formats code. If your app is failing because the AI changes its personality or struggles to output perfect JSON formatting, you need Fine-Tuning to bake behavioral constraints directly into the model's weights.
Your Knowledge Base is Small and Static: If your entire corporate playbook or manual fits within less than 50 or 100 pages, constructing a vector database infrastructure is over-engineering. Use full-context prompting along with platform Prompt Caching—it will be faster, cheaper, and fundamentally more accurate.

Summary: Designing with Trade-offs

┌─────────────────────────────────────────────────────────────────────────┐
│                           RAG ARCHITECTURE CHEAT SHEET                  │
├────────────────────────────────────┬────────────────────────────────────┤
│            USE RAG WHEN            │            AVOID RAG WHEN          │
├────────────────────────────────────┼────────────────────────────────────┤
│ • Data shifts/updates frequently   │ • Task requires pure math/logic    │
│ • Documents are vast or private    │ • Dataset fits within 50-100 pages │
│ • Factual attribution is critical  │ • Goal is altering structural tone │
└────────────────────────────────────┴────────────────────────────────────┘

Moving an AI feature past a basic prototype requires shifting your focus away from creative prompt engineering hacks and moving it squarely toward robust data engineering. Your application's final accuracy will always be defined by how cleanly you slice your data, how quickly you update your index, and how strategically you retrieve your context.

If you are currently expanding an AI feature into production, what chunking tools or database patterns have given your team the best results? Let’s talk shop in the comments below!

Behind the AI Chatbox: What Actually Happens When You Send a Prompt?

AbhiJsDev — Wed, 01 Jul 2026 15:10:44 +0000

Most of my day as a developer is spent crafting UI components, managing state, and making sure web interfaces look pixel-perfect and accessible. But recently, a new layer has been added to almost every app we build: the AI chatbox.

You type a prompt, hit Send, and a magical, human-like response streams onto your screen. But if you look under the hood, it's not magic at all. It's a beautifully orchestrated system of mathematics, probabilities, and predictions.

Let's lift the curtain on what's actually happening behind that glowing screen—without the dry, intimidating jargon.

1. Demystifying the Buzzword: What is an LLM?

Before we follow your message's journey, let's meet the engine powering everything.

LLM stands for Large Language Model.

At its core, an LLM is a deep learning model trained on enormous amounts of text, allowing it to understand and generate human language with remarkable fluency.

What Problems Do LLMs Solve?

Historically, computers struggled with human language.

Traditional software relies on explicit rules. If you misspelled a word, used slang, or phrased something differently than expected, the program often failed because it could only follow predefined instructions.

LLMs changed that completely.

Instead of relying solely on rigid rules, they learn patterns from massive amounts of text, enabling them to understand unstructured human language—the messy, flexible, and often ambiguous way people naturally communicate.

Rather than matching exact keywords, they infer the intent behind your words.

Popular Examples

Some of today's most widely used LLMs include:

OpenAI's GPT models (used in ChatGPT)
Google Gemini
Anthropic Claude
Meta Llama

Where You Already Use Them

You probably interact with LLMs every day without even realizing it.

They power:

Smart autocomplete
AI coding assistants
Language translation
Email drafting
Customer support chatbots
Document summarization
AI search experiences

2. Why Computers Are Completely Text-Blind

Before understanding how an LLM thinks, we need to understand one strange fact:

Computers have absolutely no idea what letters like A, B, or C actually mean.

Computers don't understand English.

They don't understand Hindi.

They don't understand any human language.

They only understand numbers.

If you handed the word:

Hello

to your computer's processor, it wouldn't recognize it as a greeting.

To the computer, it's simply a collection of characters with no inherent meaning.

Before an AI can process your message, every piece of text must first be transformed into numbers.

That journey begins with Tokenization.

3. The Journey of Your Prompt

Your Prompt
      │
      ▼
Tokenization
      │
      ▼
Embeddings + Positional Encoding
      │
      ▼
Transformer (Self-Attention)
      │
      ▼
Next Token Prediction
      │
      ▼
Streaming Response

Let's walk through what happens during each step.

Step 1 — Typing a Prompt

Everything begins when you type something like:

Give me a recipe for a quick snack.

After clicking Send, the application (such as ChatGPT) securely sends your prompt over the internet to an LLM running on powerful cloud servers.

Only then does the model begin processing your request.

Step 2 — The Slicer (Tokenization)

The first thing an LLM does is slice your text into manageable pieces called tokens.

Words vs Tokens

A token isn't always a complete word.

Depending on the tokenizer, it can represent:

A full word
Part of a word
Punctuation
Whitespace
Emojis
Numbers

For example:

Input

Hello, I like coding.

Tokens

["Hello", ",", " I", " like", " cod", "ing", "."]

Token IDs

[15496, 11, 314, 588, 3842, 278, 13]

Every token receives a unique numeric identifier.

These numbers—not the original words—are what the model actually processes.

Breaking language into standardized tokens allows the model to efficiently process millions of words every second.

Step 3 — The Map of Meaning (Embeddings & Positional Encoding)

Now that the text has become numbers, the AI still doesn't know what those numbers mean.

To solve this, every token is converted into an embedding—a high-dimensional mathematical representation that captures semantic meaning.

Imagine a Giant Map

Words and concepts with similar meanings naturally appear close together.

Apple  ───────── Banana

Paris ───────── Eiffel Tower

Doctor ──────── Hospital

The closer two words appear in this embedding space, the more semantically related they are.

This allows the model to recognize relationships without anyone explicitly programming them.

Figure 1: Imagine a sentence being broken into tokens and projected into a massive semantic space. Words like "Feast", "Gathering", and "Everyone" naturally cluster together, while concepts such as "Ideas" drift closer to "Creativity." Rather than memorizing definitions, the model learns relationships between concepts.

But Word Order Matters

Consider these two sentences:

The cat chased the mouse.
The mouse chased the cat.

They contain exactly the same words.

Yet they mean completely different things.

To preserve order, every token receives additional positional information called Positional Encoding.

This tells the model where each token appears in the sentence.

Without positional encoding, the model would know which words exist—but not where they occur.

Step 4 — The Context Detective (The Transformer)

This is the crown jewel of modern AI.

The Transformer architecture, introduced in 2017, completely changed natural language processing.

Older AI models processed text sequentially.

I → sat → on → the → river → bank

By the time they reached the last word, they often struggled to remember important information from the beginning.

Transformers solved this problem using Self-Attention.

Instead of reading one word after another, every token can examine every other token simultaneously.

Understanding Self-Attention

Consider the word:

Bank

Sentence 1:

I sat on the river bank.

The nearby word river tells the model that "bank" refers to land beside water.

Sentence 2:

I deposited money in the bank.

Now the nearby word money changes the meaning entirely.

The model understands that the same word has different meanings depending on surrounding context.

This contextual understanding is made possible through Self-Attention.

Old AI vs Transformer

Old AI (Sequential)

[I] → [sat] → [on] → [the] → [river] → [bank]

Reads one word at a time.


Transformer (Parallel)

[I]
[sat]
[on]
[the]
[river]
[bank]

Every token attends to every other token simultaneously.

Instead of forgetting earlier words, every token continuously considers the entire sentence.

Figure 2: Compare an older sequential model reading one word after another with a Transformer where every token connects to every other token through Self-Attention. The illustration should highlight how the meaning of the word "Bank" changes depending on whether it connects more strongly to "River" or "Money."

Step 5 — Generating a Response (It's Not Copying Google)

One of the biggest misconceptions about ChatGPT is that it searches Google and copies an answer.

That's not how it works.

Instead, once the Transformer understands your prompt, it predicts the most likely next token.

Think of it as an incredibly advanced autocomplete system.

Suppose your prompt is:

The capital of France is

Internally, the model estimates probabilities similar to:

Paris      97%

London      1%

Berlin      1%

Rome        1%

It selects one token.

Now the sentence becomes:

The capital of France is Paris

The entire process repeats.

Again.

And again.

Hundreds of times every second.

Each newly generated token becomes part of the context used to predict the next one, allowing the model to produce completely new responses instead of copying existing text.

4. The "Creativity" Dial — Temperature

Have you ever asked the exact same prompt twice and received different answers?

That's because of a parameter called Temperature.

LOW TEMPERATURE (0.2)

✔ Predictable
✔ Consistent
✔ Factual
✔ Great for coding


HIGH TEMPERATURE (0.9)

✔ Creative
✔ Diverse
✔ Imaginative
✔ Better for brainstorming

Low Temperature

The model strongly favors the highest-probability token.

Best suited for:

Coding
Mathematics
Technical documentation
Structured content

High Temperature

The model becomes more adventurous.

Instead of always choosing the highest-probability token, it occasionally selects lower-probability alternatives, producing more diverse and creative outputs.

Ideal for:

Brainstorming
Story writing
Poetry
Creative marketing
Idea generation

5. The Context Window

Think of the Context Window as the AI's short-term memory.

    Older Messages (Forgotten)

                │

                ▼

──────────────────────────────────────────────

        Current Conversation

         Your Latest Prompt

──────────────────────────────────────────────

                │

                ▼

               LLM

The model can only "remember" a limited number of tokens at once.

As conversations become longer, older messages eventually fall outside this window.

Once that happens, the model no longer has access to them, which is why it may appear to forget earlier parts of the conversation.

Who Builds What? (The Division of Labor)

Figure 3: On the left, illustrate an ML Engineer ("The Chef") training massive Transformer models using GPUs, datasets, and neural networks. On the right, show an Application / GenAI Engineer ("The Restaurateur") building chat interfaces, integrating APIs, streaming responses, storing conversation history, and creating polished AI-powered applications for users.

People often assume application developers spend their days designing neural networks and writing complex mathematical equations.

In reality, responsibilities are generally divided into two complementary roles.

Machine Learning Engineers

Think of them as the master chefs.

They build the intelligence itself by:

Designing neural network architectures
Training foundation models
Creating embeddings
Optimizing GPU workloads
Improving Transformer architectures
Fine-tuning and evaluating models

Application / GenAI Engineers

Think of them as the restaurant owners.

They take an already-trained LLM and transform it into products people use every day by building:

AI chat interfaces
API integrations
Streaming responses
Authentication
Conversation history
Prompt engineering
RAG pipelines
Vector databases
Monitoring
Production-ready user experiences

One builds the brain.

The other builds the product.

Both are equally important in delivering a great AI experience.

Wrapping Up

The next time you watch an AI generate a response, you'll know there's no magic happening behind the scenes.

Your words are first broken into tokens, transformed into mathematical representations, enriched with positional information, analyzed through the Transformer's self-attention mechanism, and then used to predict the most likely next token. That prediction becomes part of the conversation, and the process repeats hundreds of times until a complete response is generated.

What feels like a natural conversation is actually millions—or even billions—of mathematical operations happening in just a few seconds.

Understanding this pipeline doesn't mean every application developer needs to become a machine learning researcher. But knowing what happens behind the API helps us build better AI-powered applications, write more effective prompts, design more intuitive user experiences, and make smarter engineering decisions.

Modern AI isn't powered by magic—it's powered by mathematics, probability, and an extraordinary amount of engineering.

And perhaps that's even more fascinating.

Weird behavior of javaScript you should know!

AbhiJsDev — Mon, 10 Jan 2022 15:53:26 +0000

We know that javaScript sometimes behaves weird as compare to other programming languages, but initially it was design only to make web pages.

But now in today's world, we can do so many things using javaScript with help of other libraries/framework like react, angular.

This weird behaviour is not a fault of javaScript, this is how the language was design in the initial phase. So we should understand why this behaviour happens, so we can take primitive actions based on it.(If we are intending that this should not happen)

So here, we make one object calling its name weirdObject which has property obj_id and obj_name which is further divided into an object which has property obj_title and type.

If we run our code with node we get the output as the object considering obj_id and obj_name.

Now, if we want to change the obj_id of the object we can do that in javaScript inspite of using const keyword.(It is allowed to change inside property of javaScript whether we use const or not)

To change this behaviour, we can use Object.freeze() method which freezes an object.

Here the value of obj_id not changed. A frozen object can no longer be changed; freezing an object prevents new properties from being added to it, existing properties from being removed, prevents changing the enumerability, configurability, and writability of existing properties, and also prevents the values of existing properties from being changed.

But, what if we want to change value of the obj_title from "My Object" to "This Object" which is present inside obj_name object of weirdObject after using Object.freeze() method.

Let's see..

Yes, we can do that..!! This is called Shallow freeze which only applies to the immediate properties of the object itself and will prevent future property addition, removal or value re-assignment operations only on object. If the value of those properties are objects themselves, those objects are not frozen and may be the target of property addition, removal or value re-assignment operations.

To make object immutable, we will have to add explicit function which will check is wheather the object has another object present inside it.

Hope this odd behaviour of javaScript information helps you.
Thanks for reading and happy coding!

Do you know Isomorphic JavaScript?

AbhiJsDev — Thu, 12 Aug 2021 14:21:56 +0000

In programming we tend to hear a lot of really strange words such as isomorphism, etc.

What is Isomorphic?

In general term "iso" means "same" and "morphic" means "form" ie same form that we are studied from our childhood.

In simplest terms isomorphic javaScript is the javaScript that can be run on both the server as well as on the client.

Let's discuss with examples below.

This code snippet is isomorphic, the code will run in a
node.js environment and it will also run in the web browser.

This code doesn't uses any node-specific libraries or browse any web apis, it's just an arrow function in javaScript that will run in environment.

Now let's have a look on another example which is not isomorphic.
We will be using fetch api to get some data from external api(NewsAPI).

This code is not isomorphic because the fetch function is provided by the web browser and results in ReferenceError.

If we want to run on both the client and the server we have to import a third-party library such as axios. The code something looks like this

This would be considered as isomorphic javaScript but it's important to note that we only need one successful path that will run on both the server and the client in order to be considered isomorphic.

If we have a javaScript function that checks the environment to determine whether or not it's on the client or the server and then it has the path for both of those cases then that can be considered as isomorphic javaScript for example this

This code checks for the window object and determines whether or not it is running on the client or the server and then logs the result.

This is isomorphic because it will run on both the server and the client so it's important to note here that isomorphic javaScript is the way that we write the code and
it's "not a particular technology" it's just sort of like a design pattern. Writing code in this way allows you to be able to do certain unique things such as server side rendering.

Hope this information helps you to understand isomorphic javaScript.
Thanks for reading and happy coding!