<@U02BUAY35QW> regarding the Clojure Compiler disc...

# javascript

[Edoardo Luppi]

@broadway_lamb regarding the Clojure Compiler discussion, and the fact the JS code has to be parsed and potentially lowered to older targets, what about using the TS compiler API?
It's just a random idea, but it gives you a visitable AST + the ability to downlevel by compiling it. Yes, you'll have to implement a separate program (and exchange data with it, e.g. via a pipe?) to translate TS AST to something you can read in Kotlin, spawn a separate process, but it doesn't seem totally crazy. With tsgo this might become even easier as it won't require a Node instance to be running.

[Edoardo Luppi]

For tsgo https://github.com/microsoft/typescript-go/pull/711

[broadway_lamb]

We haven't considered it. Delegating the parsing to a separate process sounds like a massive performance issue. One of the benefits of GCC is that it's written in Java, so should be usable from Kotlin pretty easily. But we're open to considering other JVM-based parser implementations, provided that they are both mature and are actively maintained.

[Edoardo Luppi]

I think the problem with JS parsers written in Java is they won't ever be up to date, no matter what, as they can't keep up with the rapid evolution that's happening now.
Rhino survived for a long time just because JS was pretty much stale.

> Delegating the parsing to a separate process sounds like a massive performance issue
For context, that's how TS compiler plugins are going to work in the future, so I bet Microsoft is thinking ahead and optimizing for this use case. Plugins will communicate through IPC.
IIRC, in the current set up under Node.js you can provide your own CompilerHost and do everything in memory if necessary, so once a Node process is up it shouldn't be a massive hit in perf.