Webassembly

19 posts

figma3 min readCurated summary

How to convince your team to switch to Figma | Figma Blog

Buffer’s move to Figma was presented as a cultural change, not merely a software upgrade. Figma helped break down design silos by making files accessible, collaborative, and usable across platforms. James Morris’s approach was to build support through experimentation and demonstrations rather than simply arguing for the switch. ## Buffer’s Transparency and Collaboration Challenges - Buffer valued transparency, but its existing design tools isolated designers from other departments. - Designs were difficult to locate in Dropbox and often required paid software or newer versions to open. - Developers and product managers worried about accidentally overwriting files. - Figma’s cloud-based files could be opened through shared URLs, with free view-only access for collaborators. - Linux users could access designs without buying a Mac or specialized desktop software. - Viewers could comment and inspect design data for implementation. ## Step 1: Create an Open Exploration Period - Morris introduced a company-wide period for testing different design and collaboration tools. - Teams were encouraged to experiment and identify which tools best addressed their workflow problems. - He gathered feedback and explained how Figma could solve Buffer’s communication issues. - Rather than relying only on a persuasive presentation, he trusted hands-on use to demonstrate Figma’s value. ## Step 2: Show, Don’t Tell ### Collaborative Whiteboarding with Product Managers - Morris used remote whiteboarding sessions to let product managers experience Figma directly. - He and a Canadian PM brainstormed together in real time, using shapes and diagrams much like a collaborative Google Doc. - This allowed them to develop ideas together without waiting for a formal specification. - Figma’s ease of use became apparent through practical collaboration. ### Winning Over Engineers - Morris gave engineers direct links to Figma files and let them explore independently. - Engineers could inspect CSS, Swift, and Android XML values through the free view-only experience. - Stable URLs created a single source of truth, replacing exported images and confusing Dropbox locations. - Figma’s browser-based architecture and use of WebAssembly also appealed to engineers interested in advanced web technology. ### Addressing Designers’ Concerns - Designers could be more difficult to persuade because some feared open, transparent workflows. - Others doubted that a browser-based application could match the speed and performance of desktop software. - The article begins describing the use of incentives—“candy”—to help designers try Figma, but the provided text ends before that section is completed. The practical recommendation is to make tool adoption an open, low-pressure experiment. Give each team a concrete way to experience the benefits—real-time whiteboarding for product managers, inspectable files for engineers, and performance demonstrations for designers—so the change becomes evident through use.

Read original(opens in new tab)
figma2 min readCurated summary

Introducing BrowserView for Electron | Figma Blog

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.

Read original(opens in new tab)
figma3 min readCurated summary

Figma is powered by WebAssembly | Figma Blog

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.

Read original(opens in new tab)
figma3 min readCurated summary

Building a professional design tool on the web | Figma Blog

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.

Read original(opens in new tab)