FRESH

Hacker News

JSIR: A High-Level IR for JavaScript

77 points by nnx

by hajile

0 subcomment

I want them to finish the official TC39 binary AST proposal. Nearly twice as fast to parse and a bit smaller than minified code makes it a pretty much universally useful proposal.
https://github.com/tc39/proposal-binary-ast

by sheepscreek

1 subcomments

This is exciting stuff!
My interpretation: If the JSIR project can successfully prove bi-directional source to MLIR transformation, it could lead to a new crop of source to source compilers across different languages (as long as they can be lowered to MLIR and back).
Imagine transmorphing Rust to Swift and back. Of course you’d still need to implement or shim any libraries used in the source language. This might help a little bit with C++ to Rust conversions - as more optimizations and analysis would now be possible at the MLIR level. Though I won’t expect unsafe code to magically become safe without some manual intervention.

by jhavera

1 subcomments

Interesting timing. We have been working on something that takes the opposite design philosophy. JSIR is designed for high-fidelity round-trips back to source, preserving all information a human author put in. That makes sense when the consumer is a human-facing tool like a deobfuscator or transpiler.
We have been exploring what an IR looks like when the author is an AI and the consumer is a compiler, and no human needs to read the output at all. ARIA (aria-ir.org) goes the other direction from JSIR. No source round-trip, no ergonomic abstractions, but first-class intent annotations, declared effects verified at compile time, and compile-time memory safety.
The use cases are orthogonal. JSIR is the right tool when you need to understand and transform code humans wrote. ARIA is the right tool when you want the AI to skip the human-readable layer entirely.
The JSIR paper on combining Gemini and JSIR for deobfuscation is a good example of where the two worlds might intersect. Curious whether you have thought about what properties an IR should have to make that LLM reasoning more reliable.

by fg137

1 subcomments

It's funny they bother to bring up the half dead "Google Closure Compiler" as an example.
And my dumb brain still don't understand how IR is "better" than AST after reading this post. Current AST based JS tools working reasonably well, and it's not clear to me how introducing this JSIR helps tool authors or downstream users, when there are all those roadblocks mentioned at the end.

by pizlonator

1 subcomments

> Industry trend of building high-level language-specific IRs
"Trend"?
This was always the best practice. It's not a "trend".

by jcuenod

0 subcomment

I came across this project in the last couple of days too. Being able to decompile from Hermes bytecode sounds awesome.
Here's the repo: https://github.com/google/jsir (it seems not everything is public).
Here's a presentation about it: https://www.youtube.com/watch?v=SY1ft5EXI3I (linked in from the repo)

by croes

2 subcomments

IR = Intermediate Representation
https://en.wikipedia.org/wiki/Intermediate_representation

by catapart

2 subcomments

asking as someone who is writing a game engine in javascript with the intention to 'transpile' the games' source into a C# project for a native runtime: this provides a map that allows automated translation from javascript source to C# source, right?

by conartist6

1 subcomments

They're presenting this under the banner "the need for source to source transformations."
That seems a bit disingenuous given this is not a source-preserving IR! All comments and nonstandard spacing would be completely removed from your code if you gave it a round trip through this format. That doesn't sound like 99.9% source recovery to me...