DEV Community: qingkuai

Frontend Framework Bundle Size Benchmark: React/Vue/Angular vs Fine-Grained Runtimes

qingkuai — Mon, 13 Apr 2026 19:08:33 +0000

Framework discussions usually focus on DX, ecosystem, and runtime performance. But users experience something earlier than all of that: download, decompress, parse, then execute.

That is why I built this benchmark: to make framework bundle-size tradeoffs visible under the same feature scope and the same reporting rules.

What I benchmarked

I implemented the same TodoMVC feature set across multiple frameworks, then generated one unified report.

The report compares:

raw size
minified size
minified + gzip size

It also breaks totals down by:

runtime
template
script
style

Fairness constraints

To reduce noise from implementation differences:

all frameworks implement the same TodoMVC behavior
template/script/style outputs are extracted and compared
styles are scoped in all implementations (TSX-based implementations use CSS Modules)
the UI does not select style by default, but style is still included in stats

Why style is not selected by default in the chart controls:

style usually has limited optimization room in this setup, and differences are often tiny and mostly caused by framework-added scoping metadata rather than major architecture differences.

Mainstream group: React, Angular, Vue (Vue 3)

At 1 component (minified):

Angular: ~201.69 KB
React: ~189.44 KB
Vue 3: ~65.64 KB

The key reason is runtime cost. In the same report view:

Angular runtime: ~195.39 KB
React runtime: ~185.66 KB
Vue 3 runtime: ~61.83 KB

As component count grows, the gap expands. Angular rises fastest, React also stays high, and Vue 3 remains lower overall in this group in this benchmark.

Fine-grained group: Solid, Vue Vapor, Svelte 5, QingKuai

The ecosystem trend is clear: less generic virtual-DOM diffing, more dependency-precise updates (fine-grained reactivity).

But in practice, frameworks in the same direction can still differ a lot.

At 1 component (minified):

Solid: ~19.04 KB
QingKuai: ~25.42 KB
Svelte 5: ~39.25 KB
Vue Vapor: ~47.27 KB

If you only look at the starting point, Solid is smallest in this group.

But if you look at growth curves, the story changes:

QingKuai grows more smoothly and ends up lowest at high component counts in this run
Solid starts smallest but grows faster
Svelte 5 and Vue Vapor stay above QingKuai in higher component-count ranges, while Vue Vapor remains below Solid and Svelte 5 at larger scales

So the useful takeaway is not just “fine-grained is better.”
It is: how the runtime is organized and how costs scale with component count matters more than a single low starting number.

Why Svelte 4 deserves a separate note

Svelte 4 has a very attractive small-app story.

At 1 component (minified), it is ~11.08 KB in this benchmark, with runtime at ~0.71 KB.

But at larger scales, its curve becomes much steeper than peers in this comparison.

This suggests a common risk pattern for larger apps:

very low centralized runtime cost
more repeated implementation fragments embedded in component output
total size grows quickly as component count increases

Practical guidance from this dataset:

for very small apps (for example, under ~10 components), Svelte 4 can still be a reasonable choice
for larger applications, evaluate growth slope early, not just the smallest demo number

The metric that matters: starting point + slope

This benchmark reinforced four points for me:

Bundle size should be a first-class framework selection metric.
“No virtual DOM + fine-grained” is an important direction, but implementations in that direction can still differ significantly.
The smallest 1-component result is not enough.
For medium/large apps, growth slope is often more important than the best single-point minimum.

Reproduce locally

git clone https://github.com/mlgq/frontend-framework-bundle-size.git
cd frontend-framework-bundle-size
pnpm install
pnpm run report

Links

If you find an unfair implementation detail or have better optimizations, critiques and PRs are welcome.

TypeScript in Vue/Svelte Is Great, Until It Isn't: Fixing the Missing Type Flow

qingkuai — Tue, 07 Apr 2026 16:58:40 +0000

Frontend component syntax is often split into two families: template-language frameworks (Vue, Svelte, Qingkuai) and JSX/TSX frameworks (React, Solid).

Template-language frameworks usually give you a cleaner script block for native JS/TS and a concise template syntax for rendering. JSX/TSX gives you maximum flexibility because the whole file is expression-friendly JavaScript, but it also blends markup, style, and logic more aggressively.

Both models are valid. This article focuses on one long-standing pain point in template-language frameworks: how to deliver a truly strong TypeScript experience.

Scope note: observations about framework behavior are based on the setups I tested while writing this article (April 2026), and may differ across toolchain versions.

1) Type Declarations Inside Components

Mainstream template frameworks already support TypeScript well, but some important workflows still feel awkward. The first one is props typing.

In Vue and Svelte, the common approach is a compiler-level declaration mechanism (terminology differs by framework). It works for simple props, but in generic scenarios you often need extra syntax on the <script> tag itself, for example:

<script generics="T extends { id: number; name: string }"></script>

This partially breaks the core promise of template languages: a clean JS/TS authoring environment inside the script block.

There is also hidden cost around visibility rules. In practice, external imported types are usually reachable from generics, while types declared inside the script block may not be.

My working hypothesis is that this is related to generic-component export shape handling: the language service may need to treat the default export as a function, and because import declarations are module-top-level only, they get lifted outside that function scope, creating the visibility mismatch.

This hypothesis is based on observed behavior, not on confirmed framework-internal implementation details.

Regardless of exact implementation details, the result is more cognitive overhead.

One practical design choice is to keep Props as a global component type declaration. If you declare Props, you have declared your prop types. This keeps the script authoring flow close to plain TS.

// TypeScript project
import type { Data as ExternalData } from "./types"

interface Data {
    id: number
    name: string
}

type Props<T extends Data & ExternalData> = {
    data: T
}

A useful side effect: in pure JavaScript projects, you can still declare component prop types via JSDoc and keep type checking/completion.

/**
 * @template {{id: number; name: string}} T
 * @typedef {object} Props
 * @property {T} data
 */

2) Passing Generic Type Arguments at Call Sites

Another major pain point is generic arguments from the caller side.

In both Vue and Svelte, in the setups I tested, trying to pass generic type arguments directly at the usage site leads to parser errors in template syntax. That means even with clear business context, callers cannot explicitly pass generic arguments to narrow and proactively constrain component types:

// desired call-site intent (illustrative)
<UserList<UserSummary> items={rows} />

// expected: caller pins the generic boundary to UserSummary
// observed in tested Vue/Svelte template setups:
// parser error for this syntax, and no equivalent
// explicit generic argument channel

This is not just a syntax preference issue. It directly impacts type precision in real-world component composition.

3) Slot Context Type Inference

Template languages have a structural advantage here.

Most template systems define slot outlets with a slot element and attach outbound data directly on that outlet. That gives the compiler a natural anchor for slot context inference.

By contrast, JSX/TSX frameworks do not have native slots. They usually emulate them with children, which often requires manual function-type declarations for parameters and return values.

In the setups I tested, mainstream template-language frameworks still do not provide full end-to-end automatic slot-context inference. Vue supports manual slot-context typing. Svelte4 used slot but did not support direct slot-type annotation there; Svelte5 introduced Snippet, but still depends on manual context typing.

From an engineering perspective, though, automatic inference is absolutely feasible through a combined path:

compile-time static analysis,
IR markers that preserve semantic structure,
type extraction via TypeScript language services.

With this model, a component can avoid extra internal type annotations while callers still get full completion and inference. This can also work in pure JavaScript projects, because type recovery can be done in tooling rather than only from explicit TS annotations:

The bigger win is IDE navigation quality. With proper slot-context inference, Go to Definition and Find References can jump to the real source definition instead of a detached type alias layer.

In complex components, this saves a lot of time during reading and refactoring.

4) Component Export Type Readability

Most template frameworks auto-infer component export types, which is good. But readability still varies.

When inferred types are too verbose or leak internal framework types, developers lose confidence quickly. Better export type design can make hover information dramatically easier to understand.

With a clearer export type structure, this can be improved significantly.

Many developers also expect to hover directly on a component tag and see its type, but support here is still uneven across frameworks.

If the language service extracts the final component type through TypeScript TypeChecker and returns it directly in tag hover, implementation is straightforward and the developer experience improves immediately.

Minimal illustration:

5) Why This Matters: Type Flow Continuity

These topics may look separate:

component type declarations,
generic argument passing,
slot context inference,
export type readability.

But they are really one problem: type-flow continuity.

Once type information breaks anywhere across this chain,

component source -> compiler output -> language service -> IDE interaction,

developers pay the cost through manual annotations, fragile conventions, and slower refactoring.

A practical strategy is to co-design compiler and language service:

Keep template syntax lightweight and avoid adding authoring friction.
Preserve enough semantic markers during compilation.
Recover and rehydrate high-quality types in language tooling.

For framework authors, this means continuing to harden edge cases (complex generics, conditional types, cross-file symbol mapping) and validating stability/performance in larger codebases.

Limitations and Trade-offs

This article focuses on type-system ergonomics, not runtime performance benchmarking.
Some claims are based on tool behavior observed in tested setups and should be re-validated in your own version matrix.
Examples are intentionally minimal to show type-flow boundaries; production code may need additional constraints.

Closing

Template-language frameworks are not inherently weaker for TypeScript ergonomics. The key is whether the type system is treated as a first-class part of both language design and tooling architecture.

If you want to evaluate these ideas hands-on, you can compare behavior quickly in docs at https://cn.qingkuai.dev and the live playground at https://try.qingkuai.dev.