I have heard that you should use :WaitForChild() in most cases on client side, since there can be a latency in loading instances. But I’m not sure if I should use it in local scripts inside StarterGui in the context of declaring variables for GUI components.
Could not using the method possibly cause eny errors during the runtime?
I would also like to know if the situation is gonna be any different with gui inside ReplicatedFirst. The documentation states that “contents of ReplicatedFirst replicate to the client before anything else in the game.”, so I assume there would be no need to use :WaitForChild()?
I can’t be sure though, so I would appreciate an expert’s point on this. The use of this method compared to a direct reference may not be much different regarding performance, but I’m trying to learn how to use it in the most appropriate way.
There is absolutely no reason to use “WaitForChild()” in a local script. Not many people know this, but client-side scripts run after the whole game on the client is replicated. So feel free to use “:FindFirstChild()” or directly referencing the instance. More info: https://www.youtube.com/watch?v=7tzy1DuPcBQ
Always use :WaitForChild() inside a localscript, because things get replicated from the server and that takes some small amount of time, but because scripts run blazingly fast, the time it takes for data to go from the server to the client is relatively big. You could be trying to use :FindFirstChild() on an instance that has not “arrived” yet from the server, and that can result in the function returning nil, breaking your system.
The built-in :WaitForChild() function fixes this issue, by yielding until it can find that instance. In this context it means that the function is waiting until the instance “arrives” from the server.
Since GUI’s are always scripted with localscripts, you should always use :WaitForChild().
May as well … One less thing to question. Sometimes If I know the script isn’t needed right away, I’ll put in a task.wait(3) up top or more. Then you can pretty much do as you will.
I say 3 because that is about the time it takes for the program to load and start. I have scripts that wait a lot longer. Have a few landscape generators that have client scripts that wait 20 seconds. Just to cut down on the loading load …
Also FindFirstChild() is great for testing if it’s even there …
if workspace:FindFirstChild("Part")~=nil then
--
end
This will not error if Part is not there… any other way to refer to Part would error if it’s not there.
This is very useful information! Even though it didn’t say anything about StarterGui, I did some testing and found out that the scripts in StarterGui run approximately at the same time as the scripts in StarterCharacterScripts, which means that they run after the game has loaded.
As the documentation says about StarterPlayerScripts, “These scripts can safely get objects from StarterPlayerScripts and ReplicatedStorage without using WaitForChild().” Since StarterGui scripts run after them, it seems to me that they also don’t need to use WaitForChild().
Conclusion: There’s no need to use WaitForChild() to declare GUI components in a local script inside StarterGui.
All of the scripts, except the ones in ReplicatedFirst, run after the game.Loaded event has fired, which means that all the GUI components are guaranteed to exist by the time of the script execution. The only case where a non-ReplicatedFirst script could have problems with direct referencing an instance is with objects in Workspace being not streamed in yet (when StreamingEnabled is set to true).
