Use the /collab command on Discord to gain access to the OneJS private repo. The repo offers early access to the latest features and fixes that may not yet be available on the Asset Store. An early preview of OneJS V2 is available on branch onejs-v2. It brings major performance improvements, zero-allocation interop, and a new esbuild workflow.
Doc Menu

Why OneJS?

OneJS integrates widely adopted techs such as Typescript and (P)React into Unity, providing a familiar and powerful toolset for UI design. The use of React ensures maintainable and scalable UI code, while also enabling fast iteration speed for a streamlined development process.

  • Fast Iteration: The interpreted JavaScript allows for instant reloading of code changes, significantly speeding up your UI designing process. (Web devs take this for granted, but C# compilation and Domain reloading speed haven't been kind to us Unity developers).
  • Browser-less: OneJS directly integrates with Unity's UI Toolkit, avoiding the need for a browser and simplifying access to UI Toolkit's DOM features.
  • Web-centric Techs: OneJS supports popular web techs like Preact, Tailwind, Styled Components, and Emotion, enabling developers to work with familiar tools and improve productivity in Unity.
  • A Script Engine: Besides being an UI solution, OneJS is also a Script Engine for Unity. You can access any .Net objects/classes/namespaces from Typescript. This means you can easily give scripting capabilities to your players if you choose to. (Think WoW Addons, but instead of Lua+XML, you've got Typescript+JSX).

Having fast iteration speed is a special trait to UI Development. And here's why:

It's important to have clear boundaries between different systems, such as Core Logic, Rendering, Audio, Physics, Input, and UI. This allows for better management of dependencies and reduces the risk of changes in one system affecting others.

UI's goal is to access and reflect the state of the game and also to provide ways for players to alter the game state. Thus, your UI code can depend on basically all the other systems in your game, but not vice-versa (no other systems should depend on UI).

Changes to your UI code will not have any effect on the rest of the systems, allowing for rapid iteration speed without consequences!

On the other hand, any changes made to the public APIs of Physics, for example, will have a cascading effect on Core Logic, Input, and UI.

(Good use of Dependency Inversion and Events (or any Pub/Sub) mechanisms will make sure your other systems don't need to know anything about UI)