It’s bad practice because you would be replicating the UI change to everyone, which ma affect network and doesn’t make sense since UI change should be local to the player, not to everyone even if they can’t see it.
It’s better to replicate a change for one player for an UI change rather fir everyone.
game.Players.PlayerAdded:Connect(function(player)
local PlayerGui = player.PlayerGui
end)
Why would I be replicating the change to everyone, you have control of each player in game.Players and their respective PlayerGui. If I wanted to Replicate the change to everyone I would use a for loop or something.
That’s not what I meant. Changing UI on the server would replicate the effect for everyone except they can’t see it, which doesn’t make sense and is wasteful.
You can easily send a remote to a certain player for an UI change rather than changing UI for one player which everyone will see.
So you are telling me that changing something in
game.Players.player1.PlayerGui
will replicate that “effect” to
game.Players.player2andplayer3.PlayerGui
?
Actually, due to the quirks of PlayerGui replication, modifications on the server replicate to the client. Other clients would not see this chance. As far as I know it’s the only way to replicate SOLEY server → specific client without replicating to other clients.
cc @elonrocket
If you want the real reason you shouldn’t do this, it’s because it will cause input delay for the player if you do events server side. Especially for mobile players, it’s not a good experience to press a button and there be a visible pause before something happens. Also, since changing things on the server isn’t exactly supported by Roblox, you could risk having to change your entire system if it gets depreciated & removed.
Additionally, if you change the player gui on the client, that won’t replicate to the server. That can cause issues where the client had something that doesn’t exist on the server, and can be more of a headache then it’s worth.
As a final note, if you care about code readability, it makes sense to do client displays on the client and server things on the server, and makes coming back to the code you wrote a few months ago much easier.
TL;DR Just because you can, doesn’t mean you should.
Everyone would see the change except that the UI would not be visible to them, if done on the server m.
Thank you for the answer. That makes a lot of sense 
I’m guessing what you’re referring to is StarterGui, which is replicated to each player’s PlayerGui on respawn / character load. PlayerGui is different, feel free to test it out on a baseplate.
Glad I could help. Quick bit of clarification that I forgot to mention that adds to the point of using the client:
So even doing something like when a player buys something, going into their PlayerGui on the server and changing a frame with number_of_bought_things should be avoided?
Though I’d advocate for client-sided UI scripting > server-sided as many others here indicated, it all boils down to preference and how you’d like to manage your UI.
In a technical standpoint, there is bound to be delays in inputs and performance issues when handling UI on server. Additionally, player inputs (such as keys on keyboard) cannot be detected serverside afaik, so you would need to use a remote anyways if you want to integrate player inputs into your UI (which is usually a big reason why people use server-sided UI frameworks). In fact, this is actually more redundant than just handling it client sided as you don’t need remotes to intertwine player input with client-sided UI.
I’d personally opt for client-sided UI simply because UI is not intended to be server-sided considering the server-client model integrated into the Roblox engine. Simply put, server-sided UI scripting is essentially doing what client-sided UI scripting does except that it relies on scopes unnecessarily to, in a way, “emulate” UI scripting that is independent for each player. This is why I think that having the client handle something like this would be more effective as it does what the server would do without the scope.
Additionally, everyone “sees” the change on the server, as server → all clients.
Ideally, use remote events. It’s a couple of extra seconds to set up, but it will save a bunch of time later. Additionally, you could use a framework / library to streamline this process.
One benefit of using only client-sided UI is you can actually move your UI from StarterGui into ReplicatedStorage, and have the client clone it from there into their PlayerGui. This gives you more control, and can significantly reduce server memory usage (if you have multiple players).
I might make a #resources:community-resources / #resources:community-tutorials on how to do this since this seems to be a commonly asked question.
Performance. That’s usually why. Lets say you’ve got a message box, that you set the text of, and tween all the individual parts to open it, and have a button to close it with a tween animation.
You’re going to be replicating that entire GUI every frame, resulting in delays, higher ping & laggy UI. When you can just send one message telling the client to open the UI, and leave everything to the client.
Also, if you’re doing everything on the server, and the player has high ping, that UI will be very laggy.
Plus, server-sided UI isn’t exactly a supported thing, you’ll run into issues that aren’t going to be fixed.
I was talking about changing player gui on the server.
Okay I would definitely read that
What would that look like? currently I am using @tyridge77 's EasyNetwork which makes setting up remotes very easy, along with a module I made that receives all PlayerData updates from the server then fires Script Signal functions from other local scripts with a :ListenToChange Method.
Oh, then I’m sorry but that’s not how PlayerGui replication works. It will only replicate to the specific player, not other players. In fact, only the server and the client that has the PlayerGui can actually see the PlayerGui folder.
Run this demo with two players to see what I mean:
Player Gui Replication Demo.rbxl (23.8 KB)
First Player:
Second Player:
The reason I’m generic about framework / library is it’s literally up to you. I’ve seen hundreds of networking modules / libraries / frameworks popping up, so it’s really up to you to decide what you wish to use. Libraries are meant to make your life easier - so choose one that does, it doesn’t matter what others think as long as it works for you (the only time it matters for others if if you work with others).
cc @SilentsReplacement
Except it won’t - the PlayerGui folder won’t replicate to other players in the first place. I’m not sure what you mean. If the other players don’t see it, and it doesn’t replicate, I’m unsure what your point is.
If you have an example showing this behavior, you should send it to #bug-reports.
Okay thanks again for the help
Will do, since I realised this is a bug where other people can see other people’s player gui implicitly.
I am not a regular, where can I post a bug issue?