uGUI or UI-toolkit?

So I'm about to embark in some serious optimization, I've got benchmarks up the nose with pretty much every other aspect of Unity so I'm asking the community what their experience is with this new UI.
How does it compare with uGUI in term of usability, code binding and performance? With the WISIWIG builder, I ain't touching css.
And does it run on the Switch in URP?

 

Well so far my experience with UI Toolkit (previously known as UI Elements) has been really useful for Editor UI. I would love to use it for Runtime but I wouldn't say it is production ready, by far.
- Unity 2020.1 is still in beta
- UI Toolkit doesn't have feature parity with UGUI yet
- UI Toolkit is in preview (and I think it is even hidden from the package manager)

I can't tell that much about runtime usage other than it just isn't ready for it yet. I've tried it out a little bit to just conclude it ain't ready yet. We require world space, grid and also a nodegraph which aren't implemented yet.

As for Editor usage, I've built quite some tools out of it and I love the way of binding code with the UI.
If I were to compare that to UGUI then UGUI has been a pain to work with. We have a very complex project that is 99% UI based. Binding the many elements with many conditions has been far from easy.

If you'd want some experience with UI Toolkit I'd suggest by start building Editor tools to get a feeling of how it works.
But for runtime, I'd stick with UGUI for now and keep it simple so that an eventual conversion to UI Toolkit will be quick and easy.

 

alright thanks @MaskedMouse I'll stick to it

 

Either way have a look at this post:
https://forum.unity.com/threads/ui-toolkit-1-0-preview-available.927822/

"This is the first of many versions of the preview package that we’ll be releasing throughout the year. In the upcoming months, we’ll be improving workflows, performance, and documentation, with the goal of shipping a pre-release version for 2020.2 by end of year.

In 2021.1, the UI Toolkit that ships with Unity will be considered production-ready. We'll continue to make the preview package available to give you early access to features in development."

 

UIT Runtime has like 5% of the functional the Editor part has. And even that functional has like 7% of what css offers.
UnityUI or IMGUI-based solutions is currently the only option if you want something substantial.

 

3/3 say stick to ugui, I'll do that.
@etienne_unity I'd like to start seeing a performance table and a workflow table.
uGUI for example is a pleasure to design UI in, no idea about uitk, imgui is a nightmare

 

I see wisiwig for the new one, that's cool, got a video of the editor running? Or simpler: does it function like uGUI?

ok maybe some of us can inspire real life benchmarks and you can come up with a standard. I'll start:

1. 100x world to screen transform with health bar composed of one black background rectangle and one green to red foreground rectangle
2. 100x 128x128 buttons on a static black background, then on an animated background
3. 100x animated gizmos on a static black background, then on an animated background
4. 100x text blocks of 128x128 on static then animated background

 

Those are meant for the documentation - to help us choose

 

That's interesting, so you have an extra hierarchy view embeded and everything is a style, loving how you can change the look of all buttons with a few clicks and live. Did you end up borrowing uGUI excellent anchor menu in more recent drops?

 

Is it intended to be a superset of uGUI in term of layouting and performance?

 

That's a tall order and with the certain track record with promises, I'll believe it when I see it.

 

I believe it certainly will surpass uGUI at some point. So far I really love UI Toolkit. The only thing missing for me is it being on par with all uGUI features. Theres no grid component (hopefully a GridView), no world space canvas, a NodeGraph, 2-way binding(?).
I can imagine people wanting to use Editor UI for Runtime UI as well. UI Toolkit closes that gap quite a bit since the tool can be used for both Editor & Runtime UI. whereas currently it is uGUI for runtime and IMGUI for editor. 2 completely different ways of setting up UI.
How awesome would it be if you could just drag drop a Color Picker and use it in Runtime as well as the Editor?

One of the things that made my life a lot easier is the ListView. I love the way of binding data. A simple List, a MakeItem and BindItem method. And it should be more performant as well as the List is only rendering the in view parts and not the entire list. Something uGUI does not do out of the box, even a bit difficult to get in as well. Large lists with complicated items are just not performant.
Also one of the big advantages is UI and Programming can be done separately. Which is a huge deal. Normally with uGUI you'd work in the Scene, adding events to buttons. And the programmers have to create all kinds of scripts and they have to be attached to the uGUI GameObjects. Even do lots of management at a higher level of the UI, which is tedious. Whereas in UI Toolkit you name the element and the programmer queries for that element name to bind it. The only bridge in between a UI designer and UI programmer are the element names and a bit of functional designs of what it should do.

So yeah I hope development accelerates quite a lot for feature parity with uGUI and stability. As I am super excited to actually be able to use this at runtime. But like I said before, it just isn't ready for production just yet. I've been working with uGUI since it got released and UI Toolkit is a great relieve.

 

? show me what you mean.

UIT is super promising. I like how you focus on how good instantiation and binding are, so important so I'll keep my finger on the pulse of this project and see it doesn't get the UNET (etc...) shafting.

 

A node graph like the Shader Graph

 

I have made a tutorial about UI Toolkit for Runtime :]
Creating a runtime interface of a simple game, using UI Toolkit - UIElements.

Check it out here:
forum.unity.com/threads/course-tutorial-ui-toolkit-for-runtime-new-unity-ui-framework.1016665/

 

Borrowing this thread to ask: is it possible to use both uGUI and UI Toolkit in the same project? Or is it somehow ill adviced? As UI Toolkit is still lacking for example world canvases, could I use UI Toolkit for the HUD and uGUI for all the in-world UI:s?

EDIT: to answe my own question, I tried this. It seems you can use both UIToolkit and UGUI in the same project. Even in screen space. Not sure if there are any drawbacks on this though.

 

I wish there were more samples showcasing how to go about realistic migrations of UI systems in production projects (other than this page in the manual). It's not trivial how to minimize the amount of stuff that must be done again from scratch (which feels like close to everything), which is a big issue for small teams. For UI-heavy applications, it feels like doing the entire project again from scratch.

For example, if I wanted to put a whole screen that exists already in uGUI on a scroll view, I wish I could set up a UI-toolkit background with a scroll view visual element that could contain the uGUI legacy stuff I already have. Right now, unless I am mistaken, I cannot do this. I must re-do my whole interface in the new system.

I am guessing something like a uGUI container in UI Toolkit. @uDamian, would this be possible?

 

Thank you @antoine-unity, I think the thread you linked hinges at what I was trying to get at.

Regarding your question: I think the current documentation on the matter is way too brief (https://docs.unity3d.com/Manual/UIE-Transitioning-From-UGUI.html). I wish there was something like the tutorials on Unity Learn in which there could be a real walkthrough for transitioning a uGUI interface into UI Toolkit. In other words, I wish a form of documentation that is relatable to the headaches that many developers are experiencing right now while they learn to think in the ways of the new framework.

I also wish there were more explicit clear-cut statements from Unity about when developers can combine the two frameworks, and when they simply can't and should not try. For example, I am realizing that maybe it would not be possible to achieve my use-case stated above without something like a uGUI container. Therefore, although it will very painful, I will need to redo my whole user interface from scratch in UI Toolkit if I want to accomplish the stated goal. I only realized this after I read your thread. The linked documentation talks about rendering order, but there isn't much about what the limits are of possible integrations between the frameworks. Perhaps something as small as a FAQ may be useful.