Hi 
I have a problem that I need to ask you: “which one should I use for Client-Server communication, RemoteEvent or RemoteFunction?”
3 Likes
Well it depends. Basically RemoteFunction is client → server → client / server → client → server, but RemoteEvent is only server → client / client → server. So if the script calling the remote needs an immediate response then you should use RemoteFunctions. Otherwise use RemoteEvents.
6 Likes
Summary
Almost never use remote functions! Go remote event or modules. Remote functions are only for nerds 
. Erm yeah
Reason:
Return is the remote function’s point. I don’t see a point it unless it’s something very advanced cause modules can do return too.
Edit: In fact! REMOTE FUNCTIONS ARE FOR UNCS 
Prob ragebait, but Remote Functions are great for requesting asyncronious data or requests from the server.
And the client cant acces required server modules so you are wrong there too.
4 Likes
Modules bruh. Have you heard of that? Go ReplicatedStorage for client to server. Server only, go serverscriptservice or workspace
I am FURIOUS with ANGER! Your ragebait has DEEPLY affected my EMOTIONS!
1 Like
The client cant acces required server modules and vice versa
1 Like
I honestly use remote functions 10% of the time because 90% of the time all you need to do is send something to the server/client and not send back.
But for that 10%, whenever you do need to send back you should use a remote function.
You could technically replicate the behaviour of a remote function with a remote event, for example you fire to the server and then you fire back to the client that fired to the server.
But this would be worse performance wise, as you’d need to set up more rbx script connections taking up more memory and in some cases you may need to create a new remote event instance.
Also remote functions would be 10x better for scalability.
Besides, Remote events’ purpose is to provide one-way communcation only. It’s like using pcalls for everything just because you can avoid errors instead of properly handling it.
2 Likes
Using RemoteFunctions to request data from the server would be strictly synchronous, not asynchronous.
It is generally advised to avoid using RemoteFunctions unless it is especially important that the returned value is used in the context from which it was requested.
In most cases, it is far better to have the client fire a RemoteEvent, and then have the server send a response by also firing a RemoteEvent.
RemoteFunction is usually used once upon player join to retrieve player settings and data
For rest RemoteEvent is a way to go
That simply not the case
Callback is superior to abstracted events
You can handle threads and not cope “maybe value will be returned in 10 seconds”
Allowing you to yield UI and display data only when it is retrived and avoiding confusion.
Provide an actual argument instead of vague “its generally adviced”.
More over if you capture upvalue unless you yield it will be forced to use REF instead of VAL aka compiler will be paranoid
Invoking a RemoteFunction will yield the thread it is done in, forcing that thread to stay alive until a response is received. There is also additional concerns when the invoked function errors, or if the player disconnects while the function is in the midst of running.
There are usecases for RemoteFunctions, but they are few and far between.
Even in the example you give, UI updates, it is far better to use RemoteEvents. RemoteEvents allow you to take an asynchronous approach, there is no reason to force a thread to simply wait for the server to respond with the appropriate information, when the client can just as easily spawn a new thread when it receives the data (using RemoteEvents).
The only scenario you should use a RemoteFunction, is if you absolutely need the response to be handled in the same scope the request was sent from.
1 Like
Incorrect, its called yield/suspended state, making thread effectively just a number that scheduler skips
This is intentional. Waiting for a response is cheaper than rebuilding control flow with events for no reason.
That just not understanding how VM operates
That would require live pointer for thread captures rather than a static VAL capture
That’s a thread, not a scope. Those are not interchangeable concepts.
Holy ragebait?
Yielding the thread for an indefinite amount of time will keep being bad until it is resumed. Spawning a new thread on response from the server is fixed-cost. It’s a matter of scale.
That would require live pointer for thread captures rather than a static VAL capture
This is just untrue. And also kind of besides the point. The primary concern for newer developers should not be micro-optimizations that aren’t even measurable, but rather how they can write well-architecture code that is easy to work with.
Ideally UI updates should be handled by the server firing an UnrealiableRemoteEvent.
That’s a thread , not a scope . Those are not interchangeable concepts.
I am well aware of the difference between a thread and the scope. I was referring to the scope.
Structuring your game around cope is a bad design because I said so.
Cope more comrade 
Yeah, it’s a cargo cultism right here.
See, that’s the whole point: YOU ARE WRONG 
Micro-optimizations matter, newbie advice doesn’t. Accept reality or stay slow.
The advice you have given is directly counter-productive. You have your own right to obsess over micro-optimization, however when a new developer asks for advice, it is not just unhelpful, but also conceited to give advice like you have done.
Please grow up.
1 Like
Sorry, I don’t accept cope - it’s counter counter-productive as you say
Either you improve… or cope more.
Logic > Feelings
Statistic > Cope
Using hazing “grow up” is peak desperation, my dude. Lowest effort argument possible.
You false-flagging my previous post just proves it, by the way.
If you are not teaching beginners how things work, then at least teach them how to do things in an optimized way.
At least it’s easier to comprehend than drowning them in OOP just for them to find out that they had wasted time on nothing that slowed them down & brought boulders to carry just to be abandoned.
Saying that micro-optimization is bad for new developers is BS and hypocritical; saying that drowning them in OOP and other slop would be more correct since optimization is actually super simple & internals are much simpler than comprehending OOP in a language it was never meant to be.
And don’t you say that “I did not speak about OOP” You know exactly what I group into OOP in the context of Luau: negligence & refusal to accept mistakes, aka cargo cultism, as other programming communities like to call it.
Teaching them OOP in Luau is like handing a kid a chainsaw to carve a butter sculpture. Meanwhile, they could have learned to slice bread efficiently.
This is true for invoking the client (which you really shouldn’t do) but not for invokeserver I think but feel free to correct.
https://create.roblox.com/docs/reference/engine/classes/RemoteFunction#InvokeClient
In my current project (deterministic tick based large scale simulation):
Sever → Client driving client side statemachine - use TickRemoteEvent:Fire(player, payload).
Client → Server for remote input -
avoided using RemoteEvent listening on server side, since listening on server exposes server for exploits, needs debounce, but still every debounce cause work on server that I cant allow.
So input channel is implemented using RemoteFunction:InvokeClient wrapped in dedicated thread for each player.
This way I can control input rate on server side.
Model looks like Server Pull (InvokeClient) → Client Async provide input.
After invoke is received on client input window gets opened, buffered input is passed or thread on client side is yielded until input is ready. Thing is that input payload might only be passed to server once for particular request, upon return from invoke thread.
This is one specialized example where RemoteFunction:InvokeClient have benefits. Lets to keep server in control over client input pace.
Direct RemoteFunction:InvokeServer on other hand exposes server workflow to be exploited.
Summary:
You better of by having expertise on both RemoteEvent and RemoteFunction before choosing best fit for particular situation.
1 Like