:WaitForChild() Discussion

In pretty much every Roblox scripting tutorial on YouTube, you will see WaitForChild() being used when referencing instances in the Workspace and other services. Roblox themselves uses WaitForChild() in the Creator Documentation and in their premade games, such as the new Racing template.

Using WaitForChild() is seen as “good practice.” We are told that not using it will result in errors. I recently watched a YouTube video which said otherwise. The person in the video claims that you do not need to use WaitForChild() in most cases. They said that you should only use WaitForChild() when referencing an instance which has been added during run time (moving a model from ServerStorage to Workspace) and a few other scenarios.

But they basically said that LocalScripts will not execute until the game is loaded. This means that by the time a LocalScript which is referencing an object in the workspace runs, the workspace will already be fully loaded.

The creator of the video basically claims that all of the following examples will not error and are completely valid:

local textLabel = script.Parent.ScreenGui.Frame.TextLabel

local part = game.Workspace.Model.Model2.Model3.Part87

local remote = game:GetService("ReplicatedStorage").Folder.RemoteEvent19

So I’m wondering if what this person claims is true. Can you really execute all of the above code without it ever erroring? Even for players who have bad internet? Do you really not need to use WaitForChild() for the above examples?

(Just to be clear, I’m not accusing this YouTuber of being wrong, I’m just questioning whether what they are saying is true.)

If anyone wants to view the video for themselves, here it is: https://www.youtube.com/watch?v=7tzy1DuPcBQ

2 Likes

As someone who uses local scripts quite a bit, there are a lot of cases where I do need to use WaitForChild(), or otherwise, I’d get an error. I will probably watch the video later and see what he says.

3 Likes

I just tested it by placing a LocalScript in StarterGui and then referencing a part from the workspace. I got an error.

3 Likes

What the person from said video claims is more or less true. Yes, it is not necessary to use :WaitForChild() in the examples that you have provided above as modern day computers are able to load a client from the server in such a short amount of time, before a Local Script even runs. I suppose if you are concerned with players that have a low-end computer (or have bad internet as how you stated) you can simply just yield until the game is loaded before continuing.

However, this brings up a question as to when :WaitForChild() should even be used. Generally, :WaitForChild() does not need to be used in most cases, as how you have stated, but it should be used in scenarios where you are uncertain whether an object that is necessary will exist before the instruction is executed.

A prime example being, trying to reference the player’s Character within a Server Script. Server Scripts, as stated in the name, run with the server, using :WaitForChild() within these scripts are seen as bad practice due to the fact that all instances within the server (where Sever Scripts run) are already loaded. An alternative to using :WaitForChild() in these scripts is to use :FindFirstChild(). However, the client is not loaded straight away, unlike the objects within the game world, and therefore, if you are trying to reference them (like the example of the player Character model) before even existing, it will throw out an error. In cases like these, scripters tend to use player.Character or player.CharacterAdded:Wait() to prevent this from occurring.

That being said, using :WaitForChild() is still a bad practice within Server Scripts nonetheless, and therefore, scripters tend to prefer to use client-based events to avoid this, in the Character model example, .CharacterAdded:Connect() would be favoured over yielding until the Character is loaded by using player.Character or player.CharacterAdded:Wait()

1 Like