Currently, in all the games I have made, I use folders and value objects parented to the player so that on the client I can listen to the Changed event on the value objects to, for example, display the player’s cash whenever it changes.
Is there anything inherently wrong with doing this? I don’t mind exploiters being able to see other player’s data, I doubt they can do anything with that information.
There isn’t really anything wrong with using ValueObjects for data replication.
Infact, I’d recommend using ValueObjects for replication in favor of Remotes under certain scenarios (explained below) as it always has:
.Changed and :GetPropertyChangedSignal()
The only scenarios where using ValueObjects wouldn’t be as useful would be if you’re trying to pass a multitude of different arguments (two or more), where you need the client to communicate with the server or when you want to be able to pass the same value to the client after passing it once.
TL;DR you’re fine using ValueObjects for data replication. (just make sure you’re using it when you don’t need the client communicating to the server and you’re ideally just passing a single value for replication, or in other words when you really don’t need remotes)
I don’t think that’s accurate.
Whilst there is a cap on Remote requests, using Value Objects has no “inherent” faster replication - the data is still sent server → client - using RemoteEvent:OnClientEvent - this has no additional client requests and essentially is identical.
You actually incur the risk, if you do this too frequently, of incurring a memory penalty by creating a bunch of RBXScriptSignals where you could do the same with one event that sends the user’s update data in a table.
@Twinbrotato If you’re only using it for values like Cash, there isn’t anything wrong with it at all - although you’ll have to be careful about users seeing data more sensitive than cash if you do choose that. I’d actually reccomend this library (ReplicatedValue.lua) by evaera to achieve this with a higher level of developer abstraction 
I agree with @unix_system.
I think a lot of this will come down to your own preference. However, I find it easier to use remotes since I’m usually representing data in more complex manners (e.g. tables/classes of data), and thus it just becomes easier to move the data around via remotes. For simple games with mostly primitive data, value objects work just fine.
Just make sure that the value objects are not the primary source of truth for the data. In other words, use the objects to replicate the data, not to necessarily store it.
Why might it be a bad practice to make the value objects the primary source of truth, just out of curiosity? Some of my projects make use of Roblox’s built-in leaderstats system and feature saving, but if that makes them especially vulnerable I would like to know.
Among more technical issues that I wouldn’t be the best person to explain, you run the risk of object deletion (goodbye data) as well as keeping track of modifications can get hairy if you have multiple scripts writing and saving data to the same value. It’s just not great practice to do - unlike variables, there isn’t a guarantee the data is there.
In my opinion (for anyone looking back at this) it’s just bad design. We use ValueObjects/Remotes as a more way of transferring data rather than as truth. If you were to use a value object for storing data - does anything happen to it? No - of course not.
BUT It’s best to avoid this as it’s bad design. Why is it bad design? Because once you start mixing your communcation with your variables we start to have some overlap which can cause issues. Not sure if you’ve ever heard of MVC, well it’s a framework./architecture built in the mid 1970s specifically to stop these issues.
And also works well with ValueObjects 