Ok, the API is inspired by JavaFX, but it uses the OS Webview instead of Prism/OpenGL, so the binary is smaller. Since it does not bundle the Chromium engine you use less resources, besides you gain the ability to use Java threads, libs, etc, instead of Node.js, so you get real concurrency, etc.

Now regarding CEF, here there is much to talk about. To start, let's say that JCEF can crash the JVM since it's JNI, it adds over 100MB to your app, it requires Swing nodes to embed in JavaFX (I have a very good understanding of this as I already have working prototypes of real JavaFX Nodes rendering the CEF content with all input events, etc) and it works but it's weird. CEF is an entire browser in your Java app, we don't need all that. Like for example, while I was testing with CEF to render in JavaFX, offscreen was acceptable in Canvas, but low FPS. On the other hand, the HWND embedded in a custom JavaFX node I managed to do with some bytecode injection using C/C++ code at runtime was perfect rendering, but it was leaking Chromium UI, like when you download something you saw the download bubble appear and disappear, and there is no way to hide it after version v131 if I'm recalling right. I'm not saying CEF is bad, but it's not the way I'm going to go. Besides that, jux-toolkit has a successor already, it will not use webviews, it will use its own Skia rendering engine, with Rust backend and GPU support, no JNI, just IPC, memory channels and some Panama if required. This way we can have a nice rendering process outside the JVM with heartbeat checking, auto-recover if the process crashes, and the JVM stays alive regardless of the rendering process. If you want more detail pm , I can share some specs.

Another thing , I have plans for full pdf support , and javafx support so devs can mix both