Currently, the only way to render graphical interfaces on Roblox is by placing it under the PlayerGui instance that is (usually) automatically created under every Player instance.
This has many downsides with relation to developer ergonomics and performance, namely:
The GUIs get unnecessarily replicated for every player, but only when their character spawns. This makes working with GUIs before a character has spawned hard to pull off.
To have your GUI components dispatched, you must put it inside the StarterGui singleton. This is also the only place where they will render inside studio, which makes its runtime behavior seem unintuitive.
The existence of both the PlayerGui and its intended contents are not determined, because they are cloned based on character spawning. This leads to ugly and very hard-to-debug :WaitForChild chains.
Among many other problems. Because of this, I believe introducing a new, separate singleton will help mitigate these issues and make GUIs a little less of a hassle to manage both internally and programmatically.
The Proposal
Add a new service, named something like Graphics or Interface, which acts similar to a PlayerGui. When a client connects, the contents of this service will be replicated before any local scripts run.
Every GUI component in this container will be rendered, just like they are in PlayerGui. These components will also render in the Studio viewport, just like if they were in StarterGui. Changes on the server will be attempted to be replicated on the client like any other replicated container.
Because you shouldn’t be. Unless you’re maybe trying to control if the client has a gui (and even then there’s better solutions).
Manipulating UI on the server with the expectation it replicates to each client creates ping issues. Its better to send messages down to the client with remote events (or instance changes), and let the client solely handle the UI.
On the main thing, if we have a singleton UI for each player, how do we create UI that is specific to each player, such as the player name?
Yes, I was thinking more about the intuitiveness of that behavior, obviously you should never try to do that. I’ve replaced that with another point.
Scripts would be expected to add and edit things inside this container locally, and that shouldn’t be more awkward to work with because that’s what we essentially do with for GUI currently.
I would want this new singleton to replace StarterGui completely, but if need be, someone could still manually work inside the PlayerGui.
I feel like this entire thing can be replicated by either a remote or something similar that pulls a gui from a place that already exists and then, manually parent’s it to the client’s gui after the character loads. Not sure if I am reading this correctly. It’s a bit confusing to read.
I’m bumping this because working with UI in Roblox is absolutely abhorrent in its current state without this.
Right now, I have a RunContext.Client script that parents the GUI to the LocalPlayer’s PlayerGui when it finally appears. Then I have to make sure nothing resets/destroys the GUI while I’m working with it. So much boilerplate to just properly render a single box or text.
UI should always be static. Needlessly cloning UI components every time the character spawns is unintuitive and should be discouraged. Having a single, static container for UI solves this.