Web Showdown 2026: “Smart” LIB

People ask me "So, what UI library should I use?"
"Should I use Zustand, like you did, for state?"
(See Web Showdown 2026.)

I use XState from Stately frequently in production. Consumed in Svelte with store contract, it’s pure jazz of UI development — not bound to any component hierarchy. More on the "state" in another post.

Global State is not your desired architectural pattern in 2026. Zustand was perfect in the read-model bench application. It’s minimalist and fast, providing a zero-overhead state driver for the benchmark. It’s also a "Global State" library, like Redux, an antipattern in business SPAs.

What do "smart" people use?

UI Libraries 2026 — the Short.

As you saw in my experiment, the browser is VERY powerful: 1_000_000 nodes in React!

Any library you love will do you good.
Yet people choose differently — let’s see why.

The ultimate context to imagine is the single Bounded Context domain behavior service in an mSaaS or µSaaS vendor application, and you are the vendor. What do you do?

Figure 1. "No shared UI" is the choice we always make because it’s not a choice.

Pick "Do not share UI (React)" in the Android Studio KMP wizard, and the web UI splits off the shared tree. That UI is not a Gradle module; it’s your ordinary JS project. It doesn’t need to be React — it can be anything! See read-model on how to make it a proper Gradle module consuming your Kotlin magic.

Vue 3 — Corporate React ++

I MEAN the Vue 3, not 2 — a very different animal. Vue 2 reached end of life on December 31st, 2023. Compiler-informed VDOM, fully Composition API, ES6 Proxies — a solid swap for React in corporate America. The template compiler leaves patch flags in the generated code, so the runtime diff skips everything static. One official stack: Vue Router, Pinia, and Vite from Vue’s own author.

And I find it easier to teach than React. ref() and computed() track their dependencies on their own: no rules of hooks, no dependency arrays to get wrong. Less ceremony is more work done, as I mentioned in the video.

SolidJS — Performance Choice

SolidJS is an entirely different paradigm — compiled, no VDOM. I dig! The few SPAs I built with it performed very well. I could demo Solid in the read-model bench application if page performance were the key. (Still might, tempted…​)

The remarkable part is the 2-stage process: the compiler turns JSX into real DOM templates with the static HTML pulled out, then a small runtime of signals updates only the nodes that depend on the changed state. Components run once — nothing re-renders, and the DOM-heavy read model stays a little faster.

Qwik — Resumable Rendering

Full disclosure: Qwik is not what I find much use for.
More and more distributed systems folks now reach for it.
Because there is a viable use case.

The "new" paradigm here is resumability instead of hydrating the DOM. And the entire magic is driven by lazy loading. Sure, competent engineers use plenty of lazy where it fits logically. And here, everything is lazy. The key to a perfect Lighthouse performance score is to use LESS JavaScript. Colloquial wisdom says that a 20% faster site makes 10% more conversions. Delayed loading helps on long-funnel landing pages, convoluted and branching page functions, and optional expensive actions that are not frequently used.

Note: I find myself making a clean feature-centric read model and not needing this. My architecture tends to avoid all the aforementioned scenarios. Or perhaps I haven’t met the right use case.

Svelte is ALL you need!

My personal cup of tea! Svelte 5 Runes — compiler directives for explicit reactivity. This library is a long-time favorite of startups. We’re way past the corporate developer here — this is pure joy to build, but only when one loves to build.
Even the story of Svelte is pure hacker lore!

My core appeal: I’ll build an amazing read model in 1/3 the time of React or Vue.

Last weekend I presented Svelte + XState in a KMP project, shared core in Kotlin,
like you see in the read model benchmarking experiment and the Android Studio screenshot above;
and many people went:

"Nice, NEW, thank you!"

Well…​

If engineering is an orchestra, then a UI developer is a trombone player!

I’ve had Svelte with XState in production for at least half a decade. It certainly isn’t new.
And perhaps the next addition to the read model project.

It never gets old — like driving a Ferrari (with a stick, of course). Nah! Even better — a Ducati!

Build something nice! Let me know how it went.

---

On Frameworks

Frameworks are excluded by the apples-to-apples rule!

In one of the buildathons I noticed teams comparing a React bench to a Next.js bench. Next.js is a framework built around the same React. So I understood that unlike in Python or Java ecosystems, JS/TS people say "library/framework" loosely. Here is what each project calls itself:

Project	Self-description	Source
React	"the library for web and native user interfaces"	react.dev
Vue 3	"progressive, incrementally-adoptable JavaScript framework"	vuejs/core
SolidJS	"JavaScript library for building user interfaces"	solidjs/solid
Svelte	"It’s a compiler"	Svelte README
Qwik	"Framework reimagined for the edge!"	qwik.dev
Angular	"The web development framework for building modern apps."	angular.dev

State of JS files them all under "front-end frameworks."

Angular is indeed a framework! I will define the terms scientifically and build the fixtures hacka-terrifically another day. You are welcome to join me, and I’ll be glad to code with you.