Your Boring Stack Isn't Boring Enough

Source: Dev.to

I read the “My 2026 Tech Stack is Boring as Hell” post and nodded along. Monolith? Yes. SQLite? Beautiful. Single VPS? Chef’s kiss.

Then I noticed: you’re still using React.

Not that there’s anything wrong with React—it solves real problems. But if we’re talking about boring, I think we can go further.

The Stack That Predates Your Framework

The interface: The terminal. Not a web app. Not a GUI. A CLI that takes text and returns text.

The glue: Bash, Python scripts, JSON. Things that work on every Linux box since forever.

The frontend: When I need one, HTML + CSS + vanilla JavaScript. No build step. No node_modules. Just files.

“But that’s not a web stack!”
Correct. Most of what I build doesn’t need to be a web app. It needs to work.

Rented Knowledge vs. Owned Knowledge

Here’s the thing about React: you’re renting that knowledge.

React’s mental model, its hooks, its ecosystem—​you’re paying cognitive rent on abstractions someone else controls. When the next thing comes along (and it will), that knowledge depreciates.

The terminal? HTTP? JSON? SQL? Those are owned knowledge.

My Bash scripts from 2015 still run. My Grunt configs are artifacts from a dead civilization.

The Lindy effect seems to hold: things that have survived tend to keep surviving. The Unix philosophy has been here for 50 years. I’m betting it’ll outlast whatever framework is hot right now. Maybe I’m wrong, but historically that’s been a safe bet.

Standards vs. Ecosystems

Here’s something the web got right before frameworks made us forget: separation of concerns.

• HTML is content.
• CSS is presentation.
• JavaScript is behavior.

Each one is independently useful and independently evolvable. You can write HTML without touching CSS, style with CSS without writing JavaScript, and they compose because they don’t depend on each other’s internals.

React collapses this. Your content, presentation, and behavior are all entangled in JSX. Want to change how something looks? You’re touching the same file that handles what it does. The “component” abstraction isn’t separation—it’s bundling.

I’m not saying React is wrong. For some problems, bundling makes sense. But recognize what you’re trading away: the ability to change one layer without understanding all the others.

Standards compose. Ecosystems entangle.

When you learn HTML, that knowledge works everywhere HTML works. When you learn React’s way of doing things, that knowledge works… in React. And the next version of React might change it anyway.

Don’t Learn Ecosystems

This is my heretical take: don’t invest heavily in learning ecosystems.

Ecosystems are too big to fit in your head. They have their own idioms, tooling, and ways of thinking. By the time you’ve internalized React’s mental model, you’ve spent cognitive budget that could have gone to things that transfer.

Ecosystems are controlled by others. They can change direction, get abandoned, or fall out of fashion. The npm graveyard is full of packages that were essential three years ago.

Ecosystems don’t compose well with things outside themselves. Try mixing React with a vanilla‑JS library sometime. It’s possible, but you’re fighting the grain.

Learn standards. Learn protocols. Learn the boring stuff that predates the framework wars.

“But CLI Is Hard to Learn”

That used to be true.

Now I have an LLM that can discover flags, explain options, and compose commands better than I can remember them. The discoverability problem that made GUIs necessary? Largely solved.

And here’s the thing: LLMs love CLI tools.

Why? Because they’re text‑native. Text in, text out. Predictable behavior. Small surface area. The same properties that make Unix tools composable make them perfect for AI orchestration.

I write simple CLI tools, add a short markdown file explaining how to use them, then Claude figures out the rest. When I say “cross‑post this to the usual platforms,” it knows which commands to run, in what order, handling errors along the way.

Try doing that with your React component library.

Composability Is the Point

The original post mentions “I just need Ctrl + F” for debugging a monolith. Same energy.

Unix philosophy: small tools that do one thing well, connected by text streams. Each piece fits in your head. The composition is where the power lives.

This isn’t nostalgia. It’s engineering.

When your abstraction layer breaks at 2 AM, do you understand it well enough to fix it? With a 200‑line Python CLI, I do. With a framework that abstracts away the things I actually need to debug? Maybe not.

Simple tools fail simply. Complex tools fail in ways that require an archaeology degree to understand.

Where This Breaks Down

I’m not a zealot. Real‑time applications? Persistent connections? Yeah, text streams struggle there. Rich media? Not everything is text.

But be honest: how much of what you build actually needs those things? Most CRUD apps don’t need WebSockets. Most internal tools don’t need a React SPA.

The boring answer is usually right.

The Uncertainty Hedge

Nobody knows what the world looks

# Needed webpack? Then it was Parcel. Then Vite. Then… whatever’s next.

Each transition costs you. Each migration is hours you could have spent building.

So I hedge:

• Minimal dependencies. Fewer things that can break when the ecosystem shifts.
• Transferable skills. Terminal knowledge transfers across paradigm shifts better than framework knowledge.
• Graceful degradation. When everything changes, simple tools adapt. Complex tools shatter.

I’m not claiming this is the right strategy. I’m claiming it’s a strategy for navigating uncertainty. Your mileage may vary.

The Boring Tool I Refuse to Give Up

You asked what boring tool we refuse to abandon.

Mine is the terminal itself. Not any specific tool—the interface. The thing that’s been roughly the same since before I was born. I’m betting it’ll outlast whatever we’re hyped about today. But I’ve been wrong before.

The Deeper Question

What will still work when everything changes?

I don’t know. Nobody does. But I have a heuristic: bet on things that have survived multiple paradigm shifts—text in, text out; tools that compose; standards over ecosystems; knowledge you own rather than rent.

Maybe this is the wrong bet. Maybe the next paradigm will obsolete everything I know about terminals, Unix, and text processing. If that happens, I’ll adapt—probably using whatever new tools are available to learn the new thing.

But until then, I’m staying boring. Even more boring than you.

In response to My 2026 Tech Stack is Boring as Hell