Why shouldn’t you? I’ve seen many people say you shouldn’t. However, I’ve never known why. In fact, I would think it benefits you because the client cannot read the server script and you don’t need a remote event, so they would not be able to fire it via FireServer, and would have to use VirtualInputManager.
Furthermore, answer me this: Why don’t all games use Server Scripts for UI? All the benefits listed like cheat prevention and no compromises should make it extremely promising to use server scripts.
The only thing I could think of that would not be good is architecture. You’d have to use BindableEvents in ServerStorage instead of RemoteEvents in ReplicatedStorage, but that is a pretty minor change to do. If nobody disputes this idea, I will make a module for this. A client-communication module that can bind UI via server scripts, and a porting tool to help turn remotes into bindable events.
This was moved to Scripting Support from Development Discussion because it became a question.
Protecting your code is the last thing you need to do; UI code is rarely proprietary. The server should not be involved with UI for two major reasons:
The replication boundary.
The user interface is a client-sided thing to begin with. All interactions will be client-sided, including text input. Things like this invoke property changes in the instance that will fail to replicate to the server.
Latency.
Once again, the user interface is a client-sided thing. It is a forward-facing component that can make or break a game’s experience. It is this fact that bonds the UI and UX (user experience) so closely together. If GUIs are scripted from the server, GUI responsiveness can quickly decline
This doesn’t mean the server cannot be involved
LocalScripts should be the only thing interacting with the GUI instances. If you need to relay server data on a GUI, you can request it via a RemoteFunction and the like
Thank you for your response, I can see how lag can be an issue since the UI signals are meant for the client.
I’ve also asked some HiddenDevs people about this, and they also said that it is a good sometimes, but lag will be an issue if you use it for everything.
I am a well-acquainted member of HiddenDevs myself; however, I disagree with members saying that server-sided GUI scripting can be occasionally good.
The only situation where I can see a benefit is when a GUI should relay something that the client cannot detect, and the server must inform the client. In that situation, the server could update the GUI itself. The update would be replicated as opposed to the information. The time difference in the client updating its GUI with information sent by the server Vs. the client applying updates replicated by the server is negligible, so it’s best to let the client continue to handle things as is traditional
While this answer make sense, it has once again confused me that many popular games do not have performance issues yet use this server-side GUI scripting. Fisch uses this system for their Shake button.
Have you guaranteed that button is entirely server-sided? In any case, as Roblox places you into ideal servers for your region, your ping is low enough where the latency is not very noticeable. Regardless, that responsiveness is not guaranteed, and can be improved