Post

Great article, thank you! I had seen the recommendation of putting the AST in a flat array, but hadn't thought of the JS class idea. That makes the idea a lot more applicable for my linter! I have a few questions if you don't mind (feel free to reply at the end so we don't have many threads)

In practice this doesn't talk much about Rust, this is mostly about passing the data from a Rust program to a JS program? There is no Rust involved in the evaluation of these rules, correct? So you have two systems for running rules: one for Rust rules and one JS plugin rules.

You mention it takes 20.4ms for the traversal (and selector matching). Is that faster/slower than with the original tree structure? The properties array contains very different data, which I'm therefore assuming isn't/can't be monomorphized. Is that correct?

I would love to know more about the serialization part. I imagine you do need to have the full tree in memory to start with? Is there any code that I can take a look at to understand more? I can't find anything resembling in deno_lint.

yeah there are a few similarities in the way the encoding is done. I'd say the key difference is that React DevTools thinks more in terms of operations rather than a full tree structure. All Fibers have the same structure too. Props are different but they're only loaded when you click a node.

When I wrote Preact DevTools back in 2019 we ran into the exact same performance issue as the React team did with their extension. Studied their serialization code quite extensively and adapted it a little for use with Preact. Learned a lot about data formats from them. Was an amazing time!

Very cool, and great writing as always. I’ve heard this “arrays, not trees” sentiment for AST-traversal come up a few times in the last couple years. I heard on the Devtools podcast that Tailwind and/or VoidZero (can’t recall) are investigating the same. The idea came up on Hacker News too.