Forem: Ibim

The AI Bubble Is Not About AI

Ibim — Wed, 31 Dec 2025 08:19:16 +0000

The AI Bubble Is Not About AI, it is about expectations, incentives, and timing

Everyone in tech seems to agree we are in an AI bubble.

What people do not agree on is what exactly is inflated, or what happens if it deflates.

Some believe the technology itself is overhyped. Others believe the infrastructure spending is excessive. Others think the real excess is in company valuations, not capability. And a growing number of developers quietly suspect something else entirely: that expectations have simply raced far ahead of reality.

The confusion is not accidental. It is a natural side effect of a technology that is genuinely powerful, unevenly useful, and arriving faster than organisations know how to absorb it.

Bubbles usually form around something real

The word bubble tends to imply fraud or fantasy. But most historical bubbles formed around technologies that actually mattered.

Railroads transformed economies.
The internet reshaped communication and commerce.
Cloud computing changed how software is built and deployed.

In each case, the mistake was not believing the technology was important. The mistake was assuming that importance translated directly into short-term returns for everyone involved.

AI feels similar.

There is a real kernel of truth here. The models work. They are improving. They unlock capabilities that did not exist before. But that truth has been wrapped in a level of certainty, urgency, and financial expectation that no complex technology has ever lived up to on the first pass.

Infrastructure optimism versus execution reality

One of the most striking features of the current AI moment is the scale of infrastructure spending.

Data centres, GPUs, power grids, and long-term compute commitments are being built on assumptions about future demand that are difficult to verify today. The justification is often that compute is the bottleneck, and that whoever builds fastest will win.

That may turn out to be true.

But there is a difference between possible and inevitable.

Execution risk is not just technical. It is organisational, economic, and human. Even if the models continue to improve, building sustainable businesses around them requires alignment across product design, cost structure, regulation, and actual user behaviour.

History suggests those things rarely move in lockstep.

AI coding as a microcosm of the bubble

Nowhere is the gap between expectation and reality clearer than in AI assisted coding.

On paper, it looks like the perfect use case. Code is structured language. It is expensive to produce. It has clear success criteria. And in isolated tasks, AI tools can be astonishingly effective.

In practice, many developers report a more complicated experience.

AI tools excel at:

boilerplate
tests
quick prototypes
explaining unfamiliar code
fixing narrowly scoped bugs

They struggle with:

large codebases
long-term architectural consistency
context awareness
respecting project-specific conventions
knowing when they are wrong

This does not make them useless. It makes them situational.

The problem arises when productivity gains measured in controlled tasks are projected onto entire engineering workflows. The result is disappointment, confusion, and sometimes a quiet sense that something does not add up.

Productivity is harder to measure than we admit

A recurring pattern in developer feedback is perceived speed versus actual output.

Many engineers feel faster with AI tools. They move more quickly through tasks. They generate more code. They spend less time staring at a blank file.

But when measured over weeks or months, the gains are often smaller than expected. Sometimes they even reverse.

Why?

Because software development is not just typing. It is:

reasoning
debugging
reviewing
maintaining
aligning with other humans
paying down technical debt

AI can accelerate some of these steps. It can also quietly increase the load on others.

More code still has to be understood. More changes still need review. And code that looks correct but subtly violates a system’s design can be more expensive than code that was written slowly and deliberately.

Technical debt does not disappear, it shifts

One of the quieter risks in widespread AI assisted coding is the accumulation of technical debt in less obvious forms.

The code may compile.
The tests may pass.
The bugs may be fewer.

But complexity can still grow.

Verbosity increases. Patterns drift. Inconsistencies multiply. And because the output often looks polished, issues can be harder to spot early.

This is not a flaw unique to AI. It is a familiar problem in software engineering. The difference is scale and speed. AI makes it easier to accumulate debt quickly, especially under pressure.

The cultural amplification effect

AI tools do not exist in a vacuum. They amplify the culture they are introduced into.

In teams with:

strong conventions
clear architectural principles
disciplined review processes

AI can be genuinely powerful.

In teams without those things, it often magnifies existing problems.

This is why adoption outcomes vary so widely. The tool is the same. The context is not.

Why this still does not mean the bubble is fake

None of this implies that AI is a fad.

It implies that the timeline has been misunderstood.

AI is not replacing software engineers overnight. It is changing what software engineering looks like, unevenly and gradually. Some workflows will be transformed quickly. Others will resist change for good reasons.

The danger is not believing in AI.
The danger is believing that belief alone guarantees returns.

A more grounded way to think about the AI moment

Instead of asking whether we are in an AI bubble, a better question might be:

Where are expectations being priced as certainty?

That framing allows for nuance.

It leaves room for:

real breakthroughs

real failures

uneven impact

long adjustment periods

And it reminds us that bubbles do not only burst. Sometimes they deflate slowly, leaving behind infrastructure, knowledge, and capabilities that matter long after the hype fades.

AI is powerful.
AI is imperfect.
AI is early.

The tension we are seeing is not between truth and illusion, but between possibility and impatience.

If there is a bubble, it is not one belief. It is many overlapping assumptions, moving at different speeds, held by people with different incentives.

Understanding that may be more useful than predicting exactly when anything pops.

Why push and pop Feel Natural and shift Does Not

Ibim — Mon, 29 Dec 2025 00:41:50 +0000

What JavaScript arrays quietly optimise for

When I first started working with JavaScript arrays, push and pop felt immediately intuitive.

You add something to the end.
You remove something from the end.
Nothing surprising happens.

Then I started using shift.

It did exactly what it promised. It removed the first element. But it always felt heavier. Slower. Slightly uncomfortable in a way that was hard to articulate.

At first, I assumed that feeling was just intuition without substance.

It was not.

Arrays look simple until you change the front

Most of us begin with a very simple mental model of arrays. A neat list of items laid out in order, ready to be modified wherever needed.

That model mostly works until you start modifying the front of the array.

This is where an important detail becomes visible:

JavaScript arrays are optimised for the end, not the beginning.

Once you understand that, the difference between push, pop, and shift stops feeling arbitrary.

Why push feels effortless

When you call push, the engine already knows where the next element belongs.

There is a clear end.
There is a known length.
Nothing else needs to move.

The value is added, the length is updated, and execution continues.

From the runtime’s point of view, this is a cooperative operation. It works with the structure of the array rather than against it.

That is why push feels cheap and predictable, even as arrays grow.

Why pop feels just as natural

Pop is simply the reverse operation.

The last element is removed.
The length is reduced.
No reorganisation is required.

Again, nothing else in the array needs to change.

Both push and pop operate at the boundary of the structure. They touch as little as possible, and that efficiency is reflected in how they feel to use.

Why shift feels different

Shift removes the first element.

On the surface, that sounds just as simple.

Underneath, it is not.

Removing the element at index 0 means everything else has to move. Every remaining item must be reassigned a new index. What used to be at 1 becomes 0. What used to be at 2 becomes 1. And so on.

The array has to be reindexed.

This is not a quirk. It is a direct consequence of how arrays work and how indexed access is maintained.

Once you realise this, the discomfort around shift makes sense. It is asking the engine to do significantly more work.

You can feel cost before you can name it

You do not need formal performance terminology to notice this difference.

You feel it when:

arrays grow larger
operations happen repeatedly
responsiveness starts to matter

Operations at the end scale quietly.
Operations at the beginning scale loudly.

This is one of those cases where understanding begins with experience, not vocabulary. Later, when performance concepts are introduced more formally, they feel familiar because the behaviour has already been observed.

Arrays are structured objects, not abstract lists

Another helpful mental shift is remembering that JavaScript arrays are not abstract containers. They are structured objects with numeric keys and a length contract.

Each index is a property. Changing the front of the array means changing many properties at once.

Seen this way, shift is no longer a sibling of pop. It is a fundamentally different operation with very different implications.

When shift is still the right choice

None of this means shift is wrong.

It means it should be used deliberately.

If:

the array is small

the operation is infrequent

clarity matters more than raw efficiency

Then shift is perfectly acceptable.

Understanding cost is not about avoiding certain methods. It is about choosing them consciously rather than accidentally.

The real lesson here

The most important takeaway is not about any specific array method.

It is about learning to ask a better question.

Not:

“Does this work?”

But:

“What does this force the runtime to do?”

That question scales far beyond arrays. It shows up again with:

string manipulation
object copying
state updates
performance issues that only appear under load

Once you start asking it, JavaScript stops feeling unpredictable and starts feeling explainable.

Push and pop feel natural because they align with how JavaScript arrays are built to work.

shift feels awkward because it asks the structure to fight itself.

Neither is wrong.

But understanding why they feel different is one of those small moments where JavaScript stops being a collection of methods and starts being a system you can reason about.

That is a meaningful learning moment.

JavaScript Closures: The Quiet Mechanism Running Your Code

Ibim — Sun, 28 Dec 2025 05:26:44 +0000

I avoided closures for longer than I care to admit.

Not deliberately. I just kept telling myself I understood them because I could repeat the usual line: “a closure is a function that remembers its lexical scope.” That sentence sounds convincing. It is also not enough.

Closures only really make sense once you stop treating them as a concept to memorise and start seeing them as a behaviour your code exhibits.

This article is not a definition dump. It is an attempt to explain closures the way they actually show up in real JavaScript code and why they matter far more than most beginners realise.

A closure is not created when you write a function

This is where most explanations subtly mislead people.

Closures are not created when a function is declared. They emerge when a function is executed and continues to reference variables from an outer scope that would otherwise be gone.

Consider this:

function createCounter() {
  let count = 0;

  return function () {
    count++;
    return count;
  };
}

const counter = createCounter();

At first glance, it looks like ==count== should disappear as soon as ==createCounter== finishes running. But it does not. The inner function still has access to it.

Why?

Because JavaScript does not copy values into functions. It keeps references to the environment in which the function was created.

That environment, the lexical environment, is what we casually call a closure.

Closures are about memory, not syntax

One of the most useful mental shifts I made was realising that closures are fundamentally a ==memory model==, not a syntax feature.

The JavaScript engine keeps variables alive only as long as something can still reach them.

In the example above:

==count== is still reachable

therefore it stays in memory

therefore its value persists between function calls

That is it. No magic.

Once you see closures this way, a lot of confusing behaviour suddenly becomes predictable.

Why closures feel confusing at first

Closures are hard because they break an intuitive rule many people unconsciously follow:

“When a function finishes, everything inside it disappears.”

That rule is mostly true, until it is not.

Closures are the exception that proves the rule. They force you to think about ==who still has a reference== to what.

This is also why closures are a common source of bugs, especially in loops.

for (var i = 0; i < 3; i++) {
  setTimeout(() => {
    console.log(i);
  }, 1000);
}

People expect ==0, 1, 2==.

They get ==3, 3, 3==.

Not because JavaScript is broken, but because all three functions close over the ==same variable==, not three different values.

Once you understand closures, this behaviour stops being surprising.

Closures are everywhere, even when you do not notice them

If you have ever:

used ==useState= in React
written a callback
used ==setTimeout== or ==setInterval==
worked with event listeners
implemented currying or partial application

you have already used closures.

Frameworks lean heavily on closures because they allow state to exist without global variables. That is an enormous design advantage.

React hooks, for example, rely on closures to “remember” values between renders while still keeping functions pure in appearance.

Closures enable encapsulation without classes

Before ES6 classes became popular, closures were one of the main ways to create private state in JavaScript.

Even today, many developers prefer closures over classes for simple encapsulation:

function createBankAccount() {
  let balance = 0;

  return {
    deposit(amount) {
      balance += amount;
    },
    getBalance() {
      return balance;
    }
  };
}

Here, ==balance== is completely inaccessible from the outside. There is no keyword for privacy. The privacy emerges naturally from the closure.

This pattern still holds up remarkably well.

The downside: closures can keep things alive too long

Closures are powerful, but they are not free.

Because closures keep references alive, they can accidentally keep large objects in memory longer than necessary. This is especially relevant in long-running applications like browsers or servers.

Memory leaks caused by closures are subtle and often misunderstood. The problem is not closures themselves, but forgetting that what you reference stays alive.

Understanding closures helps you reason about memory usage far better than memorising garbage collection rules.

A better way to explain closures (in one sentence)

If I had to explain closures in one sentence now, it would be this:

A closure is what happens when a function keeps a live connection to variables that existed when it was created.

That sentence is not poetic, but it is accurate.

Reading further and deepening your understanding

If you want to go deeper, here are some genuinely useful directions to explore:

MDN’s explanation of lexical environments and execution contexts
Articles that explore JavaScript engine internals (V8 in particular)
Functional programming discussions on closures in Scheme and Lisp
Academic papers on lexical scoping and environment models (arXiv is useful here)

Closures are not unique to JavaScript. Understanding them well makes learning other languages easier.

Final thoughts

Closures are not something you “learn once”.

They are something you gradually notice more clearly the longer you write JavaScript.

At some point, they stop being a mysterious interview topic and start becoming a quiet, dependable tool you rely on without thinking.

And that is usually the sign that you finally understand them.

JavaScript Closures Took Me a While to Understand and That Is Okay

Ibim — Sat, 27 Dec 2025 21:19:16 +0000

A reflection on closures, memory, and behaviour

For a long time, I told myself I understood JavaScript closures.

I could repeat the definition. I knew they were related to scope. I had even used them in projects without thinking too much about it. But if I am being honest, none of that meant they truly clicked.
And that is okay.

Closures are one of those ideas in JavaScript that do not reward memorisation. They reward time, exposure, and the uncomfortable moments where code behaves consistently while completely violating your expectations.

For me, that moment came in the form of a bug.

The bug that forced me to actually understand closures

The moment closures finally made sense did not come from documentation. It came from chasing behaviour that felt wrong, even though it was technically correct.

I was looping over a list and attaching handlers. Nothing clever. Nothing experimental. Just everyday JavaScript.

But every handler behaved as if it had forgotten which item it belonged to.

I assumed I had made a mistake. Then I assumed some shared state was being overwritten. I added logs. I rewrote the function. The behaviour did not change.

Every handler was seeing the same value.

A simplified version of the problem looked like this:

for (var i = 0; i < 3; i++) {
  setTimeout(() => {
    console.log(i);
  }, 1000);
}

I expected to see 0, 1, and 2.

What I saw was 3, printed three times.

That was the moment I realised I was not dealing with a logic error. I was dealing with a misunderstanding of how JavaScript remembers things.

Each callback was not getting its own copy of the value. They were all holding onto the same variable. By the time the function actually ran, that variable had already changed.

Once I saw that, the behaviour stopped being mysterious. It was predictable. It was even reasonable.

The bug disappeared the moment I stopped asking why JavaScript was doing this and started asking what the function was still connected to.

That was the point where closures stopped being a definition and became a mental model.

Closures are about environments, not syntax

Closures are often introduced as a feature of functions. That framing is convenient, but it is incomplete.

Closures are not something you turn on by writing functions a certain way. They emerge from how JavaScript manages environments over time.

When a function is created, it is associated with the environment in which it was defined. That environment contains bindings, not frozen values. When the function later executes, it resolves those bindings by walking outward through its lexical environments.

A closure exists when that environment remains accessible beyond the lifetime of the original function call.

Why closures persist after functions return

A common misconception is that closures store values. They do not.

What persists is reachability.

If a function still has access to a variable, that variable remains reachable. If it remains reachable, it stays alive in memory. Garbage collection does not care where a variable was declared. It only cares whether something can still reach it.

Once you see closures as a consequence of reachability rather than a special feature, many confusing behaviours stop feeling arbitrary.

Closures explain bugs before they explain features

Most developers encounter closures through bugs long before they use them deliberately.

Asynchronous callbacks, event handlers, and timers all expose the same underlying behaviour. Closures capture variables, not moments in time. Multiple functions can close over the same binding. Delayed execution simply makes this visible.

Understanding this shifts closures from being an interview topic to being a practical debugging tool.

Closures are foundational to encapsulation

Before modern class syntax and private fields, closures were the primary way JavaScript achieved encapsulation.

Even now, they offer something classes cannot always provide cleanly. Privacy without exposure.

A variable that exists only inside a function scope and is accessed only through returned functions is fundamentally inaccessible from the outside. No keyword is required. The structure enforces it naturally.

Closures support intentional design by keeping state local and controlled.

Closures and functional composition

Closures become especially powerful when combined with higher order functions.

Functions that return functions, partially apply arguments, or generate specialised behaviour all rely on closures. This is not an advanced trick. It is a natural extension of how environments work.

Once closures stop feeling mysterious, patterns like currying and composition start to feel obvious rather than clever.

The real cost of closures

Closures are often blamed for performance problems, but that concern is usually misplaced.

The real cost of closures is responsibility.

If you close over large objects, DOM nodes, or long lived references unintentionally, you extend their lifetime. That can lead to memory retention that is difficult to spot.

This is not a reason to avoid closures. It is a reason to understand them well enough to use them deliberately.

A more accurate mental model

After spending time with closures in real code, the most accurate mental model I have found is this:

A closure is not something you create.
A closure is something that remains.

It is the result of:

lexical scoping
name resolution
reference reachability
delayed or repeated execution

When these conditions align, a closure exists.

Why it is okay that closures take time

Closures sit below the surface of JavaScript. You can write code for years without naming them explicitly. That does not mean you are not using them. It means the language is doing its job.

Understanding closures deeply requires encountering unexpected behaviour, tracing execution mentally, and thinking about memory rather than just output.

That is not beginner work.

If closures took you a while to understand, that is not a failure. It is part of becoming fluent.

They took me a while too.

And that is okay.

Further reading

The ideas in this article were shaped over time by reading and experience. These resources were especially helpful:

JavaScript from Beginner to Professional. For practical reinforcement of function scope and nested behaviour.
Eloquent JavaScript (4th Edition) by Marijn Haverbeke. For building intuition around nested scope and environments.
Clean Code in JavaScript by James Padolsey. For connecting closures to encapsulation, maintainability, and intentional design.

Synthetic Data Is Not About Replacing Reality. It Is About Questioning It.

Ibim — Sat, 20 Dec 2025 00:23:33 +0000

There is a quiet moment many of us reach when working with data and machine learning.

The model performs well.
The metrics look reassuring.
The pipeline feels complete.

And yet, something does not sit right. Not because the system is broken. But because we are not convinced it is fair.

This is where synthetic data becomes more than a technical tool.
It becomes a way to ask uncomfortable questions.

The Hidden Problem With Real World Data

We often talk about real world data as if it is neutral. It is not.

Hiring data reflects decades of unequal access to education, employment, and opportunity. Healthcare data reflects who was diagnosed, who was believed, and who was ignored. Behavioural datasets reflect cultural norms and economic pressures.

When AI systems are trained purely on historical data, they do not learn fairness. They learn patterns. And many of those patterns are shaped by inequality. This is not a philosophical argument. It is a statistical one.

What Synthetic Data Actually Is

Synthetic data is artificially generated data that mimics the structure and statistical properties of real datasets, without representing real individuals. It is not created for humans to read. It is created for systems to learn from, or to be tested against. This distinction matters.

Synthetic CVs are not meant to apply for jobs.
Synthetic patient records are not meant to describe real people.
Synthetic handwriting samples are not meant to replace human writing.

They exist to allow experimentation without harm.

Synthetic Data as a Controlled Lens

One of the most powerful properties of synthetic data is control. In the real world, you cannot ethically do the following:

Take a job applicant.
Change only their name.
Or their age.
Or a single line mentioning a disability.

Then re-run the application. With synthetic data, you can.

Research on synthetic CV generation for fairness testing shows how artificial applicant profiles can be created where all variables are held constant except one. This allows researchers and practitioners to observe how automated hiring systems respond to specific demographic changes without involving real candidates or breaching privacy obligations (Saldivar, Gatzioura, Castillo, 2025).

When outcomes change under these controlled conditions, bias becomes visible. Not as an accusation. But as behaviour.

Lessons From Healthcare and Rare Disease Research

Some of the most mature work on synthetic data comes from healthcare. In rare disease research, data is scarce, sensitive, and heavily regulated. Sharing real patient records is often impossible.

Research into privacy preserving synthetic data generation shows how generative models can create realistic patient profiles that allow analysis, model training, and collaboration without exposing personal information (Mendes, Barbar, Refaie, 2025).

But these studies also highlight something important.

Synthetic data reflects the quality of the data it is generated from. If the original dataset is biased or incomplete, the synthetic data will inherit those weaknesses. This lesson transfers directly to hiring systems. Synthetic data is not automatically fair. It must be designed with intent.

Why Representation Matters More Than Volume

Another important insight comes from handwriting recognition research.

Some languages and writing styles are poorly represented in public datasets. As a result, models perform well for some populations and poorly for others.

Research on handwriting recognition shows that large scale synthetic datasets are often required to capture enough variation for models to generalise properly, especially when real data is limited (Pham Thach Thanh Truc et al., 2025). The takeaway is simple.

If certain groups are missing from the data, the system will struggle with them. This applies to CVs, medical records, and any system that interacts with human diversity.

What Robotics Teaches Us About Synthetic Worlds

Robotics offers a useful warning.

In robotic learning, simulation is widely used because collecting real world data is expensive and slow. However, research on robotic bin packing shows that systems trained only in idealised synthetic environments often fail when deployed in real conditions (Wang et al., 2025).

Why?

Because reality is messy.

Objects behave unpredictably.
Lighting changes.
Constraints shift.

The same principle applies to synthetic data used for fairness testing. If synthetic CVs are too clean, too linear, or too idealised, fairness evaluations become misleading. Real careers are rarely neat.

People change paths.
Take breaks.
Move countries.
Care for others.

Synthetic data must reflect this complexity if it is to reveal meaningful bias.

Synthetic Data Does Not Eliminate Bias Automatically

This point is worth stating clearly. Synthetic data does not fix bias on its own. Generative models learn patterns. They do not understand ethics or social context. If historical data encodes inequality, a naive synthetic generator will reproduce it.

This is why recent research emphasises constraints, validation, and domain knowledge when generating synthetic datasets, particularly in sensitive domains such as healthcare and employment (Mendes et al., 2025).

Synthetic data is a tool.
Fairness depends on how it is used.

Why Synthetic Data Forces Honesty

There is something quietly powerful about synthetic data.

It removes excuses.

When systems can be tested under controlled conditions, bias can no longer hide behind noise or complexity.

If a hiring model behaves unfairly when only one variable is changed, the issue is structural.

Synthetic data does not accuse.
It reveals.

And that is precisely why it matters.

Looking Ahead

Synthetic data is often described as artificial.

But its impact is real.

It shapes how we test AI systems.
How we protect privacy.
How we detect bias.
How we imagine fairer alternatives.

Used carelessly, it can reinforce historical inequality.
Used thoughtfully, it can help us challenge it.

Synthetic data is not about replacing reality.

It is about questioning the systems we build from it.

References

Saldivar, J., Gatzioura, A., Castillo, C. (2025).
Synthetic CVs to Build and Test Fairness-Aware Hiring Tools.
ACM Transactions on Intelligent Systems and Technology.

Mendes, M., Barbar, F., Refaie, A. (2025).
Synthetic Data Generation: A Privacy-Preserving Approach to Accelerate Rare Disease Research.
Frontiers in Digital Health.

Pham Thach Thanh Truc et al. (2025).
HTR-ConvText: Leveraging Convolution and Textual Information for Handwritten Text Recognition.
arXiv preprint.

Wang, Z. et al. (2025).
RoboBPP: Benchmarking Robotic Online Bin Packing with Physics-Based Simulation.
arXiv preprint.

MIT Technology Review
What synthetic data is and why it matters for AI
https://www.technologyreview.com

Nature News and Comment
How artificial data could help address bias in AI
https://www.nature.com

OECD AI Policy Observatory
Fairness, transparency, and accountability in AI
https://oecd.ai

JavaScript Did not Crash. That Does not Mean It is Fine.

Ibim — Sat, 01 Nov 2025 20:51:57 +0000

When you first start learning to code, you usually expect two outcomes:

1. It works
2. It explodes and tells you what went wrong.

JavaScript has a secret third option:

3. It does something questionable, keeps going, and says nothing.

That quiet behaviour is what I mean when I say: JavaScript often fails silently.

Your code can be doing the wrong thing, and the language will not always warn you. In this article, I want to show you how that happens, why it happens, and a few habits that help you protect yourself from it.

1. JavaScript Will "Fix" Your Types For You

JavaScript is very eager to guess what you meant.

For example:

const result = "12" / 3;
console.log(result); // 4

Let us pause there.

"12" is a string. It is text. In many other languages, doing maths on text would throw an error.

JavaScript does not throw. It says, basically: “Oh, you probably meant the number 12,” quietly converts the string to a number, and gives you 4.

No warning. No complaint. It just proceeds.

Now look at this one:

const result2 = "12" + 3;
console.log(result2); // "123"
Same "12", same 3, totally different behaviour.

Why?

With / (division), JavaScript says “this is maths” and does number maths.

With +, JavaScript says “this might be string joining” and glues them together into "123".

In other words: the operator you choose can silently change how your data is treated.

Your program technically "works", but maybe not in the way you thought.

This automatic behaviour is called type coercion. JavaScript tries to convert things into a type that allows the operation to continue instead of stopping the program.

This is helpful sometimes. It also means you can ship a logic bug without realising it.

2. You Can Create a Global Variable By Accident

Watch this:

accidentalValue = 10;
console.log(accidentalValue); // 10

Look closely. There is no let, no const, no var. You never declared accidentalValue.

In many languages, this would immediately throw something like “ReferenceError: variable not defined”.

In normal (non-strict) JavaScript, it quietly creates a global variable with that name. The code continues.

So a pure mistake (a typo, or you forgot l`et) becomes part of your program's state.

That is dangerous because:

You did not plan for it.

It can leak into other parts of the code.

You may not realise where it came from.

Now compare that to strict mode:

"use strict";

accidentalValue = 10; // ReferenceError: accidentalValue is not defined

With "use strict";, JavaScript finally shouts. This is the behaviour most people expect by default, but it is not the default in older or looser code.

So here is the key point:
Without strict mode, JavaScript sometimes lets you make a mistake quietly and keeps going.

3. Maths Can Go Wrong Without Throwing an Error

Consider this:

function getAverage(numbers) {
  const total = numbers.reduce((sum, n) => sum + n);
  return total / numbers.length;
}

console.log(getAverage([])); // NaN

We passed in an empty array.

Mathematically, “average of nothing” does not make sense. Some languages will force you to handle that case.

JavaScript does not force you. It just returns NaN.

NaN means “Not a Number”, and it is JavaScript’s way of saying “this calculation is not valid”. But it does not throw. The code still runs.

Now imagine this in an app:

const averageScore = getAverage(userScores);

if (averageScore > 80) {
  unlockBadge();
}

If averageScore is NaN, then averageScore > 80 is always false. So maybe unlockBadge() never runs, and you are sitting there thinking: “Why is this feature broken?” with no obvious error message.

So again: not loud, just quietly wrong.

4. Missing Data Just Becomes `undefined`

Let us say you have:

const user = {
  name: "Amina"
};

console.log(user.age); // undefined

There is no age on user. In many languages, asking for something that does not exist would crash or complain loudly.

JavaScript simply answers: undefined.

No error. No warning. Just “I do not have that, so here is undefined.”

Now here is why that is sneaky:

If you expected user.age to be there, you might assume undefined means “it exists but it's empty”.

But that is not true. It just is not there at all.

This is the kind of small difference that can break logic later without an obvious moment where the program shouts “something is wrong”.

Even worse with typos:

const profile = {
  displayName: "Riya"
};

console.log(profile.dispayName); // undefined (typo!)

You misspelled displayName as dispayName. You do not get an error about the typo. You just quietly get undefined.

Then you pass that undefined around, and the bug is now somewhere else in your code.

5. Equality Can Lie To You

JavaScript actually has two main equality operators: == and ===.

They are not the same.

== is “loose equality.” It will try to convert values in order to compare them. This sounds friendly. It is also how you get silent bugs like this:

console.log(false == 0); // true
console.log("" == 0);    // true
console.log("0" == 0);   // true
console.log(null == undefined); // true

Look at the second one.

"" == 0 // true

An empty string is considered equal to the number zero.

Now imagine you do this in your code:

const userInput = "";

if (userInput == 0) {
  console.log("User typed zero.");
}

That if block runs, even though the user did not type 0. They typed nothing.

This is a bug pretending to be valid behaviour.

Now compare with strict equality:

console.log(false === 0); // false
console.log("" === 0);    // false
console.log("0" === 0);   // false
console.log(null === undefined); // false

=== (triple equals) does not try to convert the values for you. It checks both value and type. This makes weird behaviour much harder to hide.

So, general rule:
Use === unless you have a very specific reason not to.

6. Why Does JavaScript Behave Like This?

Short version: history.

JavaScript was created in the 1990s to run inside web browsers. It was designed very quickly, and the target user was not a full-time software engineer. It was “let normal people add behaviour to web pages.”

In that world, if JavaScript crashed hard every time something was off, entire web pages would just break. That would be a terrible experience for people browsing the web.

So the language leaned toward:

"Keep the page running."

"Try to guess what they meant."

"Do not shout unless you absolutely must."

Also, early JavaScript did not even have proper exception handling. Exceptions became standard later on (in ECMAScript 3). Before that, failing loudly in a controlled way was not really part of the design.

Now, years later, a lot of that behaviour is still around. Even if some of it is confusing, you cannot just remove it, because it would instantly break millions of existing websites.

That is the cost of being the language of the web: every old decision becomes permanent.

7. How To Protect Yourself (Practical Tips)

You do not have to memorise the entire JavaScript spec to be safe. You just need a few habits that make silent problems louder.

1. Use `===` instead of `==`

if (userInput === 0) {
  console.log("User typed zero.");
}

Now JavaScript will not do any behind-the-scenes conversion. If the types do not match, it will simply return false.

2. Use `"use strict"`;

At the top of your file or function, write:


"use strict";

Ths will force JavaScript to complain when you do dangerous things like create accidental globals.

Without strict mode:


accidentalValue = 10; // ReferenceError

With strict mode:


"use strict"
accidentalValue = 10; //ReferenceError

This is good. You want that error early.

3. Check numbers that come from user input or division

const result = someCalculation();

if (!Number.isFinite(result)) {
  console.error("Result is not a normal number:", result);
}

This catches cases like Infinity, -Infinity, and NaN right away, instead of letting them poison later logic.

4. Treat `undefined` as a signal, not “oh well”

If you expected the data to exist, throw or log where it first goes missing.

For example:

if (user.age === undefined) {
  console.error("User age is missing, expected a value.");
}

Make the problem loud on purpose.

Final Thought

JavaScript was designed to be friendly and forgiving. It tries very hard not to break the page. That is nice for users.

But for you, as a developer, that also means this:
Your code can be wrong and keep running.

This is why debugging JavaScript sometimes feels like guessing in the dark. There is no big red alarm. Just slightly “off” behaviour.

So any time something feels off, add a console.error(...) or a guard and make the bug noisy early.

In JavaScript, silence is not always safety. Sometimes it is the bug.

Imperative versus Declarative in Flutter

Ibim — Wed, 20 Aug 2025 08:38:06 +0000

Summary

There are two common ways to build screens. Imperative code tells the computer exactly what to do, step by step. Declarative code describes what the screen should look like for the current state, and the framework updates it for you. Flutter encourages the declarative way. This post keeps things simple, shows tiny examples, and gives a clear path to try the ideas on your own device.

A calm starting point

Imagine a small screen that shows a list of books. There is a loading spinner, and sometimes an error message. On a busy day the old list stays visible under the error card. You fix one path, another breaks. It feels fragile. A change of style can help.

Two ways to think

Imperative: change what already exists. Show the spinner, hide the list, replace the text.
Declarative: say what the screen should be for this state. If loading, return a spinner. If ready, return a list.

An everyday picture helps. If a friend asks for directions to your flat:

Imperative sounds like this. Turn left at the bakery, walk past the park, take the third right, press the second buzzer.
Declarative sounds like this. Number 18, Willow Road, the blue door.

One is a list of steps. The other is the intended result.

A small imperative example

This short example is from the classic Android view system. You flip visibility by hand and push data into the list.

Kotlin

// Small, imperative example in Kotlin

sealed interface ScreenState
object Loading : ScreenState
data class Ready(val items: List<String>) : ScreenState

fun render(
  state: ScreenState,
  spinner: View,
  list: RecyclerView,
  adapter: ListAdapter<String, *>
) {
  spinner.visibility = if (state is Loading) View.VISIBLE else View.GONE
  list.visibility    = if (state is Ready)   View.VISIBLE else View.GONE

  if (state is Ready) {
    adapter.submitList(state.items)
  }
}

It is clear when there are only two states. It becomes easy to miss a line when more states appear. That is when yesterday’s content sometimes remains visible. That approach works, but it does not scale well. Let us now see how Flutter encourages a different style.

A small declarative example with setState

Now the same idea with Flutter. We describe the whole screen from the current state. There is a single source of truth, the screen value.

How to try this now

"Create a new Flutter project."
"Replace lib/main.dart with the code below."
"Run the application and tap the button."

import 'package:flutter/material.dart';

// Two simple states for the screen
enum Screen { loading, ready }

// A tiny value object for books
class Book {
  final String title;
  final String author;
  const Book(this.title, this.author);
}

void main() => runApp(const MaterialApp(home: BooksDemo()));

class BooksDemo extends StatefulWidget {
  const BooksDemo({super.key});
  @override
  State<BooksDemo> createState() => _BooksDemoState();
}

class _BooksDemoState extends State<BooksDemo> {
  Screen screen = Screen.loading;
  List<Book> items = const [];

  Future<void> load() async {
    setState(() => screen = Screen.loading);
    await Future<void>.delayed(const Duration(seconds: 1));
    setState(() {
      items = const [
        Book('Practical Flutter', 'Sara Conte'),
        Book('Patterns for Mobile', 'Leo Ahmed'),
      ];
      screen = Screen.ready;
    });
  }

  @override
  void initState() {
    super.initState();
    load(); // start loading as soon as the screen appears
  }

  @override
  Widget build(BuildContext context) {
    // Describe the whole screen from the current state
    if (screen == Screen.loading) {
      return const Scaffold(
        body: Center(child: CircularProgressIndicator()),
      );
    }

    // Ready state
    return Scaffold(
      appBar: AppBar(title: const Text('Books')),
      body: ListView.builder(
        itemCount: items.length,
        itemBuilder: (_, i) => ListTile(
          title: Text(items[i].title),
          subtitle: Text('By ${items[i].author}'),
        ),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: load,
        child: const Icon(Icons.refresh),
      ),
    );
  }
}

What to notice

The first thing to notice is that there is no manual show or hide. You are not juggling visibility flags or remembering what was visible before. Instead, you simply describe the tree as it should look right now, and Flutter handles the rebuilding for you.

Another detail is the absence of leftover state. Because you always return the correct tree for the current value, yesterday’s content does not accidentally leak into today’s frame.

You might also see that this approach reduces side effects. You are not nudging old widgets into place, you are just returning the correct shape for the moment.

And finally, it becomes easier to test. You can say: given this state, I expect a spinner. Or: given that state, I expect this text or a certain number of tiles. That clarity is a direct payoff of the declarative style. The key point is that you focus on describing the state, not on hiding or showing parts by hand. With that in mind, let us try a small example where the user taps a switch.

A very gentle user input example

Here is a tiny settings screen. It has a dark mode switch. When the switch changes, the app theme changes. No manual updates to labels. No hidden toggles.

import 'package:flutter/material.dart';

void main() => runApp(const ThemeDemo());

class ThemeDemo extends StatefulWidget {
  const ThemeDemo({super.key});
  @override
  State<ThemeDemo> createState() => _ThemeDemoState();
}

class _ThemeDemoState extends State<ThemeDemo> {
  bool dark = false;

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      themeMode: dark ? ThemeMode.dark : ThemeMode.light,
      theme: ThemeData.light(),
      darkTheme: ThemeData.dark(),
      home: Scaffold(
        appBar: AppBar(title: const Text('Settings')),
        body: ListTile(
          title: const Text('Dark mode'),
          trailing: Switch(
            value: dark,
            onChanged: (v) => setState(() => dark = v),
          ),
        ),
      ),
    );
  }
}

The widget tree is a clear reflection of state. If dark is true, the dark theme is used. If it is false, the light theme is used.

A simple form that reacts to state

This shows how a small form can feel declarative. The message appears when the name is too short. There is no manual show or hide scattered around.

class NameForm extends StatefulWidget {
  const NameForm({super.key});
  @override
  State<NameForm> createState() => _NameFormState();
}

class _NameFormState extends State<NameForm> {
  String name = '';

  @override
  Widget build(BuildContext context) {
    final isValid = name.trim().length >= 3;

    return Padding(
      padding: const EdgeInsets.all(16),
      child: Column(mainAxisSize: MainAxisSize.min, children: [
        TextField(
          decoration: const InputDecoration(labelText: 'Your name'),
          onChanged: (v) => setState(() => name = v),
        ),
        const SizedBox(height: 8),
        if (!isValid)
          const Text('Please enter at least three characters',
              style: TextStyle(color: Colors.red)),
        const SizedBox(height: 8),
        ElevatedButton(
          onPressed: isValid ? () {} : null,
          child: const Text('Continue'),
        ),
      ]),
    );
  }
}

The button enables itself when the state is valid. The error text appears only when needed. Clear and predictable.

Key differences you can feel

Readability: Declarative code reads like a small list of states. Loading, ready, failed. The intent is visible.
Single source of truth: Keep a single state value. The tree is built from that value. Old values do not leak into new frames.
Fewer side effects: You are not nudging old widgets into shape. You are returning the correct shape for now.
Easier testing: You can say, given this state, I expect a spinner, or this text, or a certain number of tiles.

When to choose which

Small, local screens. Use the setState function. It is simple and fine.
Shared or cross screen state. Move state into a small model with Provider or Riverpod.
Many transitions and tricky flows. Consider Bloc for explicit events and clearer steps.

If you are unsure, begin with the setState function. When the widget starts to feel busy, lift state into a model. You will feel the difference.

A gentle way to migrate an old screen

Write down the states. Loading, empty, ready, failed.
Create one state value and a single if or switch that returns the right body.
Extract small helper widgets for each branch.
Remove old show or hide code one piece at a time.
Add an explicit empty state if the list can be empty. That small decision prevents confusion later.

This is steady work. It pays off quickly.

Takeaways you can use today

Describe the screen from state rather than patching it.
Keep a single source of truth.
Start small with the setState function. Lift state into a model when needed.
Name states up front. It saves time and reduces accidental drift.

Flutter’s declarative style can feel unusual at first, but once you start, you will likely find your code easier to read, test, and grow. Start small, keep a single source of truth, and let the framework do the heavy lifting.

References:

Navigating State and Effects in React: A Practical Guide

Ibim — Wed, 30 Jul 2025 15:02:19 +0000

Have you ever built a simple counter in React and thought there must be a better way to handle updates and side effects? I certainly have. When I first encountered the use of state and effects in React, it felt a little magical, and at times a bit opaque. In this short guide I will walk you through a hands‑on example that illustrates how state and effects play together, from the perspective of a developer who is not yet an expert but keen to level up.

Why State Matters
State lets you store values that change over time, for example a score in a game or the number of unread messages. In React you declare state in a function component with a hook. Here is a simple counter:

import React, { useState } from 'react';

function Counter() {
  const [count, setCount] = useState(0);

  function handleClick() {
    setCount(count + 1);
  }

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={handleClick}>
        Click me
      </button>
    </div>
  );
}

export default Counter;

Here the effect runs only when the count changes. That small addition demonstrates how React keeps the user interface and external systems in sync.

How It Flows
Let us look at a simple sequence diagram so you can picture what happens under the hood.

That diagram shows the chain of events from a user click to the effect that updates the document title.

Next Steps
Give this code a spin. Tinker with the dependency array of the effect hook and see what happens when you omit it or add other variables. Try adding a second effect that logs values to the console.

Forem: Ibim

The AI Bubble Is Not About AI

Why push and pop Feel Natural and shift Does Not

JavaScript Closures: The Quiet Mechanism Running Your Code

JavaScript Closures Took Me a While to Understand and That Is Okay

Synthetic Data Is Not About Replacing Reality. It Is About Questioning It.

JavaScript Did not Crash. That Does not Mean It is Fine.

JavaScript has a secret third option:

1. JavaScript Will "Fix" Your Types For You

Why?

2. You Can Create a Global Variable By Accident

3. Maths Can Go Wrong Without Throwing an Error

4. Missing Data Just Becomes undefined

5. Equality Can Lie To You

6. Why Does JavaScript Behave Like This?

7. How To Protect Yourself (Practical Tips)

1. Use === instead of ==

2. Use "use strict";

3. Check numbers that come from user input or division

4. Treat undefined as a signal, not “oh well”

Imperative versus Declarative in Flutter

Summary

A calm starting point

Two ways to think

A small imperative example

Kotlin

A small declarative example with setState

A very gentle user input example

A simple form that reacts to state

Takeaways you can use today

References:

Navigating State and Effects in React: A Practical Guide

4. Missing Data Just Becomes `undefined`

1. Use `===` instead of `==`

2. Use `"use strict"`;

4. Treat `undefined` as a signal, not “oh well”