Speeding up the JavaScript ecosystem part 11 is here! This time we're looking at: Extending Rust tools with JavaScript plugins marvinh.dev/blog/speedin... - ThreadSky

marvinh.dev • 1 day ago

Speeding up the JavaScript ecosystem part 11 is here! This time we're looking at:

Extending Rust tools with JavaScript plugins

https://marvinh.dev/blog/speeding-up-javascript-ecosystem-part-11/

Comments

jfmengels.bsky.social•2 hours ago

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)

jfmengels.bsky.social•2 hours ago

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.

jfmengels.bsky.social•2 hours ago

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?

jfmengels.bsky.social•2 hours ago

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.

jfmengels.bsky.social•2 hours ago

I'm excited to give this a try for my own linter. Not sure when I could get to this though, hopefully soon.

marvinh.dev•2 hours ago

- Traversal got 10x faster
- there are both Rust rules and JS rules
- properties remain polymorphic (that's how its spec'ed in TSESTree)
- code is in Deno repo

jviide.iki.fi•19 hours ago

Great writeup, thank you 👍

larsgraubner.bsky.social•4 hours ago

Even though I do not know much about ASTs this was easy to follow. Thanks for sharing!

linolevan.com•23 hours ago

Great post!

acemarke.dev•22 hours ago

Nice!

This looks _very_ similar to how the React DevTools serializes updates to the component tree:

https://blog.isquaredsoftware.com/presentations/2023-10-react-devtools-replay/?slideIndex=12&stepIndex=0

/cc @brian.blue

marvinh.dev•21 hours ago

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.

marvinh.dev•21 hours ago

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!

shirakaba.bsky.social•12 hours ago

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.

andrewvijay.bsky.social•22 hours ago

I miss bookmarking feature here on bluesky a lot now. I got all previous posts on this bookmarked on twitter 😭

marvinh.dev•21 hours ago

yeah, agree. Bookmarking is the one feature I miss from twitter too.

tom.engineering•19 hours ago

🔥

rihan.dev•22 hours ago

This series is always so interesting to read, thank you 😃🙏

Comments

Posting Rules

Reply