DEV Community: Alexandra

Understanding JavaScript Execution Context: The Foundation of Interactivity

Alexandra — Mon, 27 Jul 2026 10:47:33 +0000

The most difficult thing in JavaScript is understanding how things are collaborating in order to provide interactivity.

The execution context is equivalent to a workspace. Whenever JS runs some code, it creates a workspace to contain everything it needs to do it successfully. That workspace has the variables, the functions, the this and information on where to continue working.

Creating contexts

There are two ways to create this workspace:

When a program starts (Global execution context)
Every time a function is called (Function execution context)

const name = "Alex";
function greet() {
    const message = "Hello";
    console.log(message);
}
greet();

when this program starts JS creates the global context with the name and greet.Then the greet function is called, which creates a new execution context that includes the variable message. When the function greet() finishes its execution, this context is removed. When the program finishes the global context is also removed. A fair question here is: "removed from where"? The answer is: from the infamous call stack.

The call stack

These execution workspaces are stored in a stack. If you don't know what a stack is: it is a data structure with some specific properties. New elements are added at the top of the stack, elements are removed also from the top of the stack. The most famous comparison is to think of a stack as a stack of plate. You wouldn't remove a plate from the bottom of the stack. This property is called LIFO: Last in First out.

┌─────────────┐
│   greet()   │  ← Top (will be removed first)
├─────────────┤
│   Global    │  ← Bottom (removed last)
└─────────────┘

When greet() finishes, it's "pop'ed" from the stack and only the global context remains (until the end of this program)

function first() {
    second();
}

function second() {
    third();
}

function third() {}

Before any call:        During execution:       After all finish:
┌──────────────┐        ┌──────────────┐       ┌──────────────┐
│   Global     │        │   third()    │       │   Global     │
└──────────────┘        ├──────────────┤       └──────────────┘
                        │  second()    │
                        ├──────────────┤
                        │   first()    │
                        ├──────────────┤
                        │   Global     │
                        └──────────────┘

As every functions finishes their executions, it's get popped from the stack. First the third finishes and it is removed, then the second, etc.

The two phases of the context

Every execution context has two phases. The 1st phase is the Creation: JS scans the code and prepares the memory, it identifies variables and functions.

Variables declared with var are initialised with undefined.
Functions defined with the function keyword are saved as a whole.
let and const variables are registered in an other place called Temporal Dead Zone.

The next phase is the execution: JS runs the code line-by-line. It assign values to variables and executes statements.

Why hoisting happens?

There is a word that scares every web developer: hoisting. This happens due to the creation phase. As JS scans the code it already knows about variables and functions before execution even begins. That process is called hoisting.

console.log(a); // Prints undefined, because JS initialized the a with undefined in the creation phase
var a = 5;

Function declarations are fully hoisted, so you can call them even before they are written.

greet(); // This works! Prints "Hello"

function greet() {
    console.log("Hello");
}

Note: function expressions are NOT hoisted. Function expressions are functions that are stored in a variable.

`let` and `const` against hoisting

In ES6 the keywords let and const were introduced. When you run the same code as before but using let this time..you get a reference error. what is happening?

console.log(a); // throws ReferenceError
let a = 5;

Javascript still knows that a exists, but the difference is that now is not saved in the context. Instead, it's stored in an another place called Temporal dead zone (TDZ).

Understanding TDZ

The TDZ is a region in a block where a variable exists but cannot accessed (yet). TDZ starts from the beginning of the block until the variable is declared and initialized.

if (true) {
    // TDZ for 'a' starts here
    console.log(a); // ReferenceError - 'a' is in TDZ, not accessible

    let a = 5;      // TDZ ends here, 'a' is now initialized and accessible

    console.log(a); // 5 - now it works
}

The Scope Chain: Looking Beyond the Current Context

When you reference a variable inside a function, JS doesnt only look in the current execution context. If the variable is not found in the current, it start looking on the parent, and then it's parent until it reaches the global context. This is called scope chain.

const global = "I'm a global var";

function outer() {
    const outerVar = "I'm in outer scope";

    function inner() {
        const innerVar = "I'm in inner scope";

        console.log(innerVar);  // ✅ Found in inner's context
        console.log(outerVar);  // ✅ Found in outer's context (via scope chain)
        console.log(global);    // ✅ Found in global context (via scope chain)
    }

    inner();
}

outer();

summary

✅ JS creates an execution context before running code
✅ Every function call creates an execution context
✅ These contexts are managed using the call stack
✅ Each execution context has a creation and an execution phase.
✅ Hoisting happens in the creation phase due to the scan of the code.
✅ const and let solved the initialization issues in JS by storing variables in TDZ
✅ The scope chain allows functions to access variables from their parent contexts (lexical scoping)

What Are Embeddings?: How AI Knows a Cat and a Kitten Are Related ⭐

Alexandra — Sat, 25 Jul 2026 11:02:11 +0000

This is a very simplified version of what an embedding is and is meant for beginners. Felt that I had to put a disclaimer here for the ai bros.

The question `embeddings` answer

How does a computer "know" that a cat and a kitten are related, that a dog is closer to a cat than to a car, and that a car is closer to a truck than to either a cat or a dog?? Computers don't understand meaning, they only understand numbers. So the trick is turning the meaning of text into numbers that math can work with.

An embedding is simply a long list of numbers that represents the meaning of a piece of text. Modern embeddings often contain hundreds or even thousands of numbers, but you don't need to understand each number individually. Pieces of text with similar meaning end up close together in this mathematical space.

A map of meaning

Imagine every word or phrase being placed on a giant map. Similar meanings end up close together, while unrelated end up far away. A model places words near each other based on how they are used in huge amounts of text, so "cat" and "kitten" end up near each other, "dog" and "puppy" are also close together and nearby to cats too, and something unrelated like a "car" sits in a completely different region.

In reality, embeddings live in far more bigger structure than a map, meaning in multiple dimensions, usually hundreds or thousands, which is impossible to actually draw (or even understand with my small 3d brain). But the two-dimensional version captures the core idea: distance yields relationships.

Where the numbers actually come from

An embedding isn't assigned by a person deciding "cat should be at this coordinate". During the training phase a model gradually learns how to convert text into embeddings based on the contexts it sees across enormous amounts of data. Words used in similar contexts end up near each other, because that's all the model ever sees: patterns in language.

This is also why embeddings capture relationships that go beyond simple synonyms. Classic examples show that the relationship between "king" and "queen" is mathematically similar to the relationship between "man" and "woman".

Why this matters for search and recommendations

Traditional keyword search matches exact words. Searching for an "affordable laptop" in a keyword-based system might miss a product like a "budget-friendly notebook" because the words don't literally match, even we (the humans) know that the meaning is identical.

Embedding-based search fixes this problem. Instead of matching words, it converts your search query into a point in the giant map and finds the nearest neighbors/points. This is why modern search and recommendation systems can surface something relevant even when you didn't use the "right" word.

Words aren't the only thing that can be embedded

Despite using words like "cat" as examples, embeddings aren't limited to single words. Entire sentences, paragraphs, documents, images, and even audio can all be represented as embeddings. The idea stays exactly the same: similar meaning ends up close together in the giant map.

In previous articles we talk about RAG and how this has a retrieval step. A simplified description of the retrieval step by adding the embeddings to the calculation will be: Your question is converted into an embedding, the documents have been embedded already, and the system simply retrieves the ones that are closest in that embedding map.

Where this shows up if you're building products

If you're building search, recommendations, finding duplicate content, or anything that needs to group or match content by meaning rather than exact text, embeddings are usually the tool for it, not string matching anymore.

A few practical things worth knowing:

Documents are usually embedded once and stored. When a user searches, only the new query needs to be embedded, making retrieval much faster.
Similarity isn't the same as correctness. Two pieces of text can be very similar while still answering the wrong question. That's why many systems rank, filter, or validate results after the similarity search.
The embedding model matters. Different embedding models place things differently, and a model tuned for one domain may not embed specialised or technical content as usefully as one tuned for that domain.

Resources

If you'd like to dive deeper into embeddings and how they're used in modern AI systems, these are excellent starting points:

Anthropic – Embeddings Documentation

https://platform.claude.com/docs/en/build-with-claude/embeddings

A practical guide explaining what embeddings are, how they work, and how they're used for semantic search, recommendations, and retrieval.
OpenAI – Embeddings Guide & FAQ

https://help.openai.com/en/articles/6824809-embeddings-faq

Covers OpenAI's embedding models, common questions, distance metrics, and best practices.
Word2Vec: Efficient Estimation of Word Representations in Vector Space (2013)

https://arxiv.org/abs/1301.3781

The classic paper by Tomas Mikolov and colleagues that popularised learned word embeddings.
Pinecone – Dense Vector Embeddings Explained

https://www.pinecone.io/learn/series/nlp/dense-vector-embeddings-nlp/

A visual, beginner-friendly explanation of dense vectors, embeddings, and semantic search, with examples beyond Word2Vec.
Jay Alammar – The Illustrated Word2vec
https://jalammar.github.io/illustrated-word2vec/
A visual, intuitive explainer on word embeddings, in the same style as his famous "Illustrated Transformer."
Embeddings & Vector Search in 2026: The Engineer's Complete Guide
https://jobsbyculture.com/blog/embeddings-vector-search-guide-2026
Covers embedding models, ANN algorithms (HNSW, IVF), and building production RAG pipelines.
How to Generate Better Embeddings for Vector Search
https://pr-peri.github.io/llm/2026/02/12/generate-embeddings-vector-search.html
Practical guide to improving retrieval quality via chunking, cleaning, metadata, hybrid search, and proper evaluation (Recall@K, MRR).
Best Embedding Models 2026: Tested on 50K Documents
https://pecollective.com/tools/best-embedding-models/
Compares OpenAI, Cohere, Voyage AI, and Jina embedding models on real retrieval benchmarks, not just MTEB scores.

[Boost]

Alexandra — Fri, 24 Jul 2026 15:04:00 +0000

Alexandra

Jul 19

Tokens aren't words: what actually happens when you send a prompt

#eli5 #ai #webdev #beginners

3 min read

Stop Hiring a Rocket Scientist to Check If a Box Is Empty

Alexandra — Thu, 23 Jul 2026 17:26:44 +0000

One thing I've been thinking about lately is what trade-offs companies are willing to make in order to market their products as "AI-powered."

A tale as old as 2023

A team needs to validate an email address. Someone asks, "What if we used AI?" Five minutes later there's a model call, an API key, a loading spinner, a monthly bill & somehow Kubernetes got involved. Congratulations, you've successfully turned O(1) into "please wait while we contact the cloud."

This is not an argument against AI. Large language models are highly effective for many categories of problems. The issue is not the technology itself, but its application to tasks that never needed it in the first place, because it's new and shiny and everyone is doing it.

The actual differences

Here's an unglamorous truth: an if statement & an LLM call are not doing the same job. They're built for different kinds of problems, and their differences are greater than people give it credit for.

An if statement runs in a millisecond, costs nothing per call, and gives you the exact same answer every single time for the same input (deterministic). An LLM call, takes real time, costs real money, and can give you a slightly different answer to the exact same question depending on the day, the model version, or the wind direction.

if-statement or AI?

Reach for an if statement (or a regex, or .. or ..) when:

The rule is simple and well-defined. "Is this a valid email format?" "Is the cart total over $50?" "Is the field empty?"
You need the same input to produce the same output. Billing logic, permission checks, form validation. No your users don't want their invoice total to vary by mood.
Performance is important and there is no ambiguity requiring interpretation.

Reach for AI when:

The task requires judgement. Summarise an article, classifying open-ended free text into fuzzy categories.
The input space is too large or unpredictable. You can't write an if statement for "understand what this customer is actually frustrated about" from a paragraph of free text.
Some variability in output is fine, or even desirable. A creative writing assistant that gives the exact same suggestion every time isn't actually that useful.

More examples than you asked for, because this pattern is everywhere

Password strength meter. "At least 8 characters, one number, one symbol" is a rule. Come on. We've been solving this since MySpace was a thing. No model needed, no matter how tempting "AI-powered password feedback" sounds on a feature list.

Flagging a support ticket as urgent. If "urgent" just means "contains the word 'urgent' or 'broken'," that's a keyword check. If "urgent" means understanding the tone, the context, and the severity from a paragraph of a frustrated customer wrote at 2am, that's no longer a keyword problem. That's a language understanding problem.

Discount code validation. "Is this code in our database and not expired?" is a lookup, full stop. Please don't ask a model to check a database for you; that's what the database is for.

Sorting a list by price. Please don't spend $0.002 to rediscover ascending order.

Summarizing 200 pages of meeting notes into three takeaways. A hard to write a rule for. This is a real, appropriate use of a model's judgement.

Writing a product description from a spec sheet. Turning structured facts into natural, readable list is a language task. This is AI doing what it's actually good at.

The cost of choosing the wrong tool

This isn't just a complaint about over-engineering. Reaching for AI on an if-statement problem has real costs:

Latency you didn't need to add. A local computation becomes a network request with inference time.
Money you didn't need to spend. Each inference incurs a monetary cost that accumulates with usage. We've somehow managed to invent a subscription for if.
Unpredictability you didn't ask for. If your business logic can quietly behave differently for the exact same input, you've turned a deterministic system into a probabilistic one. Now you get to debug "why did this work yesterday and not today" for a rule that used to just... work.
A dependency you didn't need. Functionality becomes dependent on the availability, performance, and pricing of third-party AI services.

Reflect on our choices

Before reaching for AI, ask: could I write this rule down in a sentence, and would that sentence still be true tomorrow? If yes, you probably want an if statement, not a model call. If the honest answer is "well, it depends, there's a lot of nuance, it's hard to actually pin down," that's usually the signal that you've found a problem AI is actually good at.

AI earning its place in a product should feel like reaching for a tool that's uniquely suited to a hard problem, not like a reflex applied to everything because it's the exciting new thing to reach for.

Sometimes the most sophisticated piece of technology in the room is the engineer who knew not to call the model.

Resources

Google's guidance on when to use ML — from Google's own People + AI Guidebook, on evaluating whether a problem needs machine learning: https://developers.google.com/machine-learning/guides/rules-of-ml
Martin Fowler on YAGNI ("You Aren't Gonna Need It") — https://lawsofsoftwareengineering.com/laws/yagni/
Anthropic's guide to when (and when not) to use agents/LLMs — practical framing for deciding where a model call is actually justified: https://www.google.com/search?client=firefox-b-d&q=Anthropic%27s+guide+to+when+%28and+when+not%29+to+use+agents

What is a context window, actually?

Alexandra — Wed, 22 Jul 2026 09:30:02 +0000

AI is moving fast, and it feels like there's a new concept to learn every week. In an effort to actually understand this whole new world instead of just skimming past it, I've been writing ELI5 articles breaking down concepts that show up constantly in AI conversations but rarely get explained simply. This time, a term that gets thrown around a lot without much explanation: the context window.

AI 101 Recap

The context window is the total number of input and output tokens an LLM can consider while generating a response. Your prompt, the conversation history, and even the model's response all share that same "budget" of tokens. As a conversation with an LLM grows longer, more tokens live in this window.

So far so good. Every AI model has a limit on how many tokens it can hold in its "working memory" at once. So the interesting part with the context window is what happens when you reach these limits.

Why are there limits?

There are several reasons models have context window limits. Processing more tokens requires more memory and computation, making every request slower and more expensive. On top of that, today's models struggle to use very long contexts effectively. They naturally pay more attention to the beginning and end of a conversation than the middle ("lost in the middle" problem).

The Amnesia Problem

An AI model has no persistent memory between conversations. Within a long conversation, it only sees whatever still fits inside its context window. Think of it as a sliding window: as new messages come in, older ones eventually slide out and are no longer visible to the model.

This is why a long conversation can feel like the model has "forgotten" something you told it early on. It doesn't actually forget, it just no longer has access to that part of the conversation, unless the product you're using has built something extra on top to handle it.

How RAG helps

RAG (retrieval-augmented generation) sounds technical, but the idea is simple: look it up before you answer, instead of guessing from memory.

Think of the model as a smart intern who read a huge pile of general knowledge, but has never seen your company's internal docs. If you ask that intern a question about your product, you wouldn't expect them to know the answer off the top of their head.

The flow looks more or less like this:

That's RAG. Before generating a response, the system retrieves the most relevant pieces of information and adds only those to the prompt. Instead of searching through thousands of documents itself, the model receives just the information it needs.

This fixes two problems at once:

It solves the "too much to fit" problem. You don't need to cram an entire wiki into the context window — just the relevant slice.
It solves the "the model doesn't know that" problem. Training data has a cutoff and doesn't include your private docs. Retrieval hands the model current, specific facts instead of asking it to make something up.

It's not magic, though. If the search step grabs the wrong page the model's answer will be wrong too. A RAG system is only as good as its retrieval step, not just the model doing the writing at the end.

Why longer context isn't automatically better

Newer models advertise huge context windows, sometimes hundreds of thousands of tokens. It's tempting to think the fix for all of this is simple: just make the window bigger, and pile everything in.

Turns out that doesn't hold up as well as it sounds.

It costs more and takes longer. Every extra token in the prompt means more processing on every single request.
Models don't "read" a huge context evenly. They tend to pay attention to the start and the end of a long conversation, and quietly lose track of things in the middle.
More text means more noise. A huge pile of context gives the model more chances to get distracted by something irrelevant, outdated, or conflicting.

A bigger context window isn't automatically better. It gives the model more information to work with, but also more opportunities to be distracted. That's why RAG matters: retrieving a small set of relevant information is usually more effective than hoping the model can make sense of everything at once.

Resources

Context windows

Anthropic's context window documentation — official, model-specific limits and behavior
"Lost in the Middle: How Language Models Use Long Contexts" (Liu et al., 2023) — the research paper behind the finding that models underuse the middle of long contexts
OpenAI's models documentation — useful for comparing how another provider frames the same constraint

RAG

"Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" (Lewis et al., 2020) — the original RAG paper from Meta AI
Pinecone's guide to RAG — practical, vendor-neutral explanation
LangChain RAG documentation — hands-on look at how RAG pipelines are built
AWS: "What is RAG?" — plain-language explainer
IBM: "What is retrieval-augmented generation?" — another accessible, non-technical framing

Does the web feel slower these days?

Alexandra — Mon, 20 Jul 2026 08:17:49 +0000

Many apps I've been using lately seem to have the same issue. HBO Max buffers all the time; Instagram stops mid-scroll. At the same time, internet providers promise the fastest internet we could ever have. How is this contradiction happening? How can the internet be in it's fastest and slowest era?

It's not just a feeling, but it's also not new

Web pages have been getting heavier for a long time, well before AI features were a factor. Most pages these days are bloated with JS, media and chatbots. Cloudflare's own performance research points out that web pages have grown 6 to 9 percent every year for roughly a decade. Separately, HTTP Archive data puts the median desktop page at around 2.3 megabytes today. So the starting point here is: the web has been trending heavier for years and the real question is whether AI is making an existing trend worse, and in what specific ways.

What AI features actually add to the weight

Chat widgets add real weight, and it varies a lot by vendor. Independent benchmarking has found that a lightweight AI chat widget can add as little as 79KB of JavaScript, while a heavier one can add over 500KB and nearly a second of script execution time.

This weight typically loads whether or not the visitor ever opens the widget. If a chat bubble sitting in the corner of a page is still costing something on every single page load, for every visitor, most of whom will never click it.

Search results now often think before they answer. AI-generated answers and summaries now appear in a large share of search results, with estimates putting AI-generated answers in roughly half of Google queries in early 2026. Search used to be near-instant: type, get a results page. Now, a visible "generating" moment has been inserted into an interaction that used to feel immediate.

Agent and crawler traffic is adding load most people never see. Beyond what a human visitor experiences directly, the sheer volume of automated AI agents and crawlers hitting websites has grown sharply. Cloudflare has reported that agentic traffic made up close to 10 percent of its network requests as of March 2026, up 60 percent year over year.

Instant interactions are quietly becoming round trips. Actions that used to be handled instantly, client-side, are increasingly being routed through an AI call instead: smarter autocomplete, AI-assisted form suggestions, AI-powered search-as-you-type. Even when the AI call is fast, it's still a network round trip standing where synchronous logic used to be. Multiply that across a page with several "smart" features, and small delays start adding up into something a user can actually feel, even if no single delay is dramatic on its own.

Some of this is self-inflicted, not inherent. Not every AI-related delay comes from the AI itself. Some products deliberately throttle how fast a response streams in, purely for the visual effect of "watching it type," even when the full answer was actually ready almost immediately.

Why it compounds instead of replacing anything

The important part is that none of this is replacing the older sources of page bloat, the images, the trackers, the ad scripts, the frameworks. It's stacking on top of a foundation that was already getting heavier every year. A page that was already carrying a few megabytes of scripts and media now often also carries a chat widget, an AI search layer, and a handful of AI-backed interactions that used to be instant and local.

What this means if you're building these features

Lazy-load anything AI-related that isn't part of the core experience. A chat widget that loads asynchronously after the page renders shouldn't block anything a visitor actually came for.
Don't let "smart" replace "fast" for things that were already fast. If a client-side interaction worked well without a network round trip, adding an AI call to it should have a clear payoff, not just because it's possible.
Be honest about whether streaming delay is earning its keep. If a response is ready, showing it is usually better than manufacturing a typing animation purely for effect.
Measure the actual Core Web Vitals impact of any AI feature before shipping it, the same way you'd measure any other third-party script. "It's AI" isn't an exemption from the same performance discipline everything else on the page has to meet.

The web probably isn't slower because AI is inherently heavy. It's slower because we're stacking new "thinking" steps and new scripts on top of a foundation that was already trending heavier every year, often without asking whether each addition is actually earning the delay it introduces.

Resources

Shared Dictionaries: compression that keeps up with the agentic web
Cloudflare on web bloat and shared dictionaries — data on the decade-long trend of growing page weight and rising agentic traffic: startuphub.ai/ai-news/technology/2026/cloudflare-shrinks-web-bloat-with-shared-dictionaries
Median web page weight in 2025: 15 years of web bloat
DebugBear's chat widget performance benchmark — a comparison of real-world JavaScript weight across popular chat widget vendors: debugbear.com/blog/chat-widget-site-performance
HTTP Archive - Page weight — httparchive.org
web.dev on Core Web Vitals — Google's official guidance on measuring and improving real-world page performance: web.dev/vitals

Tokens aren't words: what actually happens when you send a prompt

Alexandra — Sun, 19 Jul 2026 15:56:08 +0000

AI is moving fast, and it feels like there's a new concept to learn every week. In an effort to actually understand this whole new world instead of just skimming past it, I started writing these ELI5 articles breaking down the concepts that show up constantly in AI conversations but rarely get explained simply. First up: tokens, and what's actually happening when you send a prompt.

Tokens, tokens everywhere

Every time you type into ChatGPT, Claude, or Copilot, your text doesn't go into the model as words. It gets chopped up first, into pieces called tokens. Sometimes this is a whole word, sometimes half a word, sometimes just a punctuation mark. The model never sees your sentence. It sees a sequence of numbers standing in for those pieces.

This is one of those things that's easy to skip over as a detail, but once you understand it, a bunch of AI behavior suddenly makes sense: why long prompts cost more, why some words seem to trip models up, why "count the letters in this word" is weirdly hard for an LLM.

Step one: splitting the text

Take the word "accessibility." A tokenizer doesn't treat it as one unit/word. It's common enough to be one token, but a lot of real-world text splits into recognizable chunks. Common short words like "the" or "cat" are usually a single token. Longer, less frequent, or more technical words often get broken into two or more pieces.

Step two: turning pieces into numbers

Each token maps to a number, based on a fixed vocabulary the model was trained with. So "access" might become 5426, and "ibility" might become 9821. The model doesn't process letters or meaning directly. It processes a list of numbers and predicts what number is statistically likely to come next, then translates that number back into text for you to read.

This is why an LLM can struggle with something like reversing a word or counting how many "r"s are in "strawberry". That's because it's not looking at s-t-r-a-w-b-e-r-r-y character by character. It's looking at a couple of opaque token chunks and has no direct access to the letters inside them.

Fun facts of tokanization

Whitespace and punctuation count as tokens too. A sentence full of short words and spaces can end up costing more tokens than a shorter sentence built from fewer, longer words. Token count isn't the same as word count or character count.
Non-English text often tokenizes worse. Most models are trained primarily on English text, so the same sentence in another language can break into noticeably more tokens to represent the same meaning.
Token limits define the "context window." This is the part that matters most if you're building products on top of these models, not just using them. Every model has a maximum number of tokens it can hold in memory at once — your prompt, the conversation history, and the response all share that budget. If you go over this limit the context will get condensed: older messages get dropped, input gets truncated, or you hit an error.

Why this matters if you're a frontend engineer

Tokenization isn't just a backend or ML-team concern anymore. Most products nowaday build something that streams AI output, that means you're designing around token budgets whether you realize it or not:

Streaming UX: responses arrive token by token, not word by word, which is why text sometimes appears to render in odd fragments before normalizes.
Truncation handling: what does your UI do when a conversation hits the context limit?
Cost and latency: token count drives both API cost and response time, so a feature that quietly sends more context than it needs is a real product cost, not just a technical detail.

Understanding tokens won't make you a machine learning engineer. But it will make you a better engineer of the products sitting on top of these models, which, increasingly, is most of us.

Resources

OpenAI Tokenizer — paste any text and see it split into tokens live: platform.openai.com/tokenizer
Anthropic's token-counting docs — how context windows and token limits work across Claude models: docs.claude.com
tiktoken — the open-source library OpenAI uses for tokenization, if you want to count tokens programmatically: github.com/openai/tiktoken
Hugging Face Tokenizers — for exploring tokenization across different open models, not just one vendor: huggingface.co/docs/tokenizers

[Boost]

Alexandra — Mon, 13 Jul 2026 21:11:30 +0000

DEV Weekend Challenge: Passion Edition Submission

Alexandra

Jul 11

Passion Lens: Discover the Passion Hidden in Your Photographs

#devchallenge #weekendchallenge

3 min read

Passion Lens: Discover the Passion Hidden in Your Photographs

Alexandra — Sat, 11 Jul 2026 21:08:36 +0000

Passion Lens: Discover the Passion Hidden in Your Photographs

This is a submission for Weekend Challenge: Passion Edition.

What I Built

When the challenge has a theme about our passions, mine was clear. I love photography. I picked up a camera more than 10 years ago, and I guess I've done my part to reinforce the stereotype that every frontend developer is secretly a photographer. To me, photography is a story, a feeling, a moment, a landscape. That's why i love landscapes and street photography.

The project's idea is simple: what the pictures you take say about you? What if you have a personal photography expert that let you capture the essence and learn something new about yourself?

You just upload a photo, share where it was taken and why it matters to you, and choose your storytelling voice: documentary, cinematic, poetic, or travel journal.

Passion Lens uses Google Gemini to analyze the visible composition alongside the photographer’s own context. It creates:

A title and three moods
A personal memory
Visual observations grounded in the photograph
Composition notes
A reflection on what the photograph may reveal about the photographer’s passions

The experience is designed to feel reflective rather than transactional.

Once the memory is ready, the user can listen to it through ElevenLabs narration or download the complete memory as a PDF.

Passion Lens begins with a photograph, but its real subject is the person behind the camera.

Demo

🔗 Try Passion Lens

The demo flow:

Upload a photograph.
Add a location and a few personal words.
Select a storytelling style.
Generate the memory.
Explore Gemini’s story, moods, visual observations, and passion reflection.
Listen to the narrated memory.
Download the finished memory as a PDF.

Code

💻 View the source code on GitHub

How I Built It

Passion Lens uses React, TypeScript, Vite, and Framer Motion on the frontend, with an Express server handling the AI integrations.

Google Gemini

The uploaded photograph and the photographer’s written context are sent as a multimodal request to Gemini.

Gemini returns a structured JSON response containing:

title
moods
visualDetails
story
photographerInsight
passionProfile

Using a response schema made the output predictable enough to drive the designed memory interface directly.

The prompt explicitly tells Gemini not to invent events, identities, relationships, professions, destinations, or emotions that cannot be observed. If a person appears in the photograph, the model describes only visible details. I tried many prompts, but it still vastly makes up things sometimes. :/

ElevenLabs

ElevenLabs turns the generated story into spoken narration.

The photograph slowly brightens and moves while narration is playing, making the memory feel alive without distracting from the story.

Memory Experience

The final card asks:

What does this photograph reveal about you?

This is where Passion Lens moves beyond “AI writes a story about my photo.” It begins helping the photographer understand why certain moments attract their attention.

PDF Export

The browser generates a downloadable PDF with jsPDF.

It includes the photograph, title, location, moods, story, Composition Notes, and passion profile. This gives the user something lasting to keep or share after the experience ends.

Technical Stack

React
TypeScript
Vite
React Router
Framer Motion
Express
Google Gemini API
ElevenLabs API
jsPDF
Multer

Challenges and Lessons

A memory should feel personal and evocative, but an image model should not quietly invent facts about someone’s life. Separating user-provided emotional context from model-observed visual details helped preserve that boundary.

Structured Gemini output was another important decision. Instead of parsing free-form prose, the application receives a defined object that can be safely mapped into different parts of the interface.

Prize Categories

Best Use of Google AI

Gemini is the central intelligence behind Passion Lens. It combines multimodal image understanding with the photographer’s context to produce grounded visual observations, a personal narrative, Composition Notes, and a carefully framed passion profile.

Best Use of ElevenLabs

ElevenLabs transforms each generated story into an intimate narrated memory. Voice makes the result feel less like generated text and more like revisiting a moment.

What’s Next

The current MVP analyzes one photograph at a time.

The next step is persistence: allowing users to build a private collection of memories. Passion Lens could then identify recurring subjects, environments, colors, emotions, and composition choices across the collection.

That is the larger promise of the project:

Your photographs do not only show where you have been. Together, they may reveal what you keep searching for.

Being an engineer in the AI era

Alexandra — Tue, 07 Jul 2026 20:10:15 +0000

I hesitated to write this.

Not because I don’t have an opinion about AI in software engineering, but because it sometimes feels increasingly difficult to have nuanced conversations about it.

I worked in an environment where being “AI native” was part of the identity. And when a technology becomes part of a company’s identity, questioning it can feel almost uncomfortable. The conversation quickly moves from “where does this create value?” to “how do we put AI everywhere?”

But I think we need more honest conversations.

AI is powerful. There is no doubt about that.

It helps me write code faster. It helps me explore unfamiliar areas of a codebase. It can remove repetitive work and accelerate experimentation.

But there is something important we should not forget:

Speed is not the same as progress.

Not everything needs AI

The truth is, not every problem needs artificial intelligence.

Not every business needs AI. Not every product needs AI features. Not every interaction needs to be optimized or automated.

Especially in industries built around people.

Hospitality, for example, is fundamentally about human connection. The experience someone remembers is often not the automated process behind the scenes, it is the person who cared, noticed, helped, and went the extra mile.

There is a Greek word I love: meraki.

It means putting a part of yourself into what you do. Doing something with love, creativity, and care.

And I think this concept is becoming increasingly important in software engineering.

The craft behind the code

When you genuinely care about your work, you don’t just want to eliminate every inconvenient part of it.

The difficult parts are where you grow.

Reading confusing code. Debugging strange production issues. Getting feedback from teammates. Having discussions about architecture. Making mistakes and learning from them.

These experiences build engineering intuition.

Software engineering has changed dramatically in the last few years. AI-assisted development is becoming part of our daily workflow, and I believe there is a lot of value in it.

But the reason AI makes me better today is because I learned the fundamentals before it existed.

I learned how systems behave.
I learned how to debug without an answer being generated for me.
I learned how to question solutions instead of blindly accepting them.
I learned through feedback, collaboration, and years of solving problems.

AI amplifies existing knowledge. It does not magically create engineering judgment.

What happens when we outsource thinking?

One of the things I worry about is not AI itself.

It is the temptation to outsource the parts of engineering that make us engineers.

Architecture exploration.
Technical discussions.
Understanding trade-offs.
Questioning assumptions.
Designing solutions together.

A company is not just a machine that transforms requirements into code.

A company is a collection of people with different experiences, perspectives, and expertise. The best solutions usually appear through conversations, disagreements, and collaboration.

If we delegate all exploration and architecture decisions to agents, what happens to the collective intelligence of the team?

What happens to the engineers who no longer build intuition because they never had to struggle?

What happens to the products created by people who never deeply understood the problems they were solving?

We might become very efficient at producing software nobody feels connected to.

Building software with meaning

I miss the feeling of building something meaningful.

I miss challenging architecture decisions. I miss deep technical discussions. I miss the excitement of solving hard problems with people who care.

Because the best software is not created by the fastest person typing the most code.

It is created by people who understand the problem, care about the users, and bring their experience into every decision.

I love building useful products.
I love seeing customers happy because something we created solved a real problem.
I love software engineering because it is a craft.

AI can help us create faster. It can help us explore more. It can remove friction.

But we should be careful not to remove the very things that make building software meaningful.

The future of engineering should not be humans versus AI.

It should be humans using AI while protecting curiosity, craftsmanship, and ownership.

Because without those things, we are not building software. We are just generating output.

Epilogue

Thank you for reading my messy thoughts, since today i got laid off because my company wants to be AI native, it felt appropriate to share my fears for the future to a bunch of strangers.

HTML Tag 📝

Alexandra — Thu, 25 Dec 2025 17:48:48 +0000

Ever wanted to be super semantic and helpful to your users and machines? The HTML <abbr> tag is your secret weapon for abbreviations! It's tiny, but mighty for accessibility and clarity. Let's dive in!

What it Does 🧙‍♀️

The <abbr> tag marks up an abbreviation or acronym. Its superpower? When you add a title attribute, it creates a magical tooltip on hover, revealing the full term!

<abbr title="Today I Learned">TIL</abbr> something awesome!

Styling Shenanigans 🎨

Browsers can be a bit... inconsistent with <abbr>'s default look (looking at you, Safari!). Good news: it's super easy to style!

abbr {
  text-decoration: underline blue dotted; /* Custom underline! */
  color: blue;
  cursor: help; /* A friendly cursor to indicate more info! */
}

The Great `<abbr>` vs `<acronym>` War ⚔️ (A Brief History Lesson)

Back in the day (the late '90s!), there was a fierce battle between Netscape's <abbr> and Microsoft's <acronym>. Developers were caught in the crossfire! But fear not, HTML5 brought peace:

<acronym> is DEPRECATED! 👋
<abbr> WINS! 🎉

So, always use <abbr> – it covers both abbreviations and acronyms! Easy peasy.

Getting Extra Semantic: `<abbr>` with `<dfn>` 📚

When you're defining a term that's also an abbreviation, you can nest <abbr> inside <dfn> (the definition element) for super-semantic goodness!

<p>
  <dfn>
    <abbr title="Hypertext Markup Language">HTML</abbr>
  </dfn>
  is the standard markup language for documents designed to be displayed in a web browser.
</p>

Why Semantic HTML is Your Best Friend 🤝

Using tags like <abbr> isn't just for looking pretty! It's about conveying meaning to machines:

Accessibility: Screen readers use semantic tags to properly interpret and communicate content to visually impaired users.
SEO: Search engine bots understand your content better, which can help with ranking.

It's our job as developers to make the web inclusive for everyone! 💛

Mobile Mystery: Where Did My Tooltip Go? 🕵️‍♀️

Uh oh! That lovely hover tooltip from title doesn't work on mobile devices (no hover state!). But don't despair, clever solutions abound!

Solution 1: Display Full Term (on Small Screens)
For smaller screens, why not just show the full term?

@media screen and (max-width: 991px) {
  abbr[title]::after {
    content: ' (' attr(title) ')'; /* Appends the full title in parentheses */
  }
}

Solution 2: Tap-to-Reveal (with tabindex="0")
Make the <abbr> focusable and reveal the full term on tap/focus!

<abbr title="Search Engine Optimization" tabindex="0">SEO</abbr>

abbr[title]:focus::after { /* Also works for :hover on desktop */
  content: ' (' attr(title) ')';
}

Mobile-friendly patterns

Show full text on small screens
Or reveal on focus (use sparingly)

✨ TL;DR: Embrace `<abbr>`! ✨

Use for abbreviations & acronyms
Always include title
Don’t rely on hover alone
Semantic HTML = better web 🌍

[Boost]

Alexandra — Thu, 19 Jun 2025 11:28:18 +0000

Alexandra

Jun 19 '25

🧠 React.ReactNode vs JSX.Element vs React.ReactElement – What's the Damn Difference?

3 min read

DEV Community: Alexandra

Understanding JavaScript Execution Context: The Foundation of Interactivity

Creating contexts

The call stack

The two phases of the context

Why hoisting happens?

let and const against hoisting

Understanding TDZ

The Scope Chain: Looking Beyond the Current Context

summary

What Are Embeddings?: How AI Knows a Cat and a Kitten Are Related ⭐

The question embeddings answer

A map of meaning

Where the numbers actually come from

Why this matters for search and recommendations

Words aren't the only thing that can be embedded

Where this shows up if you're building products

Resources

[Boost]

Tokens aren't words: what actually happens when you send a prompt

Stop Hiring a Rocket Scientist to Check If a Box Is Empty

A tale as old as 2023

The actual differences

if-statement or AI?

More examples than you asked for, because this pattern is everywhere

The cost of choosing the wrong tool

Reflect on our choices

Resources

What is a context window, actually?

AI 101 Recap

Why are there limits?

The Amnesia Problem

How RAG helps

Why longer context isn't automatically better

Resources

Does the web feel slower these days?

It's not just a feeling, but it's also not new

What AI features actually add to the weight

Why it compounds instead of replacing anything

What this means if you're building these features

Resources

Tokens aren't words: what actually happens when you send a prompt

Tokens, tokens everywhere

Step one: splitting the text

Step two: turning pieces into numbers

Fun facts of tokanization

Why this matters if you're a frontend engineer

Resources

[Boost]

Passion Lens: Discover the Passion Hidden in Your Photographs

Passion Lens: Discover the Passion Hidden in Your Photographs

Passion Lens: Discover the Passion Hidden in Your Photographs

What I Built

Demo

Code

How I Built It

Google Gemini

ElevenLabs

Memory Experience

PDF Export

Technical Stack

Challenges and Lessons

Prize Categories

Best Use of Google AI

Best Use of ElevenLabs

What’s Next

Being an engineer in the AI era

Not everything needs AI

The craft behind the code

What happens when we outsource thinking?

Building software with meaning

Epilogue

HTML Tag 📝

What it Does 🧙‍♀️

Styling Shenanigans 🎨

The Great <abbr> vs <acronym> War ⚔️ (A Brief History Lesson)

Getting Extra Semantic: <abbr> with <dfn> 📚

Why Semantic HTML is Your Best Friend 🤝

Mobile Mystery: Where Did My Tooltip Go? 🕵️‍♀️

Mobile-friendly patterns

`let` and `const` against hoisting

The question `embeddings` answer

The Great `<abbr>` vs `<acronym>` War ⚔️ (A Brief History Lesson)

Getting Extra Semantic: `<abbr>` with `<dfn>` 📚

✨ TL;DR: Embrace `<abbr>`! ✨