webgl

Figma Rendering: Powered by WebGPU | Figma Blog (opens in new tab)

Figma replaced its WebGL-based renderer with a WebGPU backend to unlock GPU compute, clearer resource management, and better error handling. The migration required more than swapping APIs: Figma redesigned its graphics interface, supported both WebGL and WebGPU, and built tooling to translate existing shaders. The project also improved the existing WebGL renderer by making rendering inputs explicit and reducing opportunities for state-related bugs. ## Why Figma Moved Beyond WebGL - Figma originally chose WebGL to deliver a smooth, browser-based infinite canvas when most design tools were native applications. - WebGPU, supported by Chromium since 2023, enables: - Compute shaders that move parallelizable work from the CPU to the GPU. - Less reliance on WebGL’s bug-prone global state. - More capable and understandable error handling. - The transition had to preserve WebGL compatibility and avoid performance regressions or disruptions during rollout. ## Making Draw Calls Explicit - The previous interface mirrored WebGL’s global-state model: - Buffers, textures, materials, and framebuffers were bound separately. - Resources remained bound after a draw call. - Developers could accidentally reuse stale state. - Figma redesigned `draw()` so that required resources are passed directly as arguments. - The WebGL implementation lazily updates bindings only when necessary, preserving efficiency while making dependencies explicit. - This redesign fixed several WebGL bugs before WebGPU support was introduced. ## Supporting GLSL and WGSL Shaders - WebGL uses GLSL, while WebGPU uses WGSL. - Maintaining separate GLSL and WGSL versions of every shader would have created excessive duplication and maintenance work. - Figma built a custom shader processor that: - Parses existing WebGL 1–compatible GLSL. - Translates it into a newer GLSL structure. - Uses the open-source `naga` tool to convert it to WGSL. - Generates both GLSL and WGSL outputs. - Extracts shader metadata such as input types and data layouts. - Supports file includes for shader reuse and modularity. - This allowed engineers to continue writing and maintaining one primary shader source while supporting both rendering backends. ## Adapting Uniform Data - Uniforms provide shader inputs such as colors and transformations. - WebGL allows uniforms to be updated individually through calls such as `uniform1f` and `uniformMatrix3fv`. - Figma’s original graphics interface followed this model with methods such as `setUniform1f`. - WebGPU requires uniforms to be grouped into uniform buffers and uploaded together. - Consequently, simply switching APIs could have reduced performance; Figma needed to redesign uniform handling carefully rather than directly reproducing WebGL behavior. ## Practical Outcome Figma’s WebGPU migration was an architectural modernization as much as a graphics API upgrade. The recommended approach is to introduce an explicit, backend-independent rendering interface, automate shader translation, and optimize data layouts carefully so WebGPU’s capabilities improve performance without sacrificing compatibility.

7 Moments That Shaped Figma, as Told by Dylan Field | Figma Blog (opens in new tab)

Figma’s story, as told by co-founder Dylan Field, was shaped by unlikely experiences, persistent experimentation, and lessons from mentors and early mistakes. His path ran from child acting and mathematical curiosity to founding a company at 20, with setbacks—including a brief meme-generator idea—helping clarify Figma’s direction. ## Persistence Learned Through Acting - As a child actor, Field once fell asleep during a *Peter Pan* performance, which he considered his most embarrassing acting moment. - The experience nevertheless gave him stunt-flying skills that helped him land a Windows XP commercial. - Auditioning taught him that persistence over time can create opportunities: continuing to try increases the chances of eventually succeeding. ## A Janitor Sparked His Interest in Mathematics - Field was solving algebra problems as early as age six and became bored in middle school. - He spent time with a cerebral school janitor who discussed mathematics and physics with him. - The janitor encouraged him to study proofs and set theory, pushing Field toward deeper mathematical thinking. ## An Unusual Fellowship Application - Applying for the Thiel Fellowship, Field answered the question about what most people get wrong by arguing that “chocolate is repulsive.” - He treated the response as a “meta-contrarian” idea—challenging not only conventional wisdom but also Silicon Valley’s tendency to prize contrarian opinions. - The playful, unexpected answer may have helped his application stand out. ## Figma Briefly Considered Becoming a Meme Generator - Field and Evan Wallace initially wanted to use WebGL—the JavaScript API for high-performance graphics in browsers—to build a design product. - Unsure how to apply the technology, they briefly considered making a meme-creation tool. - Field called this five-day period Figma’s “darkest week,” after realizing that memes were not a sufficiently serious direction. - The episode illustrates the founders’ willingness to explore ideas before committing to a larger product vision. ## Growing Into Leadership - At 20, Field struggled with the responsibilities of being CEO after previously identifying more like an intern. - He acknowledged micromanaging because he had intensely considered every part of the product experience. - Pressure to launch and control the details created tension, teaching him that building Figma required developing as a manager as well as refining the product. The post presents Figma’s development as the result of accumulated experiences rather than a perfectly planned startup journey. Field’s advice and example emphasize persistence, intellectual curiosity, experimentation, and the willingness to learn from immature decisions.

Why Developers Should Embrace Creative Coding Again | Figma Blog (opens in new tab)

Creative coding once made websites distinctive, expressive, and technically ambitious, but templates and automation have made many sites predictable. The author argues that modern browsers now offer even more creative possibilities than before, yet designers and developers often remain constrained by outdated conventions. Reviving experimentation can help turn the web back into a medium for artistic expression rather than merely a container for information. ## From Handcrafted Websites to Templates - In the early 2010s, custom websites served as digital calling cards and demonstrated developers’ technical and creative skills. - Developers used emerging HTML5 capabilities such as: - Inline SVG - GSAP-powered animations - WebGL experiments - Complex CSS illustrations - Website builders and templates eventually made sophisticated features accessible to everyone. - This democratization was valuable, but it also encouraged predictable designs built around familiar patterns. ## The Browser’s Creative Evolution - Browsers now support capabilities that exceed those found in many design tools. - Important advances include: - Container queries - Advanced CSS scoping, inheritance, and responsive behavior - Dynamic units and sophisticated layouts - Improved typography, color handling, and animation - Adaptation to user preferences - Many newer designers and developers remain unaware of these features and continue working within older design paradigms. ## Modern Color and Design Possibilities - CSS supports color spaces beyond standard RGB, including: - HSL - OKLCH - These color spaces allow more vibrant and controlled gradients and transitions. - The author created a Figma plugin called **CSS color-mix()** to help connect modern CSS capabilities with design workflows. - As design and development converge, design tools can become places for experimentation rather than merely production and handoff. ## Creative Coders as Examples - Henry Desroches creates responsive websites with the precision and dimensionality of print design. - Sarah Drasner has demonstrated the expressive potential of SVG animation and illustration. - Tim Holman’s projects, including **Optical Toys** and **The Useless Web**, embrace playful experimentation. - Lynn Fisher treats viewport changes as part of the artwork, creating illustrations that transform with the browser’s width. - These creators show that templates can be starting points rather than limitations. The author encourages developers and designers to experiment with the browser’s full capabilities. By moving beyond templates and embracing creative coding, they can make websites that are more intentional, surprising, responsive, and expressive.

Why Roles Are Not Rules | Figma Blog (opens in new tab)

Figma CTO Kris Rasmussen argues that engineering roles should guide collaboration, not restrict who participates in product decisions. As products become more collaborative and nonlinear, engineers must contribute not only to implementation but also to deciding what to build. However, collaboration works best when teams balance broad input with clear ownership, milestones, and momentum. ## Collaboration Beyond Traditional Roles - Modern product development is increasingly multiplayer, shaped by: - Web technologies such as WebGL and WebAssembly - Collaboration tools like Google Docs - Hybrid and remote work - Engineers are no longer simply responsible for executing plans created by product managers and designers. - At Figma, engineers help determine both: - **How** to build products - **What** to build - Cross-functional collaboration includes working closely with product peers and incorporating customer feedback. ## Early, Open Design Work - Teams are encouraged to gather diverse perspectives at the beginning of a project. - Engineers write down early ideas in concept documents rather than waiting until proposals are polished. - Feedback is collected during the drafting process, allowing designs to evolve collaboratively. - This approach helps expose problems earlier, though it can be difficult to obtain timely feedback from teams focused on their own work. ## Engineering Crits as Feedback Forums - Figma holds regular engineering “crits” across design and engineering organizations. - Crits provide: - Early and frequent feedback - Expert input on technical designs - A dedicated forum for cross-team participation - They are explicitly **not approval meetings**: - No decisions need to be finalized during the session. - Participants identify problems and improve designs without immediately choosing a solution. - Figma uses FigJam so participants can collaborate in real time. - The goal is to improve a proposal until it no longer requires formal approval. ## Balancing Input with Direction - Collaboration can become counterproductive when teams receive too many conflicting ideas. - Excessive feedback may cause projects to: - Lose focus - Get stuck in endless exploration - Struggle with ambiguous tradeoffs, such as defining an initial pricing model - Teams need a balance between: - Diverging to explore possibilities - Converging to make progress - The right balance depends on the organization, culture, product, and desired outcomes. ## Milestones and Momentum - Figma breaks projects into clearly defined milestones. - Milestones help: - Set expectations with stakeholders - Signal when exploration should give way to decisions - Preserve forward momentum - Momentum makes goals feel attainable, while losing momentum can cause teams to question their direction and spin in circles. The practical lesson is to treat roles as areas of responsibility rather than rigid boundaries. Invite collaboration early, use structured forums for feedback, and establish milestones that make it clear when the team must stop exploring and move forward.

React at 60fps: improving scrolling comments in Figma | Figma Blog (opens in new tab)

Figma improved comment-scrolling performance threefold by targeting unnecessary React work during canvas panning and zooming. Although comment pins must recalculate their positions on every viewport update, unrelated fixed-position UI components were also re-rendering. By isolating viewport-dependent updates and optimizing comment transformations, Figma moved closer to its goal of maintaining 60fps even in files with many comments. ## The Performance Goal - Figma aimed to render the editor at 60fps, which is substantially smoother than 15 or 30fps. - Growing numbers of comments and threads exposed slowdowns while users panned and zoomed around the canvas. - Comment pins are anchored to canvas content, so their positions must continuously respond to viewport changes. ## Figma’s Rendering Architecture - The editor combines WebGL, WebAssembly, TypeScript, and React—effectively a browser-based design tool with a dynamic React interface. - Viewport updates are stored in Redux. - Comment components read viewport state and calculate their positions relative to the canvas. - Unlike static React interfaces, comments move as part of the canvas and must update frequently. ## Diagnosing the Bottleneck - Chrome Performance tools showed that JavaScript consumed most of the frame time. - With 30 comments, approximately 68ms per frame was spent on JavaScript, producing about 19fps. - React Profiler showed that rendering the comments themselves took only about 1.8ms. - The larger problem was unnecessary re-rendering of fixed UI elements such as: - The left panel - Toolbar - Properties panel - Comments list - Other components that did not depend on viewport movement - This revealed that viewport updates were propagating too broadly through the React component tree. ## Preventing Unnecessary Re-renders - Figma narrowed which components subscribed to viewport changes. - Components that did not need changing viewport data were prevented from re-rendering. - The optimization focused on separating dynamic canvas-attached comments from fixed interface elements. - Reducing this wasted React work freed time in each frame for the comment pins that actually needed updates. ## Optimizing Comment Positioning - Comment pins must transform their positions whenever the canvas viewport changes. - Figma optimized the transformation calculations and the way those updates were applied to the components. - This reduced the JavaScript cost of moving many comment pins simultaneously. ## Results - Scrolling comments became roughly three times faster. - The improvements brought performance closer to the 60fps target. - Figma planned to continue improving performance as files and comment counts scale. The main lesson is to profile both browser execution and React rendering separately. For highly interactive views, performance depends not only on optimizing the visible components, but also on ensuring that unrelated parts of the application do not re-render in response to high-frequency state updates.

How to build a plugin system on the web and also sleep well at night | Figma Blog (opens in new tab)

Figma’s plugin system had to let untrusted third-party JavaScript interact with a powerful, browser-based design editor without compromising security, performance, or stability. The team evaluated several isolation strategies, ultimately favoring JavaScript Realms because they supported synchronous APIs and avoided the performance costs of a full interpreter. Figma later replaced that implementation with a JavaScript VM compiled to WebAssembly after a vulnerability was found in the third-party Realms shim. ## Why Plugin Isolation Was Difficult - Plugins needed access to Figma’s document model while remaining isolated from: - User data and credentials - Figma’s internal application state - Other plugins - The host page and browser APIs - Simply calling `eval(PLUGIN_CODE)` would execute arbitrary code in Figma’s main environment. - Figma’s architecture added constraints: - The editor relied heavily on WebGL and WebAssembly. - Parts of the interface used TypeScript and React. - Multiple users could edit files simultaneously. - Plugins also needed to remain performant and avoid breaking as Figma evolved. ## Attempt 1: The `<iframe>` Sandbox - The team first considered the browser’s standard isolation mechanism: sandboxed `<iframe>` elements. - An iframe could separate plugin code from Figma’s main page and restrict access using browser security policies. - Communication between the plugin and Figma would use mechanisms such as `postMessage`. - However, this created an important limitation: iframe communication is asynchronous. - Figma’s plugin API needed synchronous access to document operations, making an iframe-based architecture awkward and potentially expensive. - The iframe approach also introduced additional browser contexts and messaging overhead. ## Attempt 2: A JavaScript Interpreter Compiled to WebAssembly - The second approach was to run plugin code inside a JavaScript interpreter rather than the browser’s native JavaScript engine. - The interpreter could expose only explicitly approved Figma APIs, providing a strong security boundary. - Compiling the interpreter to WebAssembly offered a way to integrate it efficiently with Figma’s existing WebAssembly-heavy architecture. - The drawbacks included: - Interpreted JavaScript would be slower than native execution. - The interpreter would require ongoing maintenance and compatibility work. - Supporting the full JavaScript language and modern features would be difficult. - Although attractive from a security perspective, this approach appeared to impose too much performance and implementation cost at the time. ## Attempt 3: JavaScript Realms - Realms provided a separate JavaScript global environment within the same browser process. - Figma could execute plugin code in a distinct Realm while exposing a carefully controlled plugin API. - Unlike iframes, Realms allowed plugin calls to remain synchronous. - Unlike a custom interpreter, plugin code could use the browser’s native JavaScript engine. - The implementation required carefully controlling built-in objects and preventing plugins from escaping their isolated environment. - This approach offered the best balance of: - Native JavaScript performance - Synchronous API access - Isolation from Figma’s application state - A relatively small integration surface ## Later Security Change - After publication, Figma discovered a security vulnerability in the third-party Realms shim used by its original implementation. - The vulnerability was fixed before public disclosure, and Figma reported no evidence that it had been exploited. - Figma subsequently changed its sandbox to use a JavaScript VM written in C and compiled to WebAssembly. Figma’s experience shows that plugin systems require more than simply restricting access to browser APIs. The isolation boundary must also preserve performance and API usability, while being robust enough to withstand vulnerabilities in the underlying sandbox technology.

How you can design end to end on a Chromebook | Figma Blog (opens in new tab)

Chromebooks, once considered too limited for professional design, can now support an end-to-end design workflow when paired with cloud-based tools. The author’s year of using Chrome OS professionally shows that Figma, web apps, and cloud storage can replace most desktop software, although custom fonts, internet access, and specialized audio/video work remain limitations. ## Why Switch to a Chromebook? - The author moved from a Mac at Square because Chromebooks offered: - Stronger security - Lower cost - Automatic file backup and synchronization - Using a Chromebook helped the author understand coworkers who used Chrome OS. - Because Figma already ran in the browser, the transition was easier than expected. ## Six Things Designers Should Know About Chrome OS - **Figma is essential:** It is the author’s preferred cloud-based design tool and works natively in the browser. - **Keyboard shortcuts differ:** The Control key replaces Command, while the Search key can act as a modifier. Figma’s shortcut menu displays Chrome OS-specific commands. - **Performance is sufficient:** Figma performed well across three different Chromebooks. - **Most supporting tools are web-based:** Slack, Grammarly, Funkify, and G Suite worked without major issues. - **Font installation is limited:** Chrome OS does not currently support custom typefaces, though Google Fonts provides many alternatives. - **Internet access matters:** Offline functionality exists, but cloud-based workflows are strongest when connected. Touchscreens are useful for scrolling and navigating canvases. ## Choosing Chromebook Hardware - The author tested an HP Chromebook, the touchscreen-and-stylus Samsung Pro, and eventually chose the Google Pixelbook. - The Pixelbook’s keyboard and trackpad were the deciding factors. - Although it started at $999, it cost less than one-third of the author’s previous MacBook Pro. - Cheaper devices, including the $85 Chromebit, could also support lightweight workflows. ## Cloud-Based Tools for a Complete Workflow - **Creating:** Figma, SuperHi, Google Slides, Paste, Grammarly, Google Docs, and Dropbox Paper. - **Organizing:** Asana, Google Tasks, Bonsai, Notion, and 1Password X. - **Messaging and meetings:** Signal, Telegram, Slack, and Google Meet. - **Media:** Spotify and Pocket Casts. - The author still used a Mac for Final Cut Pro and Logic Pro, since video and audio editing remained desktop-focused. ## The Web as a Design Platform - Cloud software eliminates much of the burden of saving and backing up files. - Files are accessible from any browser rather than being tied to a particular device. - Advancements such as WebGL demonstrate that browsers can handle sophisticated, real-time applications. - The web’s openness and accessibility make it an increasingly viable platform for professional software. Overall, designers who primarily use cloud-based tools can confidently consider a Chromebook, especially if affordability, portability, and synchronized files are priorities. Those dependent on custom fonts or advanced media-production software may still need a traditional computer.

Introducing BrowserView for Electron | Figma Blog (opens in new tab)

Figma introduced BrowserView for Electron to address the performance, stability, and feature bugs it experienced with `<webview>`. BrowserView embeds web apps at the operating-system window level, similar to Chrome tabs, allowing them to perform more like native Chrome content. Although it requires manual positioning and layering, Figma found the trade-off worthwhile and shipped it in Figma Desktop 2.0. ## Why Figma Chose Electron - Figma uses the web to make its design tools broadly accessible. - Its desktop app is built with Electron, extending the web experience to desktop platforms. - Figma had already improved performance through technologies such as WebGL and WebAssembly. - The company also contributed fixes and improvements to Electron and Chromium. ## Problems with `<webview>` - Electron commonly uses `<webview>` to embed remote web applications. - Unlike an iframe, a webview renders content in a separate process, improving security, stability, and performance. - Over time, Figma encountered: - Drag-and-drop bugs - Performance below that of Chrome - Other fundamental reliability issues - Because webview is implemented inside Chromium, fixing its underlying problems would require major Chromium changes. - Figma and Electron maintainers therefore chose to develop an alternative rather than continue waiting for Chromium fixes. ## How BrowserView Works - `<webview>` exists within the page’s DOM hierarchy. - BrowserView lives in the operating system’s window hierarchy, much like Chrome’s browser tabs. - This design benefits from the more mature and actively maintained code paths used for Chrome tabs. - BrowserView eliminates many webview-specific bugs. - Applications embedded through BrowserView can perform similarly to applications running directly in Chrome. ## Trade-offs and Adoption - BrowserViews cannot be positioned or layered using ordinary HTML and CSS. - Developers must manually manage their size, location, and stacking order. - This can be difficult for applications with complex interfaces. - For Figma, converting to BrowserView was relatively straightforward. - At the time of publication, BrowserView was experimental and still planned for further refinement. Figma recommends BrowserView as a promising replacement for `<webview>` when improved performance and reliability outweigh the added layout complexity.

Figma is powered by WebAssembly | Figma Blog (opens in new tab)

WebAssembly reduced Figma’s load time by more than three times after replacing its asm.js-based C++ runtime. The improvement came primarily from faster parsing, native-code compilation, and caching—not from a major reduction in compressed download size. Figma’s experience demonstrated that WebAssembly could deliver substantially faster, desktop-quality web applications, though browser support and implementation differences remained limitations. ## What WebAssembly Changes - WebAssembly is a compact binary format for machine code designed specifically for browsers. - Figma’s C++ code was a strong candidate because C++ can be compiled directly to WebAssembly. - Before WebAssembly, Figma used asm.js, a restricted JavaScript subset that represents memory as a large numeric array. - WebAssembly preserves asm.js’s limitations: - It primarily loads and stores numbers. - It must call JavaScript for browser APIs such as the DOM and networking. - It remains subject to the browser sandbox. ## Why WebAssembly Is Faster Than asm.js - **Smaller and faster to parse:** WebAssembly’s binary format transfers efficiently and parses around 20 times faster than asm.js. - **Ahead-of-time optimization:** LLVM optimizes the C++ code before compilation, allowing browsers to translate it directly to native code. - **Effective caching:** Browsers can cache the translated native code, making subsequent loads nearly free. - **Native 64-bit integer support:** WebAssembly avoids the slower emulation required by JavaScript’s 53-bit integer limitation. - **Less runtime optimization work:** Unlike JavaScript, WebAssembly does not require extensive browser optimization passes for code that was already compiled and optimized. ## Figma’s Load-Time Results - Figma measured load time from application initialization through downloading and rendering an entire design for the first time. - Switching from asm.js to WebAssembly improved load time by more than three times across document sizes. - The gain was especially meaningful because Figma users often work with large documents and switch between them frequently. - Subsequent loads could benefit further from cached WebAssembly-to-native translations. - The compressed download size improved only slightly because compressed asm.js was already close in size to compressed WebAssembly. ## Browser Support Limitations - At the time of publication, WebAssembly was enabled by default in Firefox and Chrome. - Edge and Safari were still developing their implementations. - Figma enabled WebAssembly only in Firefox because Chrome’s implementation had blocking issues, including the lack of caching for translated WebAssembly code. - These browser-specific differences affected whether the performance benefits could be consistently delivered. Figma’s results suggested that teams with substantial C or C++ code should seriously consider WebAssembly for performance-sensitive web applications. The largest benefits were faster startup and reusable native-code caching, while download-size improvements were comparatively modest.

Debugging Data Corruption with Emscripten | Figma Blog (opens in new tab)

Figma encountered intermittent save-file corruption caused by an elusive C++ memory-safety bug. Conventional debugging tools failed because the web app’s asynchronous behavior made the problem nondeterministic. A keyboard-and-mouse fuzzer eventually produced reproducible failures, while understanding Emscripten’s C++-to-JavaScript memory model helped narrow the investigation. ## Detecting the Corruption - Invalid save files appeared occasionally and could not be reliably reproduced. - Figma’s files used ZIP containers around Google FlatBuffers documents. - The serialized bytes looked mostly valid, but some offsets were unexpectedly zeroed. - Data being written to the wrong location suggested a memory-safety violation such as: - Use before initialization - Use after free - Out-of-bounds access ## Why C++ Made the Bug Difficult - C++ was valuable for Figma because it provided: - Access to libraries such as FreeType, HarfBuzz, and Skia - Low-level control suitable for graphics software - Mature debugging and optimization tools - However, C++ offers no built-in protection against memory errors. - The team tried avoiding deallocation, enabling malloc diagnostics, fixing Valgrind and Clang Analyzer findings, and upgrading the compiler, but none exposed the corruption. ## Reproducing the Failure with Fuzzing - The team planned to eliminate nondeterminism by recording user events and replaying them deterministically. - Building a complete session recorder was too large a project, so they limited inputs to keyboard and mouse events. - A fuzzer generated random event sequences and ran them against the application. - After several days, it produced multiple save failures, providing reproducible cases for debugging. ## Emscripten’s Emulated Memory Model - Figma’s C++ editor ran in the browser through Emscripten, which compiled C++ into JavaScript. - JavaScript typed arrays and shared `ArrayBuffer` storage allowed Emscripten to emulate contiguous C++ memory. - In the generated code: - Pointer loads became typed-array reads. - Pointer stores became typed-array writes. - Registers became local variables. - Shared buffers enabled pointer reinterpretation between types. - Emscripten generated asm.js-style JavaScript, using type annotations and operations optimized for JavaScript JIT compilers. The combination of deterministic fuzzing and knowledge of Emscripten’s low-level memory representation provided the path toward isolating the corruption, even though the ultimate fix was reportedly only a three-line change.

Building a professional design tool on the web | Figma Blog (opens in new tab)

Figma set out to prove that a professional, high-fidelity design tool could run reliably in the browser. The challenge was that the web exposed specialized features rather than general-purpose graphics primitives, so Figma effectively had to build “a browser inside a browser.” Its solution combined C++ compiled through Emscripten with a custom rendering engine, enabling tighter control over memory, performance, and cross-platform consistency. ## Building Beyond the Web’s Original Design - The web was originally designed for documents, with application features added later as isolated APIs. - This limits advanced applications: - CSS provides sophisticated text layout but does not expose or customize the layout process. - Browsers have optimized GPU compositors, but developers cannot directly modify compositing or add custom blend modes. - Image decoders are highly optimized but offer limited control over details such as EXIF orientation and color-space handling. - Technologies such as WebGL and asm.js began exposing lower-level access to hardware, making demanding browser-based graphics applications practical. ## C++ and Emscripten - Figma’s editor was written in C++ and cross-compiled to JavaScript using Emscripten. - Emscripten targeted asm.js, allowing JavaScript engines to generate predictable and compact machine code. - This approach provided: - Direct control over memory layout, including compact 32-bit floats and bytes instead of JavaScript’s 64-bit numbers. - Manual allocation that avoids garbage-collection pauses and helps maintain 60 fps. - LLVM optimization and C++ template specialization for performance approaching native code. - More predictable execution because asm.js avoids the deoptimization points common in regular JavaScript. ## Memory Constraints and Indirect Buffers - Large contiguous typed-array allocations caused problems, especially in 32-bit Chrome on Windows, where address-space fragmentation from ASLR could prevent allocations as small as 256 MB. - Figma created an `IndirectBuffer` API to reference external typed arrays from C++. - Moving large image and geometry buffers outside the main heap: - Reduced fragmentation during long sessions. - Allowed better use of limited 32-bit address space. - Helped bypass typed-array size limits in 64-bit browsers. - The post also points toward future improvements from WebAssembly, which would reduce asm.js parsing costs, and shared typed arrays, which would enable shared-memory multithreading. ## Custom Rendering - Figma implemented its own rendering engine to achieve fast, consistent output across platforms. - Rather than relying entirely on browser graphics implementations, the team began building the rendering layer needed for a professional design application. Figma’s broader recommendation is to use low-level browser capabilities such as WebGL and compiled code when standard web APIs cannot provide the required performance or control.

Design Meet the Internet | Figma | Figma Blog (opens in new tab)

Figma’s 2015 launch post argues that creative software should become online, real-time, and collaborative, just as tools like Google Docs had done for documents. Enabled by WebGL, Figma aims to bring powerful vector design into the browser while solving designers’ fragmented collaboration workflows. The company introduced its preview release after three years of development and announced $18 million in funding. ## Why Design Tools Needed the Internet - Designers increasingly work across teams, sharing assets, refining marketing copy, and preparing specifications for engineers. - Unlike engineers, designers lacked integrated tools for designing, commenting, sharing, and storing work collaboratively. - The authors believed browser limitations had prevented creative applications from moving online. ## WebGL Makes Browser-Based Design Possible - Co-founders Dylan Field and Evan Wallace began exploring WebGL in 2011. - Wallace demonstrated that WebGL could reproduce server-side image processing directly in the browser. - This led them to pursue a browser-based creative tool supported by the Thiel Fellowship. - Building Figma required solving difficult problems involving: - Vector rendering - Font layout - Browser performance - Stability across many edge cases ## Introducing Figma - Figma is a browser-based vector interface design tool designed for team collaboration. - The team spent eighteen months using the product internally and working with alpha customers. - Collaboration features included: - Sharing designs through links - Providing contextual feedback - Establishing shared brand colors - Keeping design work accessible in one place ## Preview Release and Future Plans - Figma launched a preview release that invited teams to try the product and influence its roadmap. - Planned improvements for 2016 included: - A stronger Slack integration - Shared team asset libraries - Simultaneous multiplayer editing - The company had raised $18 million from Greylock, Index, OATV, and prominent angel investors. Figma’s launch positioned the browser as a viable platform for professional creative tools. Its practical recommendation was implicit: teams should adopt collaborative, web-based design workflows rather than rely on disconnected desktop applications.