DEV Community: djuleayo

Why You Must Revisit the Stack Data Structure in the Age of AI

djuleayo — Sat, 24 Jan 2026 07:22:50 +0000

Why You Must Revisit the Stack Data Structure in the Age of AI Link to heading

With the rise of AI-assisted coding, execution has become cheap.

You can let the AI do the wiring.
What you cannot delegate is the choice of abstractions.

And that changes everything.

If you choose the right abstractions, your system scales.
If you don’t, you don’t get “bad code” — you get semantic debt:
a pile of spaghetti whose behavior you no longer understand.

That’s why data structures matter more today than they did before. Not because you must be able to implement them, but because you must understand the semantic consequences of choosing one.

Those consequences often cascade far beyond what you intended.

Let’s see this with the simplest example possible.

The Stack Is Not Just a Stack Link to heading

A stack is one of the simplest data structures we have. So simple, in fact, that it exists physically in hardware.

CPUs implement stack pointers
Operating systems allocate a stack per process
Languages expose it implicitly via function calls and scopes

In C-like languages, opening a {} opens a stack frame. When you exceed stack memory, the OS kills your program. Even Stack Overflow is named after this exact failure mode.

You cannot write a program without a stack.

So far, nothing surprising.

But now track execution mentally.

If function A calls B, and then C, execution looks like this:

Enter A
Enter B
Exit B
Enter C
Exit C
Exit A

At runtime, the stack is a path.

But over time, the trace of execution forms a tree:

A is the parent
B and C are siblings

The stack is not “just LIFO”. It is a traversal of a tree-shaped execution history.

This matters more than most developers realize.

Execution Leaves a Shape Link to heading

Most developers are comfortable with stack behavior.
Far fewer are comfortable with closures — and this is why.

Closures break the illusion that execution is only a stack.

Consider this example:

const makeClosure = () => {  let a = 10;  function closure() {  console.log(a);  }  return closure; };  const myClosure = makeClosure(); myClosure(); // prints 10

Here’s the puzzle:

makeClosure() creates a stack frame
That stack frame exits
Yet a is still accessible later

So where is a?

It cannot be on the stack. The stack frame is gone.

The only possible conclusion:

execution is no longer a simple stack.

What actually happens is this:

The stack is one branch of a larger execution tree
Closures preserve parts of that tree after the branch collapses
Variables escape time, not scope

Once you understand this, async functions, promises, callbacks, and event-driven runtimes stop feeling magical.

They are not “stack tricks”. They are graph-shaped execution.

Why You Should Care Link to heading

In an age where any of us can spin up a workforce in the form of AI agents, the real challenge is no longer writing code — it’s scaling systems.

People sense this intuitively. That’s why they keep building frameworks, layers, and tooling with increasing internal complexity.

Frameworks consume your code — or AI-generated wiring — and impose their own abstractions and limitations. That is precisely where architectural decisions become irreversible.

Here’s the key point:

Seeing the stack as the active trunk of an execution tree is the mental model behind virtual machines, language runtimes, and frameworks themselves.

If you don’t understand the semantic consequences of your data structures, you are outsourcing architecture to tools that don’t pay the cost when things go wrong.

I’ll write more about this using concrete examples from a VM I built using exactly this perspective. As a preview: it supports async pipelines natively — but more on that later.

Dynamically Generated Languages vs MCP Servers

djuleayo — Sun, 18 Jan 2026 15:10:43 +0000

Dynamically Generated Languages Solve the Same Class of Problems as MCP Servers — and Do It Better Link to heading

After battle-testing these ideas in practice, here is my conclusion:

Centralized interaction and intent architectures are inevitable.
The only real question is whether we build them as formal systems or probabilistic agents.

From Clicking and Scrolling to Invoking Capabilities Link to heading

User interaction is moving away from clicking and scrolling and toward invoking capabilities directly, most notably via voice.

This shift is powerful:

If you can name a capability, you can invoke it
Interaction becomes direct
UX complexity drops dramatically

From a UX-complexity standpoint, this is a clear win.

However, this change forces a fundamental architectural shift compared to traditional frontend setups.

React and the Problem of Distributed Capabilities Link to heading

Consider a typical React application.

In React:

Capabilities are exposed through components
Components expose behavior via props and callbacks
Capabilities are therefore distributed by construction

There is no centralized place where “what the system can do” exists.

Trying to centralize this in React quickly reveals deep friction:

Hooks produce unstable references across renders
Central registries must constantly re-register handlers
Context-based solutions become brittle and stateful
Unsubscribing DOM listeners requires the exact same function reference
That reference is often no longer available or stable

Yes, you can build a capability registry on top of React.

But it is:

Clunky
Hard to reason about
Tightly coupled to rendering lifecycle
Architecturally inverted

All of this is a strong signal:
centralized capability invocation does not belong inside the UI layer.

Centralization Is Not Optional Link to heading

Now compare this with a system like the Visual Studio Code command palette.

VS Code exposes:

A centralized
Runtime-configurable
Discoverable
Uniform command surface

Once a command is registered:

It does not matter where it lives
It does not matter which UI triggered it
It can be invoked uniformly

This is not an accident.
It is a capability-first architecture.

The Natural Conclusion: A Decoupled Capability Layer Link to heading

What naturally follows is a module that:

Is decoupled from the frontend
Has no dependency on UI frameworks
Accepts voice or textual input
Emits discrete, authorized commands

At first glance, this smells like parsing.

And that is exactly what it is — with one important caveat.

This Is Parsing — Not AI Link to heading

Traditional parsing assumes:

Full input available upfront
A lexing phase
A parsing phase
A final AST

User interaction does not work this way.

For voice and interactive input we need:

Incremental parsing
Partial feedback
Real-time guidance
Asynchronous evaluation

This is not AI.

This is asynchronous parsing.

That distinction matters.

MCP Servers and the Core Problem Link to heading

MCP servers attempt to solve a similar problem:

Centralized capability invocation
Access via natural language
Location-agnostic execution

In practice:

Once a capability is integrated, its origin no longer matters
If you can name it, you can invoke it

On the surface, this sounds ideal.

It is not.

Why Informal Invocation Is Dangerous Link to heading

MCP-style systems rely on:

NLP → mapping informal language to formal side effects
Agents → which can and do hallucinate

This creates a fundamental mismatch:

Informal input
Formal consequences

The moment real side effects exist, you must introduce:

Authorization
Capability scoping
Denial rules
Auditability

At that point, you are already rebuilding a formal system.

Languages Are Formal Systems Link to heading

Languages:

Are minimal
Are precise
Can be syntactically close to natural language
Support deterministic navigation
Enable runtime introspection (autocomplete, discovery)

Most importantly:

Languages allow relational identification.

Objects are identified not by name alone, but by their position in a capability topology.

This is strictly stronger than nominal invocation.

LLMs are good at resolving names.

They are bad at:

Systematic search
Relational exploration
Topological disambiguation

A formal language enables:

Search through capability graphs
Context-aware narrowing
Progressive discovery
Authorization by construction

This is not “autocomplete”.

This is relational observation over a formal structure.

The Implementation Is Already Known Link to heading

Asynchronous parsing is not new.

Generators:

Exist in JavaScript for over a decade
Are foundational in operating systems
Are widely used in parsers and schedulers

They are exactly the right abstraction:

Incremental
Stateful
Deterministic
Interruptible

Nothing exotic is required.

The Critical Difference Link to heading

The most important outcome of such a system is this:

It can correctly deny you access.

This places it in a completely different category than LLM-driven systems.

LLMs aim to be helpful.
Formal systems aim to be correct.

When invoking real capabilities, correctness wins.

Closing Link to heading

Dynamically generated languages and centralized capability graphs solve the same class of problems as MCP servers.

They do so:

Deterministically
Safely
Transparently
With better UX
And with lower long-term complexity

This is not the future of “AI interfaces”.

This is the future of intent architecture.

Service as Architecture Reversal

djuleayo — Mon, 12 Jan 2026 07:22:50 +0000

Service as Architecture Reversal Link to heading

In the early internet, the intent was simple: distribute textual files with minimal markup.
To support this, a client–server architecture was adopted.

The naming was not accidental.

A server served.
The client was the master.

The server could not act unless requested. It could not speak unless spoken to. This asymmetry was a core design principle of the internet.

Today, our intuition feels inverted.

We scroll.
We are notified.
We are fed.

It feels as if we are no longer the masters of the system, but its dependents.

How did this reversal happen?

Capability Link to heading

A service exposes a capability.

Take a barber. A haircut is a convenience — until you cannot cut your own hair.
At that point, convenience becomes dependency.

The moment you lose capability, the service becomes a control surface.

This is exactly what happened to software.

Software as a Service is an architectural reversal:
instead of software serving on request, access to capability itself is mediated.

You no longer act directly.
You must go through the service.

Control Surfaces Link to heading

Consider a simple example: taking a screenshot in WhatsApp.

You own the hardware.
The hardware is capable.
The action is legal.
You want to do it.

Yet you cannot.

The application forbids it.
And who grants the application that authority?

The operating system.

This is the root.

Modern operating systems increasingly allow applications to define rules over hardware you own.
Capability is no longer assumed — it is granted.

A second example is even more revealing: offline functionality.

Your computer is powerful enough to edit documents, organize files, or process data locally.
Yet many tools refuse to function without an internet connection.

Not because computation is impossible — but because capability has been relocated behind a service boundary.

When the network disappears, so does your ability to act.

The Reversal Link to heading

Most people will never modify an operating system.
They will never build tools.
They will accept the service.

And so the architecture completes its reversal.

The system that was meant to serve becomes a gatekeeper.
The user that was meant to command becomes dependent.

This is not a conspiracy.
It is the cumulative result of convenience traded for capability.

Resolution Link to heading

The loss of freedom did not begin with surveillance or advertising.
It began earlier — with the quiet removal of user capability.

The way forward is not rejecting services.
It is refusing to confuse convenience with ownership.

Use services where they save time.
Avoid them where they become gates.

Prefer tools that work locally.
Prefer systems that degrade gracefully.
Prefer architectures where capability exists before permission.

Because in the end, whoever holds capability holds agency.

Freedom didn’t disappear when we were watched.
It disappeared when we stopped being capable.

Truth of IT, AI and sense

djuleayo — Sat, 10 Jan 2026 07:22:50 +0000

Truth of IT, AI and sense Link to heading

IT Is Power Link to heading

Automation has been world-scale power since World War II. AI does not change that. It only changes who can access it.

Automation has never worked “for you” by default. AI will not either. The same defensive mechanisms apply.

The system protects itself.

Fragmentation is one of those defenses. It prevents uninvited rises to power.

If you want market share, you are told you need an app on four platforms. To build that, you already need capital, distribution, and legitimacy. If you want traction, you need money. To get money, you need traction.

This is not accidental. It is the essence of pyramidal systems.

In any direct competition, the decisive advantage is surprise — a weapon the opponent does not expect. Markets are no different. Whether drugs, services, or software, the rule is the same: you want customers to know you exist while competitors do not.

Yet newcomers are taught the opposite: build in public, share everything, come with open hands — as if power has ever been granted freely.

In cultures with inherited capital and institutional trust, this illusion can survive. Elsewhere, it functions as extraction. The promise is always the same: someone won the lottery — work hard and it might be you.

Cultural memory has warned about this for millennia. Prometheus was not punished for kindness, but for stealing power prematurely.

Smokescreens are not moral failures. They are safeguards.

Those who see them can navigate. Those who do not are filtered out.

The Smokescreen Link to heading

This is written from nearly two decades behind a screen.

For two years I was paid well to build what was, in essence, a button calling an external service. That is not a complaint. It provided time and money. Both matter.

But once you build something real, you notice how aggressively usefulness is devalued.

Liquidity floods products whose primary function is compliance: don’t shake the boat — you have a job.

Todo apps raised billions. Not because they automate meaningfully, but because they are safe.

Most “creation” today is binding: gluing together logging services, monitoring services, analytics services, translation services, storage services, auth services, payment services.

What did you build?

This is not laziness. It is guided behavior.

Money flows steer developers away from capability and toward dependency. The web itself is structured around this principle.

Now widen the lens.

How many people in a country are builders by character? How many are trained as engineers? How many end up employed by foreign companies assembling SaaS stacks, mistaking API calls for ownership, platforms for infrastructure?

They are not idle. They are productive — inside fragmentation.

The result is predictable: local capability erodes, and sovereignty shifts to external platforms delivered “as a service.”

Even technical people lose power.

UX that is not o(1) is not automation. It is control through friction.

AI Power Redistribution Link to heading

AI changes one thing decisively:

Execution is no longer the bottleneck.

Coding agents, code search, and automated infrastructure inheritance remove manpower scarcity. Workforce becomes cheap. Speed becomes abundant.

Capability does not.

Scaling still depends on abstraction. Abstractions that can absorb exceptions without collapsing. Abstractions coherent enough to survive growth.

To the unskilled eye, high-level abstraction looks like noise. Rubbish and abstraction are indistinguishable without judgment.

That is the final bottleneck.

As execution flattens, control passes to those who own abstractions — not organizations with headcount. Companies will depend on them, not the reverse. Not out of ideology, but out of necessity.

This is not something that “must” stay so. It stays so because scaling fails without it.

For the first time, mechanics are no longer the constraint. Capability is.

Fragmentation declines. Coherent capability compounds.

These tools being public is not generosity. It is admission.

Those who can use them are rare. Those who cannot will be displaced — regardless of effort.

For a builder, this shift is not motivational. It is structural.

Selection Link to heading

With power comes responsibility — but responsibility is not assigned by declaration.

The remaining work is not invention. It is inheritance.

Understanding existing intent. Indexing accumulated systems. Maintaining coherence under growth.

Very few can do this. Fewer will choose to.

No invitation is required. The system selects on its own.

Those who align will find leverage. Those who do not will fragment — efficiently, at scale.

You Should Not Outsource Your Topological Sort

djuleayo — Sat, 20 Dec 2025 09:13:48 +0000

You Should Not Outsource Your Topological Sort Link to heading

Things are shifting quickly in software.

Execution is no longer scarce. Parallelism is cheap. Spawning workers—human or AI—is trivial. What is no longer cheap is coherence: understanding what depends on what, and in which order work can safely progress.

In that world, seniority is not about knowing frameworks or tooling. It is about owning structure.

One structure, in particular, keeps reappearing.

The invariant we keep outsourcing Link to heading

Topological sort sounds boring. Dependency graphs. Build order. Module resolution.

For years, we happily outsourced this problem:

to module loaders
to dependency injectors
to build systems
to frameworks

And that was fine—when execution itself was the bottleneck.

But once you start orchestrating:

multiple worktrees
multiple agents
partially overlapping tasks
incremental pipelines

…the dependency graph stops being an implementation detail.

It becomes the control surface.

What breaks when you don’t own it Link to heading

If the dependency graph lives outside your system, you lose more than convenience:

You can’t checkpoint progress meaningfully
You can’t resume work without recomputation
You can’t branch execution deterministically
You can’t define clean contract boundaries between concurrent actors

You’re forced to “start over” more often than necessary—not because the work changed, but because you don’t know where you are in the graph.

This shows up everywhere:

painful monorepo setups
slow feedback loops
brittle automation
orchestration that feels magical instead of mechanical

These are not tooling problems. They are graph ownership problems.

A concrete example: sessions as graph cursors Link to heading

Imagine a single source of truth: code, data, or input.

You process it in stages:

tokenization
preprocessing
parsing
semantic analysis
domain-specific passes

Different consumers need different depths.
But you do not want to reprocess from scratch every time.

What you actually want is simple:

recognize how far the source has been processed
continue minimally from there
reuse everything that is already valid

That is not a caching trick.

That is a cursor moving through a DAG.

Call it a session. Call it an account. The name doesn’t matter.

What matters is this:

once you own the dependency graph, incremental progress becomes trivial.

Without it, you fake it.

Why this matters more now Link to heading

With AI agents, automation, and parallel execution:

execution is abundant
retries are cheap
recomputation is wasteful

The limiting factor is no longer doing work.
It is placing work correctly.

If you outsource topological reasoning, you:

lose observability
lose control
lose leverage

And no amount of tooling on top can recover that.

The real claim Link to heading

This is not about implementing topological sort yourself for sport.

It is about this:

You should not outsource the authority over your dependency graph.

Once you own it:

session management becomes natural
incremental computation falls out
agent contracts become explicit
orchestration becomes deterministic instead of heuristic

Once you don’t:

everything becomes “best effort”
progress becomes opaque
automation becomes fragile

Closing Link to heading

Topological sort is not an algorithm problem anymore.

It is a design boundary.

Outsource it, and you outsource understanding.
Own it, and higher-level abstractions finally become possible.

That choice matters more now than it ever did.

TS API Spec

djuleayo — Sat, 20 Dec 2025 09:13:48 +0000

TS API Spec Link to heading

TS-first API spec with superb DX Link to heading

Everything is autocompleted and type-checked.
As soon as the schema is satisfied, the error disappears.

No separate spec file.
No generation step.

The problem this targets Link to heading

Most teams still pay the same tax:

duplicated contracts (controllers, OpenAPI, generated clients)
contract drift between backend and frontend
stale generated code
runtime bugs shipped by “green” builds

The root cause is structural:
the contract is treated as an artifact, not as the boundary.

Benefits Link to heading

Maximum code sharing between nodes (assuming JS/TS)
Fully typed end-to-end, including error cases
Uniform error handling across server and client
Single source of truth: router and apiClient are generated from the same spec

Optional runtime validation can be enabled in non-prod without changing the contract.

Overlap with existing approaches Link to heading

This overlaps with:

OpenAPI + codegen
RPC frameworks
shared schema repos

Difference: those generate code from a spec.
Here, the spec is the code boundary.

Why this is especially leveraged in JS/TS Link to heading

JS has an unfair advantage:

same language on backend and frontend
TypeScript as the shared type system

That enables:

zero drift
zero regeneration
no stale specs

Example Link to heading

Declare your spec once:

export const authRouter = {  register_post: {  bodySchema: registerRequestSchema,  responseSchema: z.object({ token: z.string() }),  cbErrorSchema: registrationError,  },  login_post: {  bodySchema: loginRequestSchema,  responseSchema: z.object({ token: z.string() }),  cbErrorSchema: loginErrors,  },  refreshToken_post: {  headerSchema: authHeader,  cbErrorSchema: z.null(),  responseSchema: z.object({ token: z.string() }),  } } as const satisfies ApiSpec;  export const apiSpec = {  api: {  auth: authRouter,  macro: macroRouter  } } as const satisfies ApiSpec; // key line (TS 5)  //Generate both router and client from the same spec:  const { router: apiRouter } = makeApi(apiSpec, {}, express.Router);  //Controller implementation is fully typed by construction:  makeController(  authRouter.register_post,  async ({ body: { email, name, password } }) => {  const user = await registerUser(email, name, password);   if (typeof user === 'string') return user; // typed error case   return { token: jwtSign({ userId: user.id }) };  } );  //And the client derives from the same contract:  export const { apiClient } = makeApi(apiSpec, {  baseUrl: 'http://localhost:3033&#39; });

If you violate the contract on either side, TypeScript complains immediately.

How it’s built Link to heading

Parser types (the core mechanism): http://djuleayo.com/posts/parser-types/
TypeScript 5 + Vite for clean cross-module sharing

What this optimizes for Link to heading

correctness over ceremony
DX over documentation
contracts that cannot drift by construction

If you can break the contract without TypeScript complaining, the setup is wrong.

Recursive "parser/grammar" type TS metaprogramming

djuleayo — Fri, 25 Jul 2025 08:23:31 +0000

Original post: http://www.djuleayo.com/posts/parser-types/

Intro — formal languages and parsing

All programming languages are specified by a grammar. A grammar tells us whether a piece of text is a valid sentence in that language. A parser generator can take such a grammar and produce a parser. Parsing is the “front end” of compilation: it turns raw text into structure. That’s the basis of how formal languages work.

Simplistic grammar example:

%token <int> NUMBER

expression: expression '+' expression
          | expression '-' expression
          | expression '*' expression
          | expression '/' expression
          | '(' expression ')'
          | NUMBER
          ;

This grammar can generate a parser for simple arithmetic. Before parsing, the input is just text. After parsing, we both

(a) know whether it’s valid under this grammar and
(b) obtain a structured representation of it.

Input:

1 + 2 * (3 - 4)

Parsed tree:

Operator precedence and associativity are encoded in how the tree “leans.” This is an Abstract Syntax Tree (AST). Every program you’ve ever written is, at some level, an AST.

Declarative vs. imperative (why we like trees-as-data)

An AST is a tree, and a tree is data. Code can be seen as data laid out in a shape that captures meaning. The tree is a constant shape that other parts of the system can consume. That’s powerful.

Take an Express router:

router.get('/users', (req, res) => {
  res.send('Users list');
});

You’re not imperatively pushing bytes through sockets; you declare what should happen on /users. The framework consumes that declaration at the right time.

Declarative style usually means: you state what you want; the machinery figures out how. The more capable the machinery, the richer the configuration language must be.

Parser types

Configurations aren’t always free-form; values often depend on each other. Not every config that “type-checks” at the top level is semantically valid. Think of a configuration as:

a constant value that must satisfy a language (expressed as an AST)

If that clicks, good. TypeScript lets us enforce such languages at compile time. I call these parser types: recursive TS types that act like a grammar. They don’t parse tokens; they constrain shape the way a grammar constrains sentences.

Consider:

type Test = Record<string, Test> // ❌ can't do

TS sees a naked, non-terminating recursion and bails.

Even:

type Test = Record<string, Test | string>

still trips the checker.

But:

type Test = { 
  [key: string]: Test | string // ✅ can do
}

works. The index signature form delays evaluation enough for TS to accept the recursion. That’s our recursive hook. Depth is unbounded (until compiler limits), so it can “eat” arbitrarily deep objects. The remaining task is to encode your language rules with unions and recursion.

TypeScript even nudges us syntactically—the leading pipes look exactly like grammar alternatives:

type Literal =
  | string
  | number
  | boolean
  ;

Now, your arithmetic example as a type-level grammar:

type Literal_t = 'number';
const ops = ['+', '-', '*', '/'] as const;
type Op = typeof ops[number];

// 1) leaf
interface NumberLiteral {
  type: 'number';
  value: number;
}

// 2) binary
interface BinaryExpr {
  type: 'binary';
  op: Op;
  left: Expression;
  right: Expression;
}

// 3) grouping
interface ParenExpr {
  type: 'group';
  expression: Expression;
}

// 4) the one non-recursive alias
export type Expression =
  | NumberLiteral
  | BinaryExpr
  | ParenExpr
  ;

// type annotation assures the object matches the grammar as AST
const ast: Expression = {
  type: 'binary',
  op: '+',
  left: { type: 'number', value: 1 },
  right: {
    type: 'binary',
    test: 'asdf', // ❌ type error
    op: '*',
    left: { type: 'number', value: 2 },
    right: { type: 'number', value: 3 },
  }
};

That stray test: 'asdf' is illegal under the grammar and TypeScript tells you immediately. Bonus: editor autocomplete now “knows” exactly what belongs where in your config/AST.

Why would you care?

Already mentioned: grammar can check more then any type union can.
But another area is COMPOSITE PATTERN constants. IE JSX is composite.
Child of a node is again JSX node. Composite patterns are omnipresent yet
constants of composite patterns are very error prone. Especially written by hand
without assistance of language server. Now JSX is solved as it is. Syntax sugar
for function calls. Thats runtime in essence and not a constant.

I'll hint another example of composite that with some effort of defining
proper "parser type", we can declare as constants with full type support.
Server routers. They are composable. and leafs are controllers.
Such constant would be SSOT which is effectively shared contract between server and client.
Out of the box both api client and controller functions would have full type support.
You can say, well we can use open API spec for that. But such a type would
allow full type support just out of declaration and nothing more. No generate types
step, code gen, eventual DRY hell retyping schemas and so on.
In next post I'll show how to do that with a real example. Stay tuned.

FP vs IP and Microservices vs Monoliths are the same argument

djuleayo — Thu, 15 May 2025 15:10:43 +0000

FP vs IP and Microservices vs Monoliths are the same argument Link to heading

There is a huge parallel between:

functional vs imperative programming
microservices vs monoliths

Now, the most unwelcome thing—dogma—should have no foothold in the software world. But it does.
Just like other markets, we ride waves of virality. It’s no coincidence that most beginners choose the most popular frameworks and languages.

While this kind of marketing gives guidance, it destroys the very essence of what coding should be: sense.
So parrots fly around and repeat things like:

“Microservices are better than monoliths”
“Functional programming is better than imperative programming”

But both approaches live, both are used—and that alone tells us both are good and both have their place.

Let’s draw the parallel between these two debates and expose the hype for what it is.

The Microservice Hype Link to heading

Every aspiring developer is told they must know how to build scalable systems before they can land a job—as if each of us is building cloud-scale infrastructure for side projects.

Buzzwords in job postings feed the hype, and so do slogans like:

“Your microservice team can be fed by one pizza.”
“Keep your services stateless.”

How many times have I heard the second one in interviews—only to open the source code and find a constructor call inside a get method, of a class passed via dependency injection… in JavaScript.

Come on. Time to quit (this really happened 😅).

Java Overengineering in JavaScript Link to heading

Java-style overengineering doesn’t belong in JavaScript.

Your JS module is automatically a singleton (unless you use dynamic imports).
The runtime handles circular dependency resolution.
Your module’s global-scope variables can’t be mutated from the outside without you exposing an interface to do so.

And yet, people bring Java complexity patterns into JS like it’s a rite of passage.

Bitter sweet reality Link to heading

This brings us to the real point: most devs are beginners. This will always be true. Most of us are territorial (we defend our code even when it sucks), and many are driven by the desire to be right—or at least to appear smart.

This, combined with a general lack of experience, makes it almost a rule: large codebases will be colored with smells.

Even “stateless” microservices often use stateful libraries or sessions for auth. Perspective is lacking—and that lack is guarded by dogma, which ultimately reduces to social behavior.

And maybe that’s fine.
After all, every problem should’ve been solved yesterday. Business doesn’t wait. We must deliver. Fast.

So there’s no time for:

“If you want to make pasta from scratch, you must first invent the universe.”
— Carl Sagan

Services Should Be Focused Link to heading

Like modules, services should focus on one thing and do it well.

Why? So we can scale them horizontally, reuse them, and maintain them independently.

But here’s where inexperience hits.
Many devs—even seniors in web—have never written a proper multithreaded program. Those who have know that orchestrating multiple clones of the same thing requires overhead.

In microservices, this overhead is primarily the cost of statelessness.

Stateless by Design — and by Cost Link to heading

Your message queues, Redis instances, and storage layers all need to be stateless (or used in a stateless way), because synchronizing across clones goes against horizontal scaling.

Need more performance? Spin up more instances.

The more instances you have, the harder it gets to synchronize them.
So… just don’t.

Don’t cache.
Don’t store session data.
Don’t share memory.

Instead: recompute everything every time.

Just like how a server-side page is re-rendered per request.

Example Link to heading

Let’s put it in beginner-friendly terms.

Say you have a function:

def fibonacci(n):

Now you call:

print(fibonacci(100)) print(fibonacci(101))

Neither functional programming nor microservices care that you just computed fibonacci(100). On line two, you start from scratch.

Only difference? A microservice wraps it in an HTTP request.

So the real question becomes:

Why is this better than a monolith? Why is it better than imperative code that could just cache the result—scaling vertically and holding runtime state with ease?

“Devs can think much further than they can code. Power to express oneself is lacking.”

This is the key.

Recomputing is obviously more expensive than caching, from the machine’s perspective. But from the developer’s perspective?

Caching is low-level. Tedious. Demanding. Often lacking expressive power. So we avoid it.

Instead, we build massive CI pipelines, spin nuclear-scale infrastructure, and recompute everything since Christ—just to avoid managing memory.

Scaling with Clones vs Standing on State Link to heading

Functional programming and microservices recompute anew—but can easily spawn 1000 instances of the same thing.

Imperative programming and monoliths tend to revolve around a single instance—but with the benefit of retained state and optimized memory usage.

Which one is better?

No straight answer.

Protecting the Codebase from Your Own Team Link to heading

If you have a large team, you often want to restrict expressive power.

You narrow responsibilities so each dev works in isolation. This reduces risk, reduces damage, and speeds up onboarding.

Yes, expressive power is linked to production cost and complexity. And industry cares more about delivering features than squeezing performance.

Under one condition:

Platforms vs Applications Link to heading

We can divide software into two rough categories:

Infrastructure — platforms like compilers, browsers, frameworks, and libraries
Applications — business logic and user-facing systems

If you fall into the second category, you tend to value:

Expressive power

Fast iteration

High-level abstraction

That’s when you lean on frameworks, CI pipelines, and horizontal scaling.

But if you’re building infrastructure, you care more about:

Precision

Performance

Long-term stability

So you optimize. You profile. You write tight, efficient code.

The Pendulum Swings Link to heading

We can’t always compute exactly when it’s time to switch paradigms. When is it worth optimizing that slow service? When is it better to lean into scale?

The pendulum will keep swinging—from monolith to microservice, from FP to imperative.

But the ideal gap between what we can think and what we can express in code is still wide. Maybe unbridgeable.

The Real Limitation: Human Abstraction Link to heading

It’s not that we lack tools to build expressive languages. They exist. The real problem is:

Human limitations in abstraction.

As one of my respected colleagues once said:

“The more abstract you go, the more language resembles static noise.”

And that is something worth pondering.

It may be the real cause behind these never-ending clashes in modern software: FP vs IP, MS vs monolith — and the limits of the human mind behind the keyboard.

DEV Community: djuleayo

Why You Must Revisit the Stack Data Structure in the Age of AI

Why You Must Revisit the Stack Data Structure in the Age of AI Link to heading

The Stack Is Not Just a Stack Link to heading

Execution Leaves a Shape Link to heading

Why You Should Care Link to heading

Dynamically Generated Languages vs MCP Servers

Dynamically Generated Languages Solve the Same Class of Problems as MCP Servers — and Do It Better Link to heading

From Clicking and Scrolling to Invoking Capabilities Link to heading

React and the Problem of Distributed Capabilities Link to heading

Centralization Is Not Optional Link to heading

The Natural Conclusion: A Decoupled Capability Layer Link to heading

This Is Parsing — Not AI Link to heading

MCP Servers and the Core Problem Link to heading

Why Informal Invocation Is Dangerous Link to heading

Languages Are Formal Systems Link to heading

Relational Navigation Beats Nominal Invocation Link to heading

The Implementation Is Already Known Link to heading

The Critical Difference Link to heading

Closing Link to heading

Service as Architecture Reversal

Service as Architecture Reversal Link to heading

Capability Link to heading

Control Surfaces Link to heading

The Reversal Link to heading

Resolution Link to heading

Truth of IT, AI and sense

Truth of IT, AI and sense Link to heading

IT Is Power Link to heading

The Smokescreen Link to heading

AI Power Redistribution Link to heading

Selection Link to heading

You Should Not Outsource Your Topological Sort

You Should Not Outsource Your Topological Sort Link to heading

The invariant we keep outsourcing Link to heading

What breaks when you don’t own it Link to heading

A concrete example: sessions as graph cursors Link to heading

Why this matters more now Link to heading

The real claim Link to heading

Closing Link to heading

TS API Spec

TS API Spec Link to heading

TS-first API spec with superb DX Link to heading

The problem this targets Link to heading

Benefits Link to heading

Overlap with existing approaches Link to heading

Why this is especially leveraged in JS/TS Link to heading

Example Link to heading

How it’s built Link to heading

What this optimizes for Link to heading

Recursive "parser/grammar" type TS metaprogramming

Intro — formal languages and parsing

Declarative vs. imperative (why we like trees-as-data)

Parser types

Why would you care?

FP vs IP and Microservices vs Monoliths are the same argument

FP vs IP and Microservices vs Monoliths are the same argument Link to heading

The Microservice Hype Link to heading

Java Overengineering in JavaScript Link to heading

Bitter sweet reality Link to heading

Services Should Be Focused Link to heading

Stateless by Design — and by Cost Link to heading

Example Link to heading

Scaling with Clones vs Standing on State Link to heading

Protecting the Codebase from Your Own Team Link to heading

Platforms vs Applications Link to heading

The Pendulum Swings Link to heading

The Real Limitation: Human Abstraction Link to heading