(I work on Figma's renderer, but I don't know much of the history of it.) The speculation there about C++ vs JS performance in Figma seem about right to me. N

(I work on Figma's renderer, but I don't know much of the history of it.) The speculation there about C++ vs JS performance in Figma seem about right to me. Notably, some Figma views (like when you click the "play" button to view the prototype) render Figma documents using JS, no* Wasm. They are more or less comparably as fast as the C++ renderer, in part because much of the heavy lifting is done by GPU code that isn't C++ or JS anyway. The main place I think we've seen a performance difference is, as the post observes, high throughput scenarios: for example, decompressing a large file, or parsing through a large binary serialization of a file. But particularly in a browser setting you end up wanting to get your data into a browser API at some point and that often ends up meaning copying data around that eats your performance. The other main difference that's worth pointing out is memory efficiency. For example, pointers in Wasm are currently 32 bits, which means (at least in principle) a massive graph -- such as a Figma document DOM! -- can be represented with 32-bit C++ pointers rather than 64-bit JS pointers. But even that distinction is not so clear in the presence of pointer compression [1] and there are other graph representation options etc. In all, my conclusion is that performance does not obviously derive from tool choice because there are so many confounding factors including algorithm choice and path dependence. For another example of this, I often think of this comment[2] by the esbuild author (coincidentally, also behind a lot of Figma code) where he found better performance with Go than Rust, which is not what I think anyone (including him) would expect up front. [1]: https://v8.dev/blog/pointer-compression https://v8.dev/blog/pointer-compression [2]: https://news.ycombinator.com/item?id=22336284 https://news.ycombinator.com/item?id=22336284 * there is some wasm in there actually but it's not for performance reasons