Canvas, meet code: Building Figma’s code layers

Last week, we launched code layers in beta, a new layer type in Figma Sites rendered by React code. Users can use code layers to bring the full power of the web to the visual canvas, building interactive experiences with forms, shaders, interactions, and APIs. At the same time, code layers act like other Figma layers in that they can be nested inside frames, used in components, and moved and resized freely on the canvas. Additionally, users can instantly convert designs built in Figma to code layers with the click of a button and add behavior using the same AI model that powers Figma Make.

Building code layers in Figma required us to reconcile two different models of thinking about software: design and code. Today, Figma's visual canvas is an open-ended, flexible environment that enables users to rapidly iterate on designs. Code unlocks further capabilities, but it’s more structured—it requires hierarchical organization and precise syntax. To reconcile these two models, we needed to create a hybrid approach that honored the rapid, exploratory nature of design while unlocking the full capabilities of code.

Doing this successfully required solving three challenges:

1. Integrating code layers and components naturally into Figma's ecosystem
2. Building a powerful yet easy-to-use IDE to power code customization
3. Enabling multiplayer collaboration between designers and developers

Code as a material

Code is traditionally structured as a filesystem—a tree of directories, with code files as the leaf nodes. While this model is great for development, it’s difficult to square with Figma’s spatial 2D canvas. For example, objects can exist anywhere in the visual canvas, whereas code files exist in a specified location in the filesystem. This mismatch creates practical challenges for the workflow: How do you copy a visual layer when it corresponds to a specific file location? Is the source of truth the canvas or a filesystem? Should cloning a code layer create an instance of it—as is the norm in code—or create a forked version, which is how duplication in Figma traditionally works?

We knew we needed code in Figma to feel familiar to designers and developers, which meant that users should retain the ability to freely manipulate code layers on the spatial canvas. The solution we arrived at was to implement code layers as a new canvas primitive. Code layers behave like any other layer, with complete spatial flexibility (including moving, resizing, and reparenting) and seamless layout integration (like placement in autolayout stacks). Most crucially, they can be duplicated and iterated on easily, mimicking the freeform and experimental nature of the visual canvas. This enables the creation and comparison of different versions of code side by side. Typically, making two copies of code for comparison requires creating separate git branches, but with code layers, it’s as easy as pressing ⌥ and dragging. This automatically creates a fork of the source code for rapid riffing.

We chose to support React because its component model aligns closely with Figma’s notion of components. Components in Figma are reusable and flexible building blocks that designers use to construct interfaces. React works the same way—developers combine reusable React components to build screens and apps. Additionally, React’s props map directly to Figma’s notion of component properties, so we linked them together; you can define properties in code, and then edit them visually with customizable controls like toggles, sliders, and dropdowns.

A batteries-included IDE on the web

While code layers can be created and edited entirely with AI, we knew users would also want to edit code directly for full flexibility. To make this seamless, we built a modern code editing experience into Figma, starting with our choice for the core engine for the IDE: CodeMirror.

CodeMirror provides an extensible base for web-based code editing, allowing us to define extensions for features such as color themes, find-and-replace, and line numbers. In many cases, we needed to override default behaviors to integrate the code editor into Figma; for instance, we replaced CodeMirror’s default undo/redo behavior with a custom implementation based on our own undo stack.

We recognized early on that performance could become a bottleneck, especially for large codebases. IDE tasks like bundling and typechecking can be slow, and because JS is single-threaded, they can cause the UI to hang when processing large files. To keep Figma’s code environment feeling fast, we run most of the development toolchain in a Web Worker. Inside the worker, we use esbuild (created by Figma Co-founder Evan Wallace) for fast bundle times, and Tailwind v4 with Lightning CSS for efficient style compilation. These tools are partially written in native code and compiled to WebAssembly, providing a significant performance boost.

To minimize dependency management complexity, we automatically install imported packages from NPM or an ESM URL. No need to initialize a package.json—just import the libraries you need and start building in a secure sandbox. Most packages will work out of the box inside Figma, including community favorites like Motion and React-Three-Fiber.

Making code layers collaborative

Multiplayer collaboration is at the heart of Figma, enabling teams to work efficiently together to design and ship great experiences. Our multiplayer technology supports simultaneous syncing for many node fields, like position and color. But it had never been used for a field as complex as source code, which can potentially be thousands of lines of text.

This new requirement presented an opportunity to rethink our approach. The simplest solution for syncing edits is last-write-wins, where changes from each user overwrite whatever other users have changed. This works for short pieces of text, such as bits of UX copy in a Figma design, but breaks down when editing large source code files simultaneously, especially on slower connections. We also saw that this problem became worse when AI models made simultaneous edits to the code, creating additional conflicts.

So we looked for better alternatives, turning to classic collaborative text editing algorithms like Operational Transformations (OTs) and Conflict-Free Replicated Data Types (CRDTs). OTs transform concurrent operations so they can be applied without conflicts. They form the foundational technology for many collaborative text editors, such as Google Docs. However, they slow down when merging files with many conflicts, since all conflicting edits must be transformed against each other.

Conversely, most CRDTs treat each character as an independent entity. This makes merging edits significantly easier, but results in a higher memory overhead. To process updates, the entire history of the document must be rebuilt in memory, even if there are no concurrent edits (which is the most common use case). This creates memory bloat and reduces performance.

Fortunately, a paper published last year introduced Event Graph Walker (Eg-walker), a new algorithm with most of the benefits of OTs and CRDTs. Eg-walker represents edits as a directed acyclic causal event graph. Its algorithm is analogous to a git rebase; it rearranges multiple divergent branches into a linear order. To merge concurrent events, Eg-walker temporarily builds a CRDT structure. After its resolution algorithm completes, Eg-walker discards the internal CRDT, freeing up memory. In the happy path of sequential, non-conflicting edits, updates are nearly zero-cost. As a result, it’s as fast as CRDTs at merging, but has minimal memory overhead like OTs.

Given the performance and memory advantages, we used the Eg-walker algorithm to build the multiplayer collaboration service for code layers. When a user edits a code file, the client sends a list of edits to the server. The server reconciles simultaneous edits from all active clients using Eg-walker, and sends back an updated list of edits, resolving any conflicts. With this architecture, the multiplayer service handles the most computationally expensive merging work for all clients, enabling fast initial load times and a performant user experience even for large filesystems.

The future of code and design

Code layers are just the beginning for code in Figma. We anticipate bringing even more direct manipulation to code layers to close the gap between code and design workflows even further—enabling users to seamlessly switch between mediums depending on what they need at any given moment.

In his talk "Inventing On Principle," interface designer Bret Victor says that “creators need an immediate connection to what they’re creating…when you’re making something, if you make a change, or you make a decision, you need to see the effect of that immediately.” As we continue to extend the capabilities of code in Figma, we're guided by this idea: Rather than siloing design and code into separate tools, we should all be able to create together in a shared environment.

Code layers are in beta now in Figma Sites. We can't wait to see what you build!

We're hiring engineers! Learn more about life at Figma, and browse our open roles.