Search
SW Tutorial

React vs Angular vs Vue: Build One App in 12 Steps [2026]

Tahlia Rourke
Tahlia RourkeCloud & Software Reporter
23 min read
React vs Angular vs Vue: Build One App in 12 Steps [2026]

React, Angular, and Vue all shipped fresh updates within a week of each other in October 2026. React landed version 19.3.1 on 14 October, Vue pushed 3.5.44 on 13 October, and Angular followed with 22.2.2 on 8 October. None of the three is slowing down, and that makes the old “just pick one and move on” advice less useful than it sounds. If you are starting a new project in Australia this quarter, you need a way to compare them that goes beyond blog opinions.

This tutorial takes the practical route. You will build the same small task dashboard three times, once in React 19.3.1, once in Angular 22.2.2, and once in Vue 3.5.44, using each framework’s current tooling. Along the way you will scaffold projects, wire up components, add routing and forms, create production builds, and measure bundle size and runtime performance using the same methodology for each. By the end you will have three working apps and a decision framework you can apply to your next client project, not just a gut feeling about which framework js ecosystem “feels” faster.

Most “which framework should I learn” write-ups answer the question with an opinion dressed up as a fact. This one is deliberately slower and more hands-on, because the honest answer depends on variables only you know: your team’s existing skills, how long the app needs to live, whether you are hiring contractors in a tight Sydney or Melbourne market, and what your client actually asked for. A consultancy shipping a six-week marketing site has different constraints to a bank replacing a decade-old internal tool, and no single ranking article can account for both. Building all three versions yourself, even just the small dashboard Tells you more about where each framework gets in your way than any amount of reading will.

The stakes are real. According to the 2025 Stack Overflow Developer Survey, React was used by 44.7% of all respondents in the web frameworks category, with Angular at 18.2% and Vue.js at 17.6%. Among professional developers specifically, usage shifts slightly to React at 46.9%, Angular at 19.8%, and Vue.js at 18.4%. Usage share is not the full story, though. “Among all respondents, React had a 52.1% admired score, compared with 44.7% for Angular and 50.9% for Vue.js,” according to the 2025 Stack Overflow Developer Survey. That gap between Angular’s usage and its admired score is worth sitting with before you commit a team to it for the next three years.

Google · Preferred Sources

Don't miss new tech stories on Google

Add TrendinTech Australia once in the Google app and our stories appear in your news suggestions.

Add Now

What You Need Before You Start

Set aside roughly 90 minutes to work through all three builds, or about 30 minutes per framework if you want to split the session. Here is the exact toolchain this tutorial assumes, matched to what each framework ships in October 2026.

  • A current Node.js LTS release and a matching npm version, since Angular 22’s CLI and Vite both expect a reasonably modern Node runtime
  • Git and a terminal you are comfortable in (this tutorial uses plain bash commands throughout)
  • A code editor with TypeScript support, such as VS Code
  • React 19.3.1 and react-dom 19.3.1, installed via Vite’s React TypeScript template
  • Angular CLI matched to Angular 22.2.2, the current stable release as of 8 October 2026
  • Vue 3.5.44, the latest patch on the active Vue 3.5 release line, installed via create-vue
  • Roughly 2GB of free disk space for three sets of node_modules folders
  • A spare hour if you also want to run the optional performance benchmarking step

One version note worth flagging: Angular also has a 22.3.0-next.1 prerelease that shipped the same week as 22.2.2. It is chronologically newer but it is a prerelease build, so this tutorial treats 22.2.2 as the current production version and leaves the prerelease alone. Chasing the newest tag instead of the newest stable tag is one of the more common mistakes teams make when comparing frameworks, and it is worth avoiding here too.

Step 1: Plan the Project You Will Build Three Times

Before touching any framework CLI, define the feature set once so all three builds stay comparable. This tutorial uses a small task dashboard: a list of tasks, a form to add a task, a filter toggle between all, active, and completed tasks, and a computed counter showing how many tasks remain. It is small enough to build in each framework within 20 minutes but touches the parts of a framework that actually matter in production work: component structure, reactive state, derived values, list rendering, and form handling.

Parity matters more than people expect here. If your React version gets a loading spinner and your Angular version does not, or your Vue version persists state to local storage and the other two do not, you have introduced a difference that has nothing to do with the framework and everything to do with inconsistent implementation. Write a short checklist of exactly what “done” looks like for the feature before you open a single CLI, and refer back to it for all three builds. It takes five minutes and it is the difference between a fair comparison and three unrelated toy apps that happen to share a name.

Create three sibling folders so the builds do not collide:

mkdir framework-comparison-2026
cd framework-comparison-2026

Everything from here runs inside that parent folder. The table below maps the same concept across each framework’s current vocabulary, which is useful to keep open in a second tab while you work through the steps.

ConceptReact 19.3.1Angular 22.2.2Vue 3.5.44
Component styleFunction component with hooksStandalone component (default since Angular 19)Single File Component with script setup
Reactive stateuseState / useReducersignal()ref() and reactive()
Derived valuesuseMemocomputed()computed()
Side effectsuseEffecteffect()watch() and watchEffect()
TemplatingJSX in the same fileHTML template, inline or separate fileHTML template inside the .vue file
Build toolViteAngular CLI (esbuild-based)Vite

Step 2: Scaffold the React 19.3.1 Version with Vite

React itself does not ship a CLI. The current community default is Vite’s React TypeScript template, which pulls in the latest react and react-dom packages automatically. Run this from inside your parent folder:

npm create vite@latest task-dashboard-react -- --template react-ts
cd task-dashboard-react
npm install
npm install [email protected] [email protected]
npm run dev

You should see Vite’s dev server boot in well under a second, with output similar to this:

  VITE v6.x.x  ready in 180 ms

  Local:   http://localhost:5173/
  Network: use --host to expose
  press h + enter to show help

Open that local URL and confirm you see the default Vite and React starter screen before moving on. If the port is already taken, Vite will automatically try the next one up, so check the terminal output rather than assuming 5173.

Step 3: Build the Task Dashboard Feature in React

Replace the contents of src/App.tsx with the task dashboard logic. This uses plain useState and a derived value computed on every render, which is idiomatic for a component this size in React 19.

import { useState } from "react";

type Task = { id: number; label: string; done: boolean };
type Filter = "all" | "active" | "completed";

export default function App() {
  const [tasks, setTasks] = useState<Task[]>([]);
  const [label, setLabel] = useState("");
  const [filter, setFilter] = useState<Filter>("all");

  const visible = tasks.filter((t) =>
    filter === "all" ? true : filter === "active" ? !t.done : t.done
  );
  const remaining = tasks.filter((t) => !t.done).length;

  function addTask() {
    if (!label.trim()) return;
    setTasks([...tasks, { id: Date.now(), label, done: false }]);
    setLabel("");
  }

  function toggleTask(id: number) {
    setTasks(tasks.map((t) => (t.id === id ? { ...t, done: !t.done } : t)));
  }

  return (
    <main>
      <h1>Task Dashboard (React 19.3.1)</h1>
      <input value={label} onChange={(e) => setLabel(e.target.value)} />
      <button onClick={addTask}>Add</button>
      <p>{remaining} task(s) remaining</p>
      <ul>
        {visible.map((t) => (
          <li key={t.id} onClick={() => toggleTask(t.id)}>
            {t.done ? "done" : "open"} {t.label}
          </li>
        ))}
      </ul>
    </main>
  );
}

Save the file and Vite will hot-reload the browser automatically. Add a couple of test tasks and confirm the counter updates and the click-to-toggle behaviour works before you move to Angular.

Step 4: Scaffold the Angular 22.2.2 Version with the Angular CLI

Angular, unlike React, ships its own opinionated CLI, and that CLI is doing more work than it used to. Standalone components have been the default since Angular 19, which removes most of the NgModule boilerplate that used to make Angular tutorials longer than they needed to be. From your parent folder:

npm install -g @angular/[email protected]
ng new task-dashboard-angular --style=css --routing=false
cd task-dashboard-angular
ng serve

The CLI will ask a couple of setup questions (SSR support, AI tooling integrations) that you can decline for this tutorial. Once it finishes, ng serve should produce output close to this:

Application bundle generation complete.

Watch mode enabled. Watching for file changes...
  Local:   http://localhost:4200/

Angular’s dev server is noticeably heavier to boot than Vite’s because it runs a full TypeScript compilation pass up front, which is a fair trade-off for the stricter typing guarantees it gives you later. Confirm localhost:4200 loads the default Angular welcome page before continuing.

Step 5: Build the Same Feature in Angular with Signals

Angular’s signal-based reactivity, now the recommended default, maps closely to what you just wrote in React, just with a different syntax. Replace the contents of src/app/app.ts (or app.component.ts depending on your CLI defaults) with:

import { Component, signal, computed } from "@angular/core";
import { FormsModule } from "@angular/forms";

type Task = { id: number; label: string; done: boolean };
type Filter = "all" | "active" | "completed";

@Component({
  selector: "app-root",
  standalone: true,
  imports: [FormsModule],
  template: `
    <main>
      <h1>Task Dashboard (Angular 22.2.2)</h1>
      <input [(ngModel)]="label" />
      <button (click)="addTask()">Add</button>
      <p>{{ remaining() }} task(s) remaining</p>
      <ul>
        @for (t of visible(); track t.id) {
          <li (click)="toggleTask(t.id)">{{ t.done ? "done" : "open" }} {{ t.label }}</li>
        }
      </ul>
    </main>
  `,
})
export class App {
  tasks = signal<Task[]>([]);
  label = "";
  filter = signal<Filter>("all");

  visible = computed(() =>
    this.tasks().filter((t) =>
      this.filter() === "all" ? true : this.filter() === "active" ? !t.done : t.done
    )
  );
  remaining = computed(() => this.tasks().filter((t) => !t.done).length);

  addTask() {
    if (!this.label.trim()) return;
    this.tasks.update((list) => [...list, { id: Date.now(), label: this.label, done: false }]);
    this.label = "";
  }

  toggleTask(id: number) {
    this.tasks.update((list) =>
      list.map((t) => (t.id === id ? { ...t, done: !t.done } : t))
    );
  }
}

Notice the imports array declared directly on the component. Standalone components still declare their own dependencies explicitly, which is the trade-off Angular makes throughout: more declared structure up front, fewer surprises later in a large codebase with multiple teams touching it.

Step 6: Scaffold the Vue 3.5.44 Version with create-vue

Vue’s official scaffolding tool, create-vue, sits architecturally close to the Vite React template since Vue also builds on Vite under the hood. From your parent folder:

npm create vue@latest task-dashboard-vue
cd task-dashboard-vue
npm install
npm run dev

When the CLI prompts you, choose TypeScript and skip the router and Pinia prompts for now, since this tutorial adds those manually in a later step so the comparison stays fair. The dev server output looks almost identical to React’s, since both sit on the same Vite base:

  VITE v6.x.x  ready in 210 ms

  Local:   http://localhost:5173/

If React is still running on 5173 from Step 2, Vue’s dev server will automatically shift to 5174. Confirm the default Vue welcome screen loads before moving on.

Step 7: Build the Same Feature in Vue’s Composition API

Replace src/App.vue with the Composition API version of the same dashboard, using script setup syntax, which is the current recommended style across the Vue 3.5 line:

<script setup lang="ts">
import { ref, computed } from "vue";

type Task = { id: number; label: string; done: boolean };
type Filter = "all" | "active" | "completed";

const tasks = ref<Task[]>([]);
const label = ref("");
const filter = ref<Filter>("all");

const visible = computed(() =>
  tasks.value.filter((t) =>
    filter.value === "all" ? true : filter.value === "active" ? !t.done : t.done
  )
);
const remaining = computed(() => tasks.value.filter((t) => !t.done).length);

function addTask() {
  if (!label.value.trim()) return;
  tasks.value.push({ id: Date.now(), label: label.value, done: false });
  label.value = "";
}

function toggleTask(id: number) {
  const task = tasks.value.find((t) => t.id === id);
  if (task) task.done = !task.done;
}
</script>

<template>
  <main>
    <h1>Task Dashboard (Vue 3.5.44)</h1>
    <input v-model="label" />
    <button @click="addTask">Add</button>
    <p>{{ remaining }} task(s) remaining</p>
    <ul>
      <li v-for="t in visible" :key="t.id" @click="toggleTask(t.id)">
        {{ t.done ? "done" : "open" }} {{ t.label }}
      </li>
    </ul>
  </main>
</template>

Notice how much closer Vue’s syntax sits to plain JavaScript than Angular’s decorator-and-template split, while still keeping the explicit reactivity model (ref, computed) that React 19’s hook model also leans on. All three apps now do exactly the same job through three different mental models.

Step 8: Add Routing, Forms, and State Management to Each App

A single-page dashboard rarely stays single-page in production. To make the comparison realistic, add a second route (a simple “About” page) and a shared state pattern to each project. This is also where the three frameworks diverge most in terms of how much you install versus how much ships built in.

# React needs an external router and, usually, an external state library
npm install react-router-dom zustand

# Angular's router and dependency-injected services ship with the framework
# no extra install needed beyond the CLI default

# Vue needs an external router, and Pinia for anything past local state
npm install vue-router pinia

This is the point where “framework bundle size” and “app bundle size” stop being the same number. Angular’s router and DI-based services are already inside the framework you installed in Step 4. React and Vue both keep their core small but expect you to add a router and a state library yourself, which is a deliberate design choice in both ecosystems, not an oversight.

CapabilityReact 19.3.1Angular 22.2.2Vue 3.5.44
Routingreact-router-dom (external)@angular/router (built in)vue-router (external, official)
Global stateZustand, Redux, or Context (external)Injectable services with signals (built in)Pinia (external, official)
FormsControlled components or React Hook FormReactiveFormsModule or template-driven formsv-model with native or Vuelidate for validation
HTTP clientfetch or axios (external)HttpClient (built in)fetch or axios (external)

Step 9: Create Production Builds and Compare Bundle Size

This is the step most comparisons skip or fake. Run the actual production build command for each framework and read the output your own terminal gives you, rather than trusting a number from an old blog post. Bundle sizes shift with every minor release and every dependency you add, so the only trustworthy number is the one you generate yourself, today, with this exact feature set.

# inside task-dashboard-react
npm run build

# inside task-dashboard-angular
ng build --configuration production

# inside task-dashboard-vue
npm run build

Each tool prints a per-file size summary with raw and gzip (or Brotli) figures. Record those numbers in a simple table like the one below, filled in with your own measurements rather than copied figures, since this tutorial deliberately does not publish specific KB values here. Framework comparisons that quote exact bundle sizes without showing the build command, target browsers, and minifier settings behind them are not comparing anything meaningful, they are quoting someone else’s app.

Metric to recordWhere to find itWhy it matters
Raw JS size (dist folder)Build tool’s terminal outputShows uncompressed delivery cost
Gzip or Brotli sizeBuild tool’s terminal output, or gzip -9 on the file manuallyCloser to real-world transfer size
Framework runtime vs app code splitsource-map-explorer, webpack-bundle-analyzer, or rollup-plugin-visualizerSeparates framework cost from your own code
Number of chunksdist folder file listingAffects how many requests the browser makes on load
Build timeTerminal output timestampMatters for CI pipeline cost, not end-user experience

To split framework runtime cost from your own application code, install a visualizer in each project and generate a treemap:

# React or Vue (Vite-based projects)
npm install --save-dev rollup-plugin-visualizer

# Angular
ng build --configuration production --stats-json
npx webpack-bundle-analyzer dist/task-dashboard-angular/stats.json

npm download counts for the react, @angular/core, and vue packages are sometimes used as a shortcut for “popularity,” but treat that number carefully. Downloads include CI runs, mirrors, and repeated local installs, so they measure ecosystem activity, not the number of production apps or unique developers using a framework. The Stack Overflow usage percentages cited earlier Are a sturdier signal precisely because they ask developers directly rather than counting registry hits.

Step 10: Benchmark Runtime Performance

Bundle size tells you about download cost. It does not tell you how an app feels once it is running. For that, serve each production build locally and run the same automated audit against all three, on the same machine, in the same browser, with the same network throttling profile.

# serve the production build (adjust the port for each project)
npx serve dist -p 4173

# run an automated audit against it
npx lighthouse http://localhost:4173 --view

Lighthouse reports Core Web Vitals including Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). Run each audit three times and take the median, since a single run can be skewed by a background process or a cold disk cache. For a task dashboard this small, all three frameworks will likely score well, so the real signal shows up once you add more components, more routes, and more state, which is why this tutorial has you build the full feature set rather than a trivial hello-world.

If you want numbers you can defend in a team meeting, run the audits through Lighthouse CI or WebPageTest instead of a single local Chrome DevTools pass, since both remove more of the variability that comes from your own machine’s background load.

Step 11: Read the Results and Match the Framework to the Job

With three working apps and your own bundle and performance numbers in hand, the decision usually comes down to team shape and project horizon rather than a raw speed gap, since all three frameworks are fast enough for the overwhelming majority of real apps once built correctly.

  • Choose React 19.3.1 if your team already knows it, you need the widest pool of contractors and candidates to hire from, and you want the biggest selection of third-party component libraries
  • Choose Angular 22.2.2 if you are building a large, long-lived enterprise application where built-in routing, DI, forms, and HTTP tooling reduce the number of architecture decisions a large team has to agree on independently
  • Choose Vue 3.5.44 if you want a gentler learning curve for a smaller team, close-to-native-JavaScript syntax, and official first-party router and state libraries without React’s more fragmented ecosystem choices

Angular’s support lifecycle is also worth weighing for enterprise work. Angular 22 entered active support on 3 June 2026, with active support running through 30 June 2027 and security support extending to 30 June 2028, according to the version tracking site endoflife.date. That kind of published support window is harder to pin down for React and Vue, since neither follows the same formal major-version support calendar, which itself is a data point if your organisation needs predictable upgrade planning.

If you are weighing this decision for a client-facing app that also needs secure authentication flows, it is worth reviewing how your forms and login screens handle credentials once you are past the prototype stage, a topic this site has covered in the context of multi-factor authentication gaps across identity providers. The login form pattern you build in Step 8, whether it is a reactive form in Angular, a controlled input in React, or a v-model binding in Vue, is also where credential-handling mistakes tend to creep in, so it is worth testing that flow with the same care you gave the bundle size numbers.

It is also worth being honest about switching costs once a team has shipped real features in any of the three. Rewriting a production Angular application in React, or a React codebase in Vue, is rarely justified by framework performance alone, since the gap this tutorial’s benchmarks will show you is usually smaller than the cost of the rewrite itself. The decision in Step 11 matters most for new projects and for teams that have not yet committed real production code to any of the three, not as a reason to tear up something that is already working.

Meta-Frameworks: Where Next.js, Angular SSR, and Nuxt Fit In

Everything So far compares the three frameworks as client-rendered single-page apps, which is the fairest way to isolate the core library’s own behaviour. In production, though, most new projects reach for a meta-framework layered on top, and that choice changes the comparison again. React developers typically default to Next.js for server rendering, static generation, and file-based routing. Vue developers reach for Nuxt, which plays a near-identical role on top of Vue 3.5. Angular’s server-side rendering is built into the framework itself through Angular SSR, configurable directly from the CLI rather than through a separate third-party package.

This distinction matters for bundle and performance numbers specifically. A server-rendered or statically generated page sends less JavaScript to the browser on first load than a pure client-rendered single-page app, regardless of which of the three frameworks sits underneath it. If your real project needs SEO-friendly pages, fast first paint on mobile, or content that search engines need to crawl, repeat the benchmarking steps Using Next.js, Nuxt, and Angular SSR instead of the plain client-rendered scaffolds, because the gap between client rendering and server rendering is usually larger than the gap between any two of these three frameworks.

Angular’s built-in SSR path is worth calling out specifically, since it is the one place Angular’s “everything included” philosophy pays off most clearly. You do not choose between three competing SSR packages the way a React or Vue project effectively has to; the Angular CLI’s own build command handles it. Whether that consistency is worth the trade-off against Next.js and Nuxt’s larger plugin ecosystems is exactly the kind of decision this tutorial’s benchmarking steps are built to help you make with real numbers instead of a guess.

Common Pitfalls When Comparing React, Angular, and Vue

Most framework comparisons go wrong in predictable ways. Watch for these before you trust any benchmark, including your own.

  • Comparing a development build against a production build. Dev builds include extra warnings, source maps, and unminified code that make the comparison meaningless.
  • Treating npm download counts as a proxy for market share or number of production apps, when they really measure CI installs, mirrors, and registry activity.
  • Benchmarking on different hardware, browsers, or network throttling profiles across the three apps, which introduces more noise than the frameworks themselves contribute.
  • Judging “framework size” by the total app bundle, without separating out the router, state library, and your own application code from the framework runtime.
  • Running each scaffold with a different Node.js or npm version installed locally, which can change build output in ways unrelated to the framework itself.
  • Reading Stack Overflow’s “usage” percentage and “admired” percentage as the same statistic. They answer different questions: one measures how many people use a tool, the other measures how many of its users would choose it again.
  • Assuming the newest version tag is the production-ready one. Angular’s 22.3.0-next.1 prerelease shipped the same week as the 22.2.2 stable release, and only one of those belongs in a production dependency file.

Troubleshooting Guide for All Three Frameworks

These are the errors most likely to interrupt you while working through this tutorial, along with the fix for each.

  • “ng: command not found” after installing the Angular CLI. Your global npm bin directory is not on PATH. Run commands with npx ng instead, or fix your PATH to include npm’s global install location.
  • Vite dev server reports a port already in use. Pass an explicit port, for example npm run dev — –port 5180, or close whatever else is bound to 5173.
  • TypeScript strict mode errors in a new Angular standalone component. Angular’s default tsconfig enables strict mode. Either fix the types properly (recommended) or relax strict rules individually in tsconfig.json rather than turning strict mode off entirely.
  • Vue reports “Failed to resolve component” inside script setup. This is almost always a casing or import path mismatch. Vue component names are case-sensitive in the way you register and reference them.
  • Old React tutorials reference ReactDOM.render and it throws an error. React 19 projects created via Vite already use createRoot from react-dom/client. Copying code from a pre-React-18 tutorial will break on this line.
  • Angular signal updates do not appear to trigger a re-render. Check that you are calling the signal as a function in the template, for example remaining(), not referencing it as a plain property. Also confirm you are not accidentally mutating an object inside a signal without calling .set() or .update().
  • Angular CLI install fails with a Node version warning. Angular 22 expects a current Node LTS release. Update Node before retrying the global CLI install.
  • A production build works but opening dist/index.html directly in a browser shows a blank page. ES module and base-path assumptions in the build output need an actual HTTP server. Use npm run preview, ng serve –configuration production, or npx serve dist instead of opening the file directly.
  • CORS errors when three dev servers call the same mock API on different ports. Add a proxy entry in vite.config.ts for React and Vue, and configure a proxy.conf.json for the Angular CLI, so requests appear to come from the same origin during development.
  • A bundle analyzer command fails with “command not found.” These tools are devDependencies, not global installs. Add them to the specific project with npm install –save-dev before running them.

Advanced Tips for Teams Running More Than One Framework

Many Australian agencies and in-house platform teams end up supporting more than one of these frameworks at once, usually because of acquisitions, legacy systems, or client preference rather than a deliberate architecture choice. A few practices make that easier to live with.

  • Pin exact dependency versions and commit lockfiles for every framework project, then rerun your bundle and performance benchmarks inside a clean CI container rather than on a developer laptop, so results are reproducible months later.
  • If you must integrate React, Angular, and Vue widgets on the same page, lean on web components or module federation as the integration boundary rather than nesting one framework’s virtual DOM inside another’s render cycle.
  • Build an internal upgrade calendar around each framework’s own release rhythm. Angular ships roughly every six months on a published schedule, React ships continuous minor and patch releases, and Vue 3.5 has been patching frequently since its September 2024 release, as tracked on Releasebot’s Vue update log. Treat these cadences differently when planning sprint capacity for dependency bumps.
  • Weight hiring decisions against both usage and admired scores from survey data, not just raw installed base. A framework with a smaller but more satisfied user base can still be the safer long-term hire in a tight market.
  • Keep an eye on each framework’s own release notes rather than secondary blog summaries. Angular publishes first-party notes for every major version, including the Angular 22 release announcement, and React’s changelog lives directly in its GitHub releases page.

If your dashboard eventually needs to talk to an AI feature, such as a chat assistant or a summarisation endpoint, the component wiring you just practiced across all three frameworks carries over directly, whether you are calling a hosted API or a model you are running locally for development and testing. And if the dashboard stores files or exports reports, it is worth comparing storage costs the same disciplined way you just compared these frameworks, which this site has also broken down for cloud object storage pricing.

Build a Complete Working Project: Pulling It All Together

By this point you should have three folders inside framework-comparison-2026, each containing a working task dashboard with add, toggle, filter, and a derived remaining-count, plus a second route and a shared state library wired in from Step 8. That is a complete, deployable starter project in all three frameworks, not a toy example. To finish the exercise properly:

  • Run the production build for all three and confirm each one serves correctly with npx serve or the framework’s own preview command
  • Record your bundle size and Lighthouse numbers in the tables from Steps 9 and 10, using your own measured figures
  • Commit each project to its own Git repository so you have a working reference to return to when the next framework version ships
  • Note which framework felt fastest to build in for your team specifically, since developer velocity on day one is a real cost even when runtime performance ends up nearly identical

Treat this project as a template. Swap the task dashboard for a feature closer to your actual product, rerun the same steps, and you will have a far more honest answer than any generic “best framework 2026” ranking can give you, because it will be based on your team, your feature set, and your own measured numbers.

Frequently Asked Questions

What are the current versions of React, Angular, and Vue right now?
As of 15 October 2026, the current stable releases are React 19.3.1 (published 14 October 2026), Angular 22.2.2 (published 8 October 2026), and Vue 3.5.44 (published 13 October 2026). Angular also has a 22.3.0-next.1 prerelease circulating, but it is not a production-ready stable release.

Is Vue losing ground to React and Angular in 2026?
The data does not support that. Vue.js sat at 17.6% usage among all Stack Overflow 2025 survey respondents and 18.4% among professional developers, close behind Angular, and the framework continues to ship frequent patch releases on its active 3.5 line.

Which framework produces the smallest production bundle?
There is no fixed answer, because it depends on which router, state library, and UI components you add on top of the framework core. Measure it yourself using the build and analyzer commands in Step 9 for your specific feature set rather than trusting a generic number.

Can I use React, Angular, and Vue components on the same page?
It is possible through web components or module federation, but it adds real complexity. Most teams are better served picking one framework per application and using an integration layer only when migrating a legacy app incrementally.

Do I need TypeScript for all three frameworks?
No, but all three support it as a first-class option, and this tutorial uses it throughout because it catches the kind of mismatched prop and state-shape errors that are easy to introduce when building the same feature three different ways.

Which framework is easiest to learn first?
Vue’s syntax tends to read closest to plain JavaScript and HTML, which is often cited as the gentlest on-ramp. React has the largest volume of tutorials and community answers available. Angular has the steepest initial learning curve but gives the most built-in structure once you are past it.

Is Angular only suitable for enterprise applications?
Angular is commonly chosen for large, long-lived enterprise applications because of its built-in router, dependency injection, forms, and HTTP tooling, but nothing prevents a smaller team from using it. The trade-off is more upfront structure in exchange for fewer independent tooling decisions later.

How often do these frameworks release new versions?
Angular ships a new major version roughly every six months, with Angular 22 released on 3 June 2026. React and Vue both ship more frequent minor and patch releases without a fixed major-version calendar, with Vue 3.5 alone receiving patch releases as recently as 13 October 2026.

Related Coverage

Tahlia Rourke

Tahlia Rourke

Cloud & Software Reporter

Tahlia Rourke is the Cloud & Software Reporter at TrendinTech, where she covers cloud infrastructure, enterprise platforms, software development and the digital transformation of Australian businesses. She is particularly interested in what happens after the contract is signed: the migrations that overrun, the bills that surprise and the teams that make it work.

All stories by Tahlia Rourke (5)