useEventfulState() has landed! Check Here for more info.

New features and bug fixes will land in the private github repo before becoming available on the Asset Store. To request access to the repo, please send an email or pm Singtaa#4915 on Discord with your Github username and OneJS Order/INV number.

OneJS Limitations

3rd Party JS Modules

One of the goals of OneJS is to cut dependencies on browser and NodeJS. When you are working with OneJS, you are working restrictly within the confines of the Unity environment. Therefore, browser features not supported by UI Toolkit are most likely not supported by OneJS. And here we are talking about hard browser features like Canvas, SVG, Web Audio, complex CSS selectors, CSS animation keyframes, etc that are currently not supported by UI Toolkit.

(You can use UI Toolkit's Vector API as a direct replacement for Canvas. And SVG is on UI Toolkit's roadmap.)

So you need to keep this limitation in mind when using 3rd party JS modules (via npm for example). Libraries like Preact, Tween.js, and Lodash that have zero or minimal dependency on browser features besides some DOM manipulations, they will work with OneJS out-of-the-box.

But things like three.js will obviously not work. Same goes for libraries that make heavy use of CSS animations. The time you save on using these libraries may not be worth the effort you need to put into polyfilling the missing browser features.

(In light of CSS Animations, UI Toolkit does support UI Transitions which are limited in scope but fairly easy to work with and performant!)

In general, if your goal is to be able to use all 3rd-party browser and node modules out-of-the-box with Unity, you will have to go for an embedded-browser solution. OneJS is for folks who want to do Preact & JSX with UI Toolkit and don't want to embed full-blown webviews in their apps.

Custom Editor UI

Currently, OneJS is for runtime only. However, custom Editor Window support is on our roadmap.

WebGL

Currently you can actually use OneJS with WebGL. But keep in mind that UI Toolkit itself can be buggy in WebGL, and WASM linking can be (really) slow if you preserve whole assemblies like in the example link.xml. As time goes, UI Toolkit should become more stable with WebGL builds.