The Evolution and Competitive Trends of Next‑Generation Frontend Frameworks

The article begins by presenting the State of JavaScript 2022 satisfaction ranking, where Solid, Svelte and Qwik lead as the three representatives of next‑generation frontend frameworks, while the established trio React, Angular and Vue still dominate the market.

It argues that, similar to programming languages, new frameworks struggle to displace the incumbents unless they are revolutionary or backed by major companies, citing Flutter as an example of a language with both qualities.

View Programming Paradigm Consolidation

Since the decline of jQuery, the view programming model has stabilized around three core concepts:

Data‑driven view : the view is a function of state (e.g., View = f(State) ).

Declarative view : frameworks describe the desired UI rather than the steps to build it.

Component‑based view : components are the primary building blocks, exposing props, slots, events, refs, context, etc.

Partial Experience Involution

While the overall paradigm is fixed, frameworks compete on two fronts: user experience and developer experience.

User Experience

Fine‑grained rendering – achieving low‑cost, precise DOM updates.

Compile‑time approaches – exemplified by Svelte and Solid.

Reactive data – used by Svelte, Solid, Vue, and signal‑based systems.

Static‑dynamic separation.

Performance optimisations.

Concurrency – React’s unique focus.

“No‑JavaScript” – frameworks aim to deliver interactive first‑page content with minimal JavaScript.

Developer Experience

TypeScript friendliness.

Tooling and build pipelines (Vite, Turbopack).

Developer tools (Vue Devtools, Nuxt Devtools).

Meta‑frameworks (Next.js, Nuxt.js) that abstract boilerplate.

Fine‑Grained Rendering Example

Svelte’s compile‑time approach eliminates the virtual DOM and translates declarative templates into imperative DOM operations. The following Svelte component demonstrates this transformation:

<script>
  let count = 0;
  function handleClick() {
    count += 1;
  }
</script>

<button on:click="{handleClick}">Clicked {count} {count === 1 ? 'time' : 'times'}</button>

The compiled output (simplified) shows explicit DOM creation, event listening, and state updates without a virtual DOM layer:

function create_fragment(ctx) {
  let button, t0, t1, t2, t3;
  return {
    c() { button = element('button'); t0 = text('Clicked '); t1 = text(ctx[0]); t2 = space(); t3 = text(ctx[0] === 1 ? 'time' : 'times'); },
    m(target, anchor) { insert(target, button, anchor); append(button, t0); append(button, t1); append(button, t2); append(button, t3); if (!mounted) { dispose = listen(button, 'click', ctx[1]); mounted = true; } },
    p(ctx, [dirty]) { if (dirty & 1) set_data(t1, ctx[0]); if (dirty & 1 && t3_value !== (t3_value = ctx[0] === 1 ? 'time' : 'times')) set_data(t3, t3_value); },
    d(detaching) { if (detaching) detach(button); mounted = false; dispose(); }
  };
}

The article likens this to low‑level memory management: virtual DOM resembles garbage‑collected languages, compile‑time approaches resemble Rust’s ownership model, and manual DOM manipulation mirrors C/C++.

Reactive Data

Reactive data is essentially an observer pattern that enables finer‑grained updates compared to React’s immutable‑data diffing. Frameworks like Vue automatically track dependencies during rendering, while signals (used in Angular, Preact, Qwik, Solid) provide a lightweight reactive primitive.

Static‑Dynamic Separation

Vue 3 exemplifies static‑dynamic separation by statically compiling templates, then applying runtime reactivity for dynamic parts, achieving both performance and flexibility.

Compile‑time vs Runtime

The article discusses the trade‑offs of compile‑time solutions: they can deliver performance gains and cleaner syntax but introduce a gap between source code and generated code, leading to debugging challenges and higher contribution barriers. Taro’s experience is cited as a case where exhaustive JSX handling became unsustainable.

Moving Away from JavaScript

Frameworks such as Astro, React Server Components, and Qwik prioritize server‑side rendering and aim to minimize JavaScript on the client, treating JavaScript as a potential performance liability for the first paint.

Conclusion

The article concludes that next‑generation frontend frameworks are still in a phase of quantitative growth, adhering to the established mental model of view development, and that developers should evaluate these trends critically to avoid unnecessary “involution.”