DEV Community: Danil

Everything Is the Fastest, the Best, and the Future. I'm Tired.

Danil — Fri, 26 Jun 2026 21:10:52 +0000

I opened a fresh terminal last week to start a small internal dashboard for tracking our team's deploys. Nothing huge. A couple of tables, a chart, a status light per service. Before I typed a single line of real code, I had four browser tabs open arguing about which runtime to use, two about the "right" package manager in 2026, and one very confident blog post explaining why the database I was about to pick was already obsolete.

I closed the laptop and made tea.

The promise is always the same

Almost every serious tool is fine. Most of them are genuinely good. That is the problem. When everything is good, marketing can't say "this is good," so it reaches for the superlative. Fastest. Most loved. The future of the stack.

It is the sheer volume of it, all at once, in every category, that wears me down. Here is my week.

JavaScript runtimes: pick a lane, any lane

I wanted to run some JavaScript. Used to be a one-line decision. Now there are three serious answers and each one has a personality.

Node is the boring grown-up that runs most of the internet and supports basically every package on npm. Deno shows up with native TypeScript, a strict permissions model, and a built-in formatter, linter, and test runner, so you stop gluing twelve tools together. Bun bundles the runtime, package manager, bundler, and test runner into one binary and tells you it is dramatically faster at almost everything.

And it can be. In an Express-style HTTP test Bun sustained roughly 52,000 requests per second where Node plateaued around 13,000, about four times faster (Strapi). Impressive number. Then you read the same writeup's more realistic test, with routing, validation, and an actual database in the loop, and the gap collapses to about 12,400 versus 12,000 requests per second. Less than three percent.

So which one is fastest? All of them, depending on which benchmark you were shown. The pattern most teams quietly land on is unglamorous: existing services stay on Node, brand-new services try Bun, and security-sensitive work leans Deno (daily.dev).

Package managers: an 18x number that means almost nothing

Fine. I picked a runtime. Now how do I install dependencies? There are four contenders and they will all tell you the others are slow.

The numbers are real and they are genuinely big. On a typical React and TypeScript project, a cold install clocks in at roughly 0.8 seconds with Bun, about 5 seconds with pnpm, and a leisurely 14 seconds with npm, which works out to Bun being around 18x faster than npm (DeployHQ). Bun is written in Zig and makes a fraction of the system calls npm does, about 165,000 against nearly a million on the same install (Bun). That is a legitimately clever engineering story, and pnpm's own benchmarks back up that it crushes npm on most graphs (pnpm).

Here is my tired confession. I install dependencies maybe a few times a day. The difference between one second and fourteen, summed over a normal day, is not what is slowing me down. What slows me down is reading three "showdown" posts to feel allowed to pick one.

The speed crown also moves. A year ago the install-speed story was pnpm's. Then Bun shipped a binary lockfile and a native installer and took the headline. Whatever you standardized on last quarter is now, by some post's reckoning, the slow one. I spent a weekend moving forty-odd internal services off Yarn onto pnpm, and then a few months later half of them onto Bun, chasing exactly this. The only things that actually changed were the lockfile format and my mood. I will not be doing it a third time.

Category	The pitch you'll hear	What's usually true
JS runtime	"Blazing fast, all-in-one"	Real wins in micro-benchmarks, small gap under real load
Package manager	"Up to 18x faster installs"	True on cold installs, rarely your bottleneck
OLAP database	"Fastest analytics engine"	Depends entirely on data size and query shape
AI model	"New state of the art"	True for a few weeks, on specific benchmarks
...and the next category	"...also the fastest and the future"	"...and the one after that, and the one after that"

Databases: the fastest, according to whose benchmark?

This is where it gets funny, because the superlatives start colliding with each other.

ClickHouse will tell you, with receipts, that it is the strongest general-purpose real-time analytics database, winning or tying 32 of 43 queries on ClickBench with a median hot-cache latency around 148 milliseconds (ClickHouse). DuckDB will tell you it is the SQLite of analytics, runs in-process, and is plenty fast for the data that actually fits on one machine. Both are correct. ClickBench is also, as one analytics vendor pointed out a little dryly, created by ClickHouse, so it is fair to assume it favors ClickHouse's engine (Tinybird).

That is not a scandal. Every vendor benchmarks on the workload that flatters them. It just means "fastest database" is a sentence with an invisible footnote attached.

Then there is the vector database category, which spent two years insisting you needed a dedicated, purpose-built, blazing-fast vector store for your AI app. Meanwhile pgvector quietly let people store embeddings right next to their relational data and run similarity search in under 20 milliseconds even at a million vectors (Encore). The counter-movement now has its own slogan, "you probably don't need a vector database," which is, of course, also a marketing position. Even the backlash to the hype is hype.

I find this strangely comforting. If "just use Postgres" can become a movement, then boring and reliable still gets a turn now and then.

Observability: same play, different category

Logs and metrics fell into the same pattern while I wasn't looking. Every storage backend and pipeline in this space promises lower cost, higher ingest, and faster queries than whatever you are running today. One project pitches column-oriented storage that makes your old setup look wasteful. Another pitches a unified store so you stop running three systems for logs, metrics, and traces. A third pitches an agent that is somehow lighter than the lightweight agent you already deemed lightweight.

I do not doubt the numbers. I doubt my ability to act on them. By the time I have evaluated one observability stack, the team behind a competing one has published a benchmark showing it ingests more events per second on a cheaper instance. The category never settles long enough for me to feel finished, so I have mostly stopped trying to feel finished.

AI models: state of the art, valid until next Thursday

You knew this one was coming.

Skim any leaderboard and a fresh "new SOTA" announcement lands before you have finished reading the last one (Vellum, llm-stats). One model tops SWE-bench, another tops reasoning, a third wins competitive coding, and last month's leaderboard is already a museum piece.

I genuinely like a lot of these tools. But the cadence has broken my brain a little. I will spend an afternoon getting a workflow tuned around one model, feel good about it, and the next morning a thread informs me that choice is now embarrassing because something launched overnight that scores two points higher on a benchmark I will never personally run. The fear of missing the better tool has quietly replaced the joy of using a good one.

Why everyone shouts at once

Most categories are crowded with good options, so a real, defensible edge on one benchmark is the only honest hook left. Launch posts and comparison content are how projects get attention, so the loudest, most quantified claim wins the feed. And I reward it. I clicked the "18x faster" headline, then rewrote half a build pipeline around the tool behind it, then watched it save me about nine seconds a day. I am exactly the reader this all works on.

The benchmarks are not lies. They are narrow truths presented at full volume. "Fastest on this query, on this hardware, with a warm cache" becomes "fastest," because the qualifier does not fit on the banner and would dull the punch anyway.

There is also a timing trap in here. A launch is a single moment, but a tool lives in your codebase for years. Marketing optimizes for the moment, when attention is cheap and the demo is rehearsed. You optimize for the years, when the docs have to be searchable, the error messages have to make sense, and someone new has to read the code. The loudest tool on launch day is not reliably the one you are happiest with eighteen months later.

How I actually pick now (the only useful part)

I promised this rant would earn its keep, so here is what I do now, mostly out of self-defense.

I start from the boring default and make the shiny thing argue its way in. Node, Postgres, npm, the model already wired up. The well-worn option has Stack Overflow answers from 2019 that still work, and I will take that over a leaderboard win most days. I only go shopping when something is actually, measurably slowing me down. Not "a blog post says I could be faster." Real pain I have felt. If installs are not my bottleneck, I genuinely do not care that another installer is quicker.

When I do read a benchmark, I read the workload before the number. If I cannot tell what was measured, I assume it was measured to win, because it usually was. And I try to pick for the unglamorous middle of a project rather than the demo: the migrations, the 2am debugging, the new hire who has to understand the code. Launch day is the least important week of a tool's life with me.

The thing that actually saves my sanity is just stopping. When a choice is good enough, I commit and close the tabs. I have shipped with the slightly slower option plenty of times and never once sat there at 2am wishing I had picked the faster one. It just never comes up.

So, honest question

I want to know how you do it, because I am clearly still figuring it out.

When you start something new and every option in the category swears it is the fastest and the future, how do you actually choose? Do you default to boring on purpose? Trust one person's taste over benchmarks? Pick the thing with the best docs and never look back? Or do you, like me, occasionally close the laptop and make tea?

Tell me in the comments. Bonus points for the most over-the-top "we're the best" tagline you've seen lately. I collect them now. It's a coping mechanism.

React vs Angular vs Vue: A Beginner's Guide to Actually Picking One

Danil — Thu, 25 Jun 2026 15:29:46 +0000

If you are new to frontend development, the React vs Angular vs Vue question feels like a trap. Every blog post seems to crown a different winner, and the comment sections turn into small wars. So here is the calm version.

TL;DR: All three are good. For most apps the framework you pick matters far less than people pretend, and that gap shrinks even more once the workload gets heavy. Pick based on your team, your job market, and how the framework feels to you. Then learn it properly. Below I explain what each one actually is, where they really differ, and a simple way to make choice.

First, what are these three things?

They all help you build interactive websites without manually poking at the page every time the data changes. But they are not the same kind of tool.

React is a library, made by Meta (Facebook). It only handles the UI (the "view"). You add the other pieces yourself: routing, data fetching, forms. Think of it as a really good engine that you build the rest of the car around.
Angular is a full framework, made by Google. It comes with almost everything in the box: routing, forms, HTTP, testing. It is the whole car, and it has opinions about how you drive.
Vue is a progressive framework, community-run, with no big tech giant behind it. It sits in the middle: a friendly core you can grow into something bigger when you need to.

A quick word on jargon. A component is a reusable chunk of UI, like a button or a whole sidebar. Reactivity just means "when the data changes, the screen updates by itself." You don't redraw it by hand.

The one difference you'll feel on day one: syntax

This is the thing that actually decides whether you enjoy a framework.

React uses JSX, which mixes HTML-like markup straight into JavaScript:

function Counter() {
  const [count, setCount] = useState(0);
  return <button onClick={() => setCount(count + 1)}>Clicked {count} times</button>;
}

Vue uses templates that look a lot more like plain HTML, with the logic kept separate:

<script setup>
import { ref } from 'vue'
const count = ref(0)
</script>

<template>
  <button @click="count++">Clicked {{ count }} times</button>
</template>

Angular also uses templates, but it expects TypeScript (a typed version of JavaScript) and a class-based structure from the very start. More ceremony up front, more guard rails later.

Most people find Vue the gentlest to read and React the most flexible once it "clicks." Angular is the most structured, which beginners often experience as the steepest.

What about speed and bundle size?

Bundle size is how much JavaScript the browser has to download before your page works. Smaller is generally faster to load. Here are rough current numbers for the core (gzipped):

Framework	Core bundle (gzip)	Reputation
Vue 3.5	~18 to 22 KB	Smallest, fast initial load
React 19	~32 to 40 KB	Small core, but you add libraries
Angular 20	~110 to 130 KB	Largest, includes everything

One fair warning: React's tiny core is a little misleading. A real React app pulls in extra libraries for routing and state, which closes the gap. Angular's number looks scary, but it ships a lot of features you would otherwise wire up by hand.

On raw rendering, modern benchmarks like the well-known js-framework-benchmark tend to show Vue edging out React on update-heavy work, because its compiler tracks exactly what changed. But here is the honest part: for most real apps, that difference is a few milliseconds your users will never feel.

The surprising part: under heavy load, they converge

This is where a beginner comparison usually stops. I want to go one step further, because it changes how you should think about the whole debate.

There is a community benchmark that puts the three head-to-head on a dashboard-heavy frontend, the kind with a 10,000-row data grid that really stresses a framework. The results were a useful reality check. Vue did come out ahead overall, and it consistently shipped the smallest bundle. But on the heaviest operation, rebuilding the entire grid, all three finished within about 4% of each other. Vue's clearest win was on sorting, where it was roughly 18% faster than React, not on the brute-force rebuild.

Don't take my word for any of it. Go read the individual claims, look at the numbers behind each one, and verify or push back on them yourself in this React vs Angular vs Vue dashboard battle.

The lesson is simple. When the work is genuinely hard, the framework stops being the bottleneck.

What you do matters more than which logo sits in your package.json!

The biggest single trick is virtualization: only rendering the rows currently on screen instead of all 10,000. A naive React grid and a naive Vue grid will both crawl. A virtualized one in either will fly.

How to actually choose (a 60-second guide)

Forget "which is best." Ask these instead:

What does your team or local job market use? This is the biggest factor by far. React has the most jobs, with tens of thousands of US openings versus a few thousand for Vue. If a paycheck is the goal, that's a thumb on the scale.
How much structure do you want handed to you? Want batteries included and strong conventions? Angular. Want freedom to assemble your own stack? React. Want a gentle middle path? Vue.
Which one is fun to read? Open the docs for each and write a counter. The one whose code makes you go "oh, that's nice" is the one you'll stick with, and sticking with it is what makes you good.

A simple default for a brand-new developer: start with Vue to learn the concepts fast, then learn React for the job market.

The takeaway

The three frameworks keep getting more alike. Angular added signals, Vue refined its fine-grained reactivity, and React shipped a compiler. They are all trying to do less unnecessary work, so the "war" matters a little less every year. Learn the fundamentals, meaning components, state, reactivity, and when to reach for virtualization, and you can move between all three without much pain.

Did you pick your first framework for a solid technical reason, because of the job listings, or just a tutorial you happened to find? Tell your story in the comments.