Article by Mohammad Reza Arashiyan
In the past few days, I had the opportunity to explore the new UI system in Unity called UI Toolkit. As a programmer who has coded with all versions of UI in Unity, I examined the UI Toolkit and created two experimental projects with it. You can find the screenshots and codes I discuss in this article at the following links:
In this article, I aim to provide a completely experiential comparison based on my coding experience with UI Toolkit, UGUI, and IMGUI. I will answer questions from my perspective that could have an impact on the coding standards of a team. During the writing of this article, the latest stable version of Unity 2022.3 was used.
Is UI Toolkit ready for use in commercial products?
Personally, my answer to this question is “No“. However, when stating this “no,” I paused several times. The reason for this “no” is not the lack of functionality or failure to meet the needs of a game developer. Instead, it’s because when using UI Toolkit, your perspective must completely shift from that to a Web Developer or UI developer. This means no traditional Animation Key Frame and Animator systems. There is no more animations based on 2D Skeleton or Sprite Sheets which are officially supported with built-in UI Toolkit tools.
However, UI Toolkit has almost all the tools you use in UGUI by default or can be developed very fast. (source) Moreover, the power of UI Toolkit in terms of performance and data binding in some cases is better than UGUI.
In this section, I can recommend that if your game includes numerous UI pages with a considerable number of fields that need to be displayed to the user and are constantly changing, you should definitely consider using UI Toolkit.
Otherwise, enjoy UGUI!
Build UI fearlessly and collaboratively!
If you’ve worked collaboratively on UGUI, you’ve probably experienced the fear of conflicts in your Git merges! Due to the structure of UGUI, where you have to store UI in Scenes or Prefabs, no matter what architecture or coding precision, you’ve likely encountered the Merge Conflict Found error sooner or later!
UI Toolkit’s UI Document, UXML, and USS structures, the foundation of forming a UI Module and Contaıner, are designed for collaborative programming.
First of all, everything can be modularized easily, and you can divide a large page into smaller modules and then assemble them with just a few clicks without any strange architecture.
Secondly, due to the difference in the structure of Prefab and UXML files, if a conflict occurs between two UXML or USS files, it can be easily fixed with a simple eye movement.
No more Serialized Events!
One of the main problems with UGUI, in my opinion, is that it doesn’t establish a clear standard or pattern for programming Events. While all variables and events can be initialized through the editor, they can also change dynamically and through code simultaneously. Worse, these two changes are not observable in Editor; assigned events in the code layer are not visible in the editor and cannot be tracked.
This problem can indeed be solved with proper communication among team members, but imagine how new teams struggle with setting and debugging their functions and actions. Now, UI Toolkit has unified the task; every event for every element in the UI must be created, initialized, and executed through code. No more editor, drag and drop, or functions that become obsolete due to a name change. Oh, I really appreciate their decision!
Forget about knowing HTML and CSS!
Your code in UI Toolkit ultimately translates into UXML and USS, which are essentially types of XML and CSS. Many friends I spoke to were concerned about not knowing these two languages, thinking that working with and learning UI Toolkit would be a complex task.
From my perspective, what you need in the initial encounter with UI Toolkit is a proper Understanding of the Structure of Containers and How Elements Are Positioned next to each other (those who have done frontend programming will understand what I mean). Understanding this structure is like knowing an algorithm in programming. You can still find a favorite programming language, but if you don’t know algorithmic programming, you probably won’t be able to do much with that language. Understanding how to create a UXML structure that is both standard and responsive is similar to knowing algorithmic programming in other programming languages.
Secondly, UI Toolkit has a very complete and efficient editor, minimizing your need for direct interaction with the code layer. So you rarely need to directly write XML, CSS, and HTML code.
Effective Debugging Tools for Developers
Like the Developer Console in internet browsers (such as Chrome), two efficient Debugging Tools have been provided for monitoring the structure of Visual Elements, Styles, and UI Events. The existence of such tools for multi-layered UIs composed of various modules is a great advantage. Moreover, you can make temporary changes to styles and elements at runtime using these tools and incorporate their results into your code after finalization.
Conclusion
If you search the internet, you’ll find various opinions from users. The reality is that every tool has its strengths and weaknesses, and UI Toolkit is no exception. Considering Unity’s roadmap, UI Toolkit still has a long way to go to become a complete tool. Therefore, to judge it, you should not imagine a complete and finished product. In my opinion, UI Toolkit, as an evolving tool, is a good tool with high potential for progress, and it will likely be the future of Unity’s UI System. In the face of such a tool, you should learn it and work with it on experimental projects. However, refrain from incorporating it into the production line, as tools like UI Toolkit often undergo significant changes in their structure when transitioning to release versions, requiring serious refactoring if your product is built based on them.