Made a little parser for Figma's file format: https://madebyevan.com/figma/fig-file-parser/. This isn't intended to be used for automation (there are already other libraries out there for that). Instead it's intended to be used for exploring the underlying file structure. It's interesting to see how some things are represented!
Figma .fig file format parser online

@evanw come back to twitter please, i love your posts but this platform is a desolate land
@evanw curious, perhaps naive or silly question, but is the figma kiwi structure parsed and rendered exclusively on the c++/wasm side or is it ever accessed or stored in memory in JS-land? does that matter?
@switz I haven't worked at Figma for quite a while now. But when I was there, it was mainly accessed in C++/WASM and not in JS. The renderer is in C++, so it made sense for the canvas objects to live in C++, so it made sense for kiwi parsing to live in C++.

@evanw interesting, thanks for the insight! Playing around with a similar product (from a tech perspective) and wondering if it’s better to keep the data pipelines and rendering in WASM for memory and performance.

Super interesting stuff! Cheers

@switz Generally yes. In C++ using a byte for an enum and a bit for a bool can be done without giving up good developer ergonomics, while in JS those are 32-bit or 64-bit values. Less memory means more performance (better use of cache). You can also use an arena allocators to go faster than a garbage collector if you're clever.

But that only makes sense for large amounts of data, as WASM may be an order of magnitude larger than JS. Turning trivial stuff into WASM may slow it down.

@switz You can do this stuff in JS too. But it starts to look less and less like writing JS and more and more like writing WASM (manually shuffling data in and out of Uint8Arrays) which harms developer ergonomics. For example: https://mbebenita.github.io/LLJS/
LLJS : Low-Level JavaScript

@evanw this is what I'm starting to realize. there are a huge number of rendering pipelines (essentially 2d game engines) in rust, but they're all somewhat incomplete. go isn't any better. haven't found many for JS-based wasm.

seems like keeping the rendering pipelines in wasm along with the data is a huge win, but I'm struggling to find the right engine for my problem.

I may build the rendering pipeline in pixi.js and try to use culling to only send the relevant display data over the pipe.