Loom is the closest thing to a true HTML and CSS alternative to Unity's UI Toolkit. UI Toolkit borrows the shape of the web — UXML resembles HTML, USS resembles CSS — but it is a Unity-specific reimplementation. Loom runs a real browser engine inside Unity, so your interface is genuine HTML, CSS and TypeScript, with the full web ecosystem behind it.
What UI Toolkit gets right
UI Toolkit is a capable system, and for many projects it is the right default. That is worth saying plainly before talking about its limits.
- It is free and built into Unity. No license, no extra dependency, nothing third-party to rely on.
- It is Unity's strategic direction for UI, so it keeps improving, and editor tooling already runs on it.
- It uses one retained-mode model and one styling system across editor and runtime UI.
If your project is small, or your team has no web background, UI Toolkit is a sensible choice. The rest of this page is for teams who keep hitting its edges.
Where UI Toolkit frustrates web developers
UI Toolkit was designed to feel familiar to web developers. In practice the familiarity is where the friction starts: it looks close enough to the web that the gaps are a surprise every time.
- USS is a subset of CSS. Unity's own documentation describes it that way. Properties, selectors and layout behaviour you rely on from the web are partially supported or missing, and you spend time discovering which.
- UXML is an XML dialect, not HTML. Close enough to feel familiar, different enough to keep tripping you up.
- There is no npm ecosystem. You cannot drop in React, Solid, Tailwind or a component library. Anything the web would give you for free, you rebuild in C#.
- Logic lives in C#. If your team's strength is TypeScript and modern frontend, that strength does not carry over.
- Iteration goes through a domain reload, which breaks the tight save-and-see loop web developers expect.
None of this makes UI Toolkit a bad system. It makes it a Unity system shaped like the web, rather than the web itself.
How Loom is different
Loom takes the other approach. Instead of reimplementing web concepts in C#, it embeds a GPU-accelerated browser engine in Unity and paints its output into the render pipeline. Your UI is a real web page.
- Real CSS: flexbox, grid, transitions, transforms, the full cascade.
- Real TypeScript and the npm ecosystem: React, Solid, Tailwind, component libraries, all of it.
- Hot reload. Save a file and the change appears in Play mode in under a second, with no domain reload.
- A typed bridge. Tag a C# class and Loom generates matching TypeScript, so game state and UI stay in sync with autocomplete and compile-time checks.
- Browser DevTools for inspecting and debugging the live UI.
Loom is a paid framework and a third-party dependency. That is the honest trade: you give up "built in and free" to get the real web stack and its ecosystem.
UI Toolkit vs Loom, side by side
| Unity UI Toolkit | Loom | |
|---|---|---|
| Markup | UXML (a Unity XML dialect) | Real HTML |
| Styling | USS (a subset of CSS) | Full CSS: flexbox, grid, transitions, transforms |
| UI logic | C# | TypeScript / JavaScript |
| Component ecosystem | Unity packages only | npm (React, Solid, Tailwind, and more!) |
| Iteration loop | Domain reload | Hot reload, under a second |
| Rendering | Unity mesh-based UI | GPU browser engine |
| Game ↔ UI data | Manual C# binding | Typed, generated C#-to-TypeScript bridge |
| Debugging | UI Toolkit Debugger | Browser DevTools |
| Cost | Free, built into Unity | Paid / free during beta |
| Engine support | Unity | Unity today; Unreal & Godot planned |
Which should you choose?
Stay with UI Toolkit if…
- The project is small, or light on UI.
- Nobody on the team has web or frontend experience.
- A built-in, free, zero-dependency system matters more than workflow speed.
- You are building Unity editor tooling — that is UI Toolkit's home ground.
Choose Loom if…
- Your team already knows HTML, CSS and TypeScript and wants that to count.
- The game is UI-heavy — menus, inventories, HUDs, shops, settings — and you want to build it quickly.
- You want real CSS and the npm ecosystem instead of a subset.
- Fast iteration matters and the domain-reload loop is slowing the team down.
The two are not mutually exclusive. Loom runs as its own UI layer alongside Unity's built-in systems, so a team can use Loom for the game's runtime UI and keep UI Toolkit for editor tooling.