sbox UI: My current gripes, hopes and general thoughts

[DoctorGurke]

Making game ui in sbox is great. I love the balance the current system provides, between c#-first ui, with optional html templates, scss stylesheets and now even full razor files, all of which hotload! That said, it needs to be considered that the game is in heavy development and therefore has some rough egdes here and there, and with the recent addition of razor and the potential (?) future replacement of html templates, there's some things I'd like to mention and point out.

I'm aware that the "downsides" I'm going to mention should get issues made for them, but I want to first point out general thoughts, potentially getting feedback, before moving on to making issues for specific things.

C# ui "scripting"

C# rules. It's nice too look at, nice to use, has great support with a number of different editors/IDEs and a lot of material online. Considering how all the other game code is C#, it's great to have some sort of unity between systems, including UI.

html Templates

Don't want to tediously lay out your UI in C#? Sounds very reasonable in my book, considering that it doesn't lend itself very well to more complex layouts and will become very messy very quickly. Html templates are optional and apply on top of the csharp panel class to layout its elements. The best part is, it can bind itself to C# to a degree and hotloads super fast! It's as easy to use as literally sticking an attribute on the panel class and having an appropriately named file in the right place. No ambiguity involved here.

scss Stylesheets

Don't think I need to say much about how good scss styling works for ui. It's kinda made for it. Works especially well when combined with html templates, so there aren't a bunch of magic strings for styling strewn across your C# code.

Note: Would be nice if the [StyleSheet] attribute worked without a parameter and just used the appropriately named local scss file, just like how [UseTemplate] works.

Razor

Now comes the latest addition to the ui system (UI2?), razor. It's basically the combination of all the three above, plus some weird magic that allows you to seemlessly switch between layout instructions and c# code, with optional embedded stylesheets via <style> and code blocks via @code.
Being the new kid on the game UI block in the sbox context comes with a few issues, however.

Currently, I'm aware of some troubling problems that, quite frankly, make the razor ui files very unattractive to use for me:

• The embedded style and code blocks don't get the love they would in dedicated files. Things like cleanup/format and code analysis just straight up don't work on them. Probably not in the hands of facepunch, but definitely something that I feel needs addressing down the line
• Codegen doesn't work on embedded code blocks, which means we cannot use [ClientRpc] in razor panel classes, needing an extra partial cs file, which in turn makes the embedded code block entirely useless for these situations. (
  Fine though, since partial cs files will still work fine with the razor-csharp magic that's at play
• Now the biggest issue: Hotload perf. Razor files compile into C#, which means for hotloading to work, the entire game assembly needs to be rebuilt and hotloaded. I'm sure this isn't a secret to most people, but C# hotloads take some time. Usually just a few seconds on basic games, considerably more on complex games, with a potential problem going on with hotloading perf degrading over the course of multiple hotloads in one editor session.
  While external stylesheets should and probably will remain, this poses a potential problem for html templates being replaced.
  This to me, is the biggest reason I don't particularly like using razor ui yet. It's just slow to use and iterate on. Html and scss files hotload instantly, making quite the difference when the razor alternative needs to compile and hotload 5 seconds for a basic style or layout change.

I've personally added warnings for all three of these points on the appropriate wiki page, since I believe razor should currently be used under caution for active development.
That said, I think even now razor already lends itself excellently for relatively basic, self contained panel classes that can just be dropped into a project and used, no need to fixup relative or absolute filepaths for the attributes in the C# class or the stylesheet reference in the html template, on top of being 3 files instead of 1.

Conclusion

I think html templates should absolutely be kept for the long term and maintained as such, alongside razor. While I don't think the razor problems aren't fixable, I'd like to point out caution regarding "remove now, fix later". I really, truly think the hotload perf on razor files for making ui is abyssmal at the moment, making razor not at all a suitable full replacement for html templates at the time.

One additional thing I need to mention though. Whatever razor does differently with html layouts with the root panel is good. I want that for html templates too. I noticed it's easier, less ambiguous and more logical to "begin" a new panel class with razor, since the <root> tags seem to "just work". Good stuff.

[garrynewman]

Some good points..

IMO I wouldn't rush to use embedded styles in the razor files. I only really included them for quick and dirty hacks to avoid having to set style="" directly. You're missing out on things like @import and $variables, as well as the missing scss highlighting.

If hotload performance is terrible we should really look into that. @Metapyziks might be interested in seeing it - because 5 seconds sounds insane to me, I've never seen performance like that - and improving performance there improves everything, not just editing Razor.

Personally I don't see any compelling reason to keep html templates around.

[Remscar]

Possible argument for keeping HTML templates around.

It would allow for UI's to be worked on outside of S&Box and then brought in when they are ready to be used. There's good tooling out there for developing HTML; I could make my HTML and scss outside of S&Box, then import the template and scss when i'm ready to see it in game or build my C# to populate fields and make it dynamic.

Also non-technical people would have an easier time just working in HTML / CSS, instead of having to setup and work on the UI via Razor files. Yes you could just copy/paste the HTML in the razor file when you're ready, but there's cases where that might not be very convenient.

[matekdev]

As long as the hot reload preformance isn't crap and intellisense preforms fine, probably makes sense to standardize this before you are forced to support multiple ways of creating UI.

EDIT:

Visual studio code analysis and code cleanup do not run.
C# Codegen is not run on .razor embedded code. This means you cannot put [ClientRpc] within a razor file.

this seems pretty annoying

[garrynewman]

Let me start gathering some metrics on compile time to see if we can make that better, it shouldn't be taking more than a couple of seconds.

[DoctorGurke]

idk how much sense this would make, but would a viable compromise be something like an import feature for html files into razor? I really only care about rapid hotloading for ui iteration at this point :(

[garrynewman]

We should really be fixing the cracks instead of papering over them

[matekdev]

After spending some time working with razor, these feel like the big three pain points.

1. The intellisense is in an awful state and only really gives me type information after importing namespaces, nothing else (I'm using vs code)
2. The hot reload times are a lot worse, as mentioned by @DoctorGurke
   3. This "bug" is really annoying Better razor panel init behavior for procedually creating panels #2579, you definitely should be able to set panel elements in the constructor

Otherwise, I'm fine with the general idea of using razor since many other UI frameworks work by allowing you to interleave code with UI creation. Can the intellisense be fixed or is it a Microsoft issue? I'm planning on moving all my code in a partial .cs file which will allow me to gain back intellisense when working on UI stuff.

[A1steaksa]

I would love to see part of Facepunch's development efforts focus on making UI from "scratch", something I personally despise, less necessary.

I think a lot of that would be helped with a SwiftUI stacking approach. Basically you can nest horizontal, vertical, or depth stacks to position UI elements relative to each other. It's definitely do-able in HTML and CSS, and I think if that was a toolset that was already built out and ready to go, creating conventional UI would be a lot easier for me.

I'm not sure to what degree this is something that only I want, or if this is something that would make the "not a web dev" UI experience better for everyone.

It feels, as I've used it, like a natural extension of the pretty nice to use Garry's Mod VGUI docking system that just let you keep docking things if you wanted to stack them

[A1steaksa]

Part of this desire, I think, is that it seems like S&box currently requires you to learn like 5 different languages in order to get anything done at all. I don't necessarily want to be an expert in C# and HTML and Razor and a new, different form of CSS, etc. to make pong.

They're probably great tools for their respective jobs, but I sure would like a very simple version of them also