Introducing Quarkus quickjs4j: Seamless JavaScript Integration in Your Quarkus Applications

[giscus[bot]]

Introducing Quarkus quickjs4j: Seamless JavaScript Integration in Your Quarkus Applications

Quarkus: Supersonic Subatomic Java

https://quarkus.io/blog/quickjs4j/

[vemilyus]

Hi, JS on the backend in Quarkus is certainly something a lot of people have been waiting for.
Is there a particular reason you went with QuickJS instead of GraalJS?
Just seems a curious choice to me.

[andreaTP]

AFAIK the embeddable GraalJS Engine doesn't offer any NodeJS APIs

My knowledge on this aspect might be a bit outdated 😅, but I believe the argument still holds when you consider the execution model, memory sharing etc.

Thanks for pointing this out!

[thomaswue]

Yes, @andreaTP is completely wrong here with respect to the security claims. Graal.js does not by default expose Node.js APIs. In fact, security sandboxing is actually a strong point for Truffle languages with detailed options for in general constraining host access that you can find here.

I think it would be great if Quarkus could offer an option to choose between QuickJS and GraalJS so developers can choose the one that better fits their trade off. GraalJS does offer a lot better peak performance and supports newer ECMAScript features including ECMAScript 2024.

[hrgdavor]

I am a big fan of efforts like this. And the choices made here fit perfectly how I would like to use JS in Java. I am not complaining about graal JS, I am using it and it is fine for me... I just love that this is more compact.

I personally love that TS was the reason we have great IDE support for JS now, but I have no plans of using TS, jsdoc is just fine to me.

So, regarding ecmascript support, I am more interested in knowing where it is to adjust my coding, rather than being able to use the latest and best form ecmascript.

Another question is, as I did not dig deep, does this use some bytecode generation that then makes it problematic to run on newer version of Java without upgrading dependencies ?

[andreaTP]

Hi @hrgdavor 👋

So, regarding ecmascript support, I am more interested in knowing where it is to adjust my coding, rather than being able to use the latest and best form ecmascript.

Here you can find the details of QuickJs.

Another question is, as I did not dig deep, does this use some bytecode generation that then makes it problematic to run on newer version of Java without upgrading dependencies ?

QuickJs is compiled to Java bytecode at build time(in the quickjs4j library), there is no Java bytecode generation happening at runtime.
We don't expect issues in this regard and QuickJs4J supports Java 11+, if you experience something different, is a bug 🙂

[andreaTP]

@thomaswue apologies for the confusion around the NodeJS API, I appreciate the clarification and look forward to learning more about GraalJS’s isolate-based sandboxing.

While we chose QuickJS for its WASM sandboxing benefits and to meet Apicurio's immediate needs, I have a lot of respect for the robustness and maturity of GraalJS.
I’m aware the Quarkus team is exploring a more comprehensive polyglot approach, but the timeline is unclear.

Personally, I’d love to see alternate implementations (especially on top of GraalJS!), so we can evaluate tradeoffs in comparable real-world scenarios.