I do honestly forget that UMXL exists as I primarily use both the UI Builder and code my Visual Elements when it comes to UI Toolkit.
I usually only remember UXML when I peruse my difs in source control… or something goes wrong and I need to manually edit it to fix it.
Recently I was thinking about a lot of the features added to UI Toolkit. [UxmlElement], [UxmlAttribute], UxmlAttributeConverter’s, UxmlObject’s and such… and started to realise: aren’t all these features just making up for the fact that by opting for this UXML approach, that UI Toolkit effectively gave up all the already fairly powerful serialization that Unity has?
With that in mind, it feels like a lot of features are reinventing the wheels, features we could have had years ago if UI Toolkit opted to use the existing serialization Unity has.
I understand that one reason why UXML was chosen is because it allows web devs to port their existing experience over to Unity. But I also wonder what amount or percentage of Unity devs doing UI are using UXML directly compared to using the UI Builder or just via code.
Don’t get me wrong, I very much enjoy UI Toolkit, particularly the CSS-like styling system, and being able to directly code my visual elements. But I do wonder if a different decision had been made however many years ago, if UI Toolkit would be in a better position than it was now?
I could also just be missing some number of other technical considerations that led to UXML being the path taken.
One of the main reasons for having the UXML format is to have an easily diffable textual format in case of merge conflicts. This is something that is often requested when multiple people work on the same UI screens/controls. YAML is not great at that.
With that in mind, it feels like a lot of features are reinventing the wheels, features we could have had years ago if UI Toolkit opted to use the existing serialization Unity has.
I do agree with this and the UXML Serialization feature is one step towards bridging that gap.
One thing that personally irks me is that we don’t have a good support for using a VisualTreeAsset as-is, meaning there is no round trip to .uxml. If we improve the support on that side, I think it could unlock a lot more scenarios.
5 Likes
Just want to add something else here. Back when we introduced UXML and VisualTreeAsset, Unity did not support polymorphic serialization. Which means that any subclass of VisualElement would need to have a matching ScriptableObject equivalent to serialize correctly. It was a big drawback and even a challenge for us internally to implement the standard control library.
This is the main reason why custom VisualElements needed to declare UxmlFactory/UxmlTraits as we effectively implemented a custom serialization system.
A few versions later, polymorphic serialization was added which opened the door to the UXML Serialization system (although it did take a few years to get to it).
I just want to provide historical context as to why the decision to not use native Unity serialization was made in the beginning.
Custom serialization comes with embedding strings somewhere and while a few Unity features used JSON, we felt that an XML based format was more appropriate for UI.
5 Likes