HTTP is a request reply communication. This is inherently limited to only one of the parties (the client) to initiate the exchange of messages. Furthermore as it is defined at the upper layers of the OSI stack it has more overhead, then protocols on lower layers.
One alternative a protocol on the transport layer, like TCP, SCTP or UDP. TCP opens a communication channel and until this channel is open messages can be exchanged and messages are guaranteed to arrive. UDP does not offer this guarantee, but in a small network messages should not get lost. SCTP is a newer portocoll and it is meant for streaming applications, so it could fit your application well.
Another option to consider is MQTT or similar streaming protocols (similar is RabbitMQ, zeroMQ). MQTT uses a message broker and instead of request-reply it uses publish-subscribe pattern. It is at a higher layer then TCP, UDP or SCTP (This usually means that it is more convenient to use but has more overhead). The robot can publish its measured coordinates and the joystick can publish its reference position. The robot subscribes to the joystick reference positions and a user interface can subscribe to both reference and measured coordinates in order to display them.
All above solutions are supported by libraries for all popular programing languages and cross platform use is also possible.
If you prefer a browser based interaction HTTP would be the easiest to implement. For native apps all above is similarly complex and plenty tutorials can be found.
Please not that none of the above methods will reach a cycle time suitable for using them inside a closed control loop, MQTT, SCTP, TCP or UDP will all be ok for supplying reference values for control loops. I would expect HTTP to be a bit slower the the others.