Search Unity

C# + CSS vs C# + UXML + CSS

Discussion in 'UI Toolkit' started by chaaaddd, Jul 4, 2020.

  1. chaaaddd

    chaaaddd

    Joined:
    Nov 9, 2019
    Posts:
    6
    Is there any downside to not using UXML? I'm not a fan of UI Builder currently, so I was thinking of just skipping UXML and just use C# + CSS. It's just much faster for me.
     
    chaaaddd, Jul 4, 2020
    #1

  2. Xarbrough

    Xarbrough

    Joined:
    Dec 11, 2014
    Posts:
    1,188
    Here are some things to consider:

    Do everything in C# if the use-case is small or you're working alone and you like it all in one place.

    Use C# + USS to separate styling from code. This speeds up tweaking values, since colors etc. may change rapidly, but the UXML structure changes less often.

    Separate C#, USS and UXML for large tools, to split functionality, styling and hierarchy elements into multiple files. Either simply to keep everything organized, when working on different aspects or when splitting work with multiple team members. Or, when using the ui builder.

    I personally, use C# + USS in many small editor tools, since it gives me the biggest workflow boost when I work alone.

    The downside to not using UXML will be that you won't be able to simply open up your hierarchy in the ui builder. Also, you will need to recompile your code to rebuild the hierarchy, whereas UXML can add a new element with a simple asset reload.
     
    Xarbrough, Jul 6, 2020
    #2

  3. Guedez

    Guedez

    Joined:
    Jun 1, 2012
    Posts:
    827
    Needing to wait 3 days and a half for the assembly to recompile and needing to leave/enter play mode every single time you change a small value on any of the elements is a pretty big deal for me
    Just being able to preview the UXML in editor is enough for me to toss all of the asset store UI solutions I have in the trash.
    How big of a deal the penalty for not using UXML is entirely dependent on the size of your project and complexity of the UI. I think a mixed workflow where you use c# for small things and UXML for complex things is the preferable way. There is no need to rigidly do only one of either
     
    Guedez, Jul 6, 2020
    #3

  4. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    1,231
    All of what they said above, plus:

    It's worth noting that UI Builder != UXML/USS. It's just a tool, like a code editor, that authors UXML/USS. So I'm curious if it's the C# vs. UXML/USS your asking about or C# vs. UI Builder. We will always support writing UXML/USS by hand in a code editor and loading that in UI Builder or the reverse.

    But I'd still like to know what you don't like about the UI Builder. :)
     
    uDamian, Jul 6, 2020
    #4

  5. chaaaddd

    chaaaddd

    Joined:
    Nov 9, 2019
    Posts:
    6
    I don't know UXML so it's just another thing to learn. I'll learn it if there's a performance boost from me using it, but as of right now it would take me longer to develop then just C# + USS. I'm learning USS because of the performance boosts.

    @uDamian It just seems very limited at this point and it's been easier for me to do the layout in C# than in UI Builder. I struggled with things like button layout when trying to make toolbars. I also think there should be zero knowledge of UXML required to use it. I had to learn all about flex just to try to get layout I wanted.

    I did go back today to play with it more and I was able to get most of the way there with UI builder for a very simple UI, but anything complex it's more difficult. For reference I was trying to replicate the Unity Project Settings menu and I just couldn't do it. My game is very UI heavy with complex UIs and I'm just not sure it's there yet. Hopefully when it's out of preview.
     
    chaaaddd, Jul 7, 2020
    #5

  6. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    1,231
    Flex is the layout engine driving UI Toolkit. You will still have to deal with flex even if you do the entire UI in C#. The layout rules are exactly the same whether you use C#, C#/USS, or C#/USS/UXML.

    UXML is just a quicker way to compose the static hierarchy of your UI than C#. It's faster to iterate on it because you don't have to compile C# and domain reload. And it's also clearer what the structure/hierarchy of the UI looks like, by design. In C#, you have to keep around references to every single element so you can add more child elements to them or change their styling. But most elements don't deserve a C# reference because they have zero C# logic associated with them (think, a static Label, or VisualElement container).

    And UXML does not need to be complicated. Something like this is enough to start seeing the benefits:

    Code (CSharp):
    1. // main.uxml
    2. <ui:UXML xmlns:ui="UnityEngine.UIElements">
    3.     <ui:VisualElement>
    4.         <ui:Button text="My UXML Button" />
    5.     </ui:VisualElement>
    6. </ui:UXML>
    7.  
    8. // main.cs
    9. var ui = AssetDatabase.LoadAsset<VisualTreeAsset>("main.uxml").CloneTree();
    10. ui.Q<Button>().text = "My C# Button";
     
    uDamian, Jul 7, 2020
    #6

  7. chaaaddd

    chaaaddd

    Joined:
    Nov 9, 2019
    Posts:
    6
    I guess I just misunderstood what UI Builder was supposed to be. I thought it would be a tool for those of us that aren't and have no interest in knowing UXML/USS a way to develop UI. It seems to just be a code generator for those already in the know.

    If I were developing it, all UXML and CSS would be abstracted away.

    I guess I disagree on it being quicker because I know C# and I have no interest in learning UXML just for this if there's no tangible benefit (not having to compile is not one to me). Every UI I've done using UI Toolkit I've tried in UI Builder/UXML first and then got frustrated and switched to laying it out in C#.

    I don't find this to be true at all. I'm only doing editor UI right now, but 99% of the elements I place need to be hooked into a C# script. I imagine runtime will be similar if you want tweening or any sort of animation.
     
    chaaaddd, Jul 7, 2020
    #7

  8. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    1,231
    Just wanted to say first that if C# works for you, by all means, continue using it. It's not "invalid" in any way and it will always be a supported workflow. All I can say is that we didn't copy the world wide web pattern of HTML/CSS for no benefit. For complex UI, the separation of concerns is a real benefit that pays off in the long term. If the UI is simple, C# (+ USS ideally) works just fine.

    There's no reason you need to look at the UXML/USS when using the Builder. Not wanting to learn UXML/USS _IS_ one of the reasons to use it. We would not have made the UI Builder if we wanted everyone to learn UXML. I was just saying that you can mix-and-match, and that the assets that come out of the Builder are human readable and easily version controlled instead of binary black boxes.

    You're already going through to effort of learning the C# API, USS styles (whether inline or in a .uss file), and the flexbox layouting engine that drives UI Toolkit. That's 90% of the complexity of UIT. If you know <OpenTag> </CloseTag> basic XML syntax, you know UXML. There's not much more to it.

    If you are building a lot of Editor UI, worth noting that we have a bindings system that works on top of SerializedObjects. This means for many fields (like IntegerField, Toggle, etc.), you could implement them entirely in UXML with no C# code at all. The binding system just needs a bindingPath that is the name of the property and it takes care of all change tracking both on the object and in the UI. For this reason (and until we have a built-in binding system for runtime), Editor UI actually benefits far more from UXML than runtime game UI.
     
    uDamian, Jul 7, 2020
    #8