This seems… kinda cool? I guess? I can see a couple different use cases, but they can all be done with the legacy behavior.
Once this is out of beta, will legacy continue to let scripts operate the way they do now, or will all scripts need to be migrated to this new system?
However, it has also been said that in places where no replication is made, the script (obviously) won’t execute. While there isn’t a script replication for the server this confuses me because it’s kinda inconsistent with client behavior. I also missed this question’s answer:
which answers the question now. I was asking for the definition of anywhere by the way.
Pretty nice update! There are some issues, but I’m sure they will be fixed.
Also I swear I remember there being a plugin setting too before this got into public beta, what happened to that?
If all the use cases can be done with the legacy, this brings nothing new as we currently have and always used legacy.
The only “new” thing is that you can place scripts wherever and cause an organisational mess.
Now we can finally manage our code structure the way we want. This is a much needed update! Thank you!
For any teams approaching development with a single-script architecture this probably won’t have a significant use case because your architecture runs off of little to one script per environment (sans engine-injected scripts) and you do the rest in ModuleScripts which can already be required anywhere.
I can see a use case for casual projects and non-power teams that don’t need or care for a deeply architectured codebase but are still capable of maintaining good practices with it or for resources that try to cover as many installation options as possible.
Seems like this is supposed to be the replacement for what was ReplicatedScriptService but instead this removes hierarchical dependence and leaves execution context on an instance-level.
So does this mean that Normal scripts with the RunContext of client mean that exploiters can’t access it?
More news!
More bugs!
Waiting to see when Roblox puts as much energy into fixing bugs as it does into creating new ones.
Glad to see this, I often made mistakes with script placement only to spend 5 minutes trying to figure out what went wrong.
Will this mean that some locations like ServerScriptService and PlayerScripts could get replaced with a more “universal” location in the future, to reduce potential clutter? (e.g SSS being merged into ServerStorage to form a uniform “ServerAssets” location or similar?)
I don’t get why so many people are being negative about this update. If you don’t like it… Keep the RunContext to Legacy? No one’s forcing you to use the new feature, maybe it’s not useful to you but it may be to someone else.
What will hapend if we have a script which run under Client context in a BasePart with Streaming enabled ?
Will it run every time the part is replicated ?
Okay, I see how this is useful but maybe you should deprecate localscript in “Insert Object” menu so that people will get used to instead spawn a server script and change its runcontext property
This update is AMAZING! I have been looking forward to it since the property was added to the API, and here it is!
Quite the opposite actually. We will now be able to run scripts anywhere, regardless of location, which will reduce clutter and make writing scripts easier in certain cases
For example StreamingEnabled: if your client code depends on a part in workspace, instead of using CollectionService and a localscript, you can put the script in a part and set RunContext to Client.
Depends on how you use it for example you can make it organized or a mess.
Then how will it work with exploiters , because we know exploiters can enter local scripts, how does it work in this system?
2 words
revolutionary.
this is insane, thank you so much for feeding into my quirky and nerdiness roblox developers! 
Very happy about this, the organization in my game has gotten a little gross because of the local script placement restrictions. Now I can have all of the client code run out of replicated storage. <3
I can see why ReplicatedScriptService was canceled. This change is huge for me as someone who creates free models that add local scripts while being self-contained. The loading code I had in the Innovation Inc Railgun, Nexus Admin, and Nexus VR Character Model is something I will be happy to finally remove.
Does this mean that we can just make contact with client and server scripts easier without sorting each on a different place?
Like…Local scripts work as usual, but you can just run it as you run a server script(anywhere)