Languages and frameworks

Taiga’s agents write code, so what they can build is a finite list rather than a claim about any language. This is that list.

You pick from it as the Stack answer when you set up your organization, and you choose as many as you actually use rather than one.

What is on the list

Choice	What it covers
React	A React single-page app built with Vite.
React Native	An Expo-managed mobile app. See the limit below.
Next.js	Next.js with the App Router, where route handlers and server actions are the backend.
Angular	Angular with the Angular CLI’s own builder, angular-eslint, and the CLI’s test builder.
Node.js	A Node service, with Fastify as the approved framework.
Python	Python with FastAPI or Django.
.NET	ASP.NET Core and C#.
Go	Go, with the standard library and chi.
Rust	Rust, with axum or actix-web.
Other	The escape hatch. See below.

The names are the ones the picker uses, in the order it lists them.

React, Next.js and Angular are separate answers rather than one “frontend”, because the difference between them is the toolchain and not the language. Declaring React at an Angular shop would approve Vite and Vitest at a team that builds with neither. Next.js is its own answer for the opposite reason: it is a backend as well as a frontend, so React alone would leave a real backend undeclared.

What choosing one changes

Your answers are not a label on your account. They generate content.

Each choice adds its rows to your approved technology table, which is part of the architecture policy every project is planned against. So a Go shop gets golangci-lint and Testcontainers written into its own policy, and a Python shop gets ruff and pytest, without anybody typing either list.

That table is then what the planning agent reads when it decides how work should be built. This is why the stack answer is worth getting right before you create a project, and why changing it later shows you what would change before it applies anything.

Mobile stops at the native build

React Native is the one entry with a boundary worth stating plainly, because it is not a limitation you can plan around.

Taiga’s agents work on Linux. They write and test the JavaScript and TypeScript half of an Expo app, which is most of it, and they cannot produce a signed iOS or Android binary. That step needs a macOS machine, your signing certificates and your store accounts, none of which Taiga holds or wants to.

So the approved path names EAS Build for it, and the pipeline that runs it stays yours. Taiga can author the workflow that calls it; you own the credentials it calls with.

What is not on the list, and why

Vue, Svelte and Java are not choices today.

The list is exactly the set the coding agent ships a skill for, and that ordering is deliberate: a skill gets written first, and the option appears after it. The reverse would let you declare a stack the agent then cannot honour, which is worse than not offering it, because you would only find out after planning a project against it.

Angular is what that path looks like when it works. It was absent for the same reason Vue is, until the agent’s Angular skill was written and the option followed.

When yours is not there

Pick Other.

It contributes no rows at all, which is the point. Your approved technology table then says nothing about your frontend rather than asserting something wrong, and a mixed shop can combine it with a backend that is on the list: choosing Python and Other gets you the Python rows and no claim about the framework in front of them.

Picking it is also the signal that matters. It is how a framework earns a skill and becomes a real choice later.

Where to go next

• Set up your organization to make the choice and see what it generates.
• Import an existing codebase if the stack question is really “will it understand what I already have”.