I’d say it depends on the kind of information you want to send back and forth.

Neither Websockets nor AJAX are complex in their basic usage. The main difference between the two is that a websocket connection is a persistent client<->server connection, where (therefore) both sides can at any time initiate a new request to the other, whereas AJAX involves setting up (and afterwards closing again) a new connection that works client->server. This means that with AJAX, only the client can initiate contact.

If therefore your application works with data that the server creates/receives and should then send to the client quickly, then websockets are definitely better. The AJAX alternative to handle this would be short-polling or long-polling, which are basically ‘hacks’ that allow you to ‘fake’ bidirectional communication because your client will keep on asking the server the ‘do you have something new yet?’ question until the server responds with something new.

Both because AJAX involves setting up/tearing down a connection each time, as well as requiring techniques like longpolling to handle bidirectional traffic, AJAX is (significantly!) slower than using websockets.

Still, depending on what your application does exactly, having a delay of a few seconds before a new message arrives because long-polling is used might not be noticeable.

However, Phoenix (and its JS clientside websockets-wrapper) abstracts the difficulties of how websockets internally work, so I definitely would advise using them for your application.

Websockets. AJAX requires setting up and tearing down the connections on every request. Long polling can mitigate latency in ‘receiving’ a bit, but websocket is the only way to minimize latency all the time in both directions.

Phoenix Channels (it’s implementation of websockets) are so simple to use, ask if you have any questions.

SImplicity of use is simplicity of documentation too.

And for note, AJAX is just normal http requests using the normal http ways including all the expensive setup and all, but it can be done in a single line of javascript where channels take a couple of easy lines. If you know how to build normal web requests, you already know AJAX then, except you return JSON instead of HTML. ^.^

This.

If it is for real-time communication where latency is important then websockets blow AJAX away. And I’ve seen a few API’s use websockets via tokens without issue, usually not worth it in most languages to set up unless the real-time need is necessary, though with Elixir it is so easy to websocket there is no reason not to anyway.

If they are rare polling requests then external API’s will not. However external API’s mandate whatever they mandate, that has nothing to do what-so-ever with using websockets for their own front-end.

OhgodNo, jsonapi needs to die, if you are going to vote for that then go for GraphQL then. Speaking of, you can use GraphQL over websockets too.

Exactly what @Qqwy said! ^.^

And what @Eiji said!

I don’t know enough about HTTP/2 to comment, but I don’t agree on the simplicity of WebSockets.

Ok so on simple level they can accomplish the same thing, I send a request across the socket and get a response on the same socket. On that level there is no difference.

Now, requests have a very particular send -> receive flow. I send a request I get a response back or I don’t for whatever reason. If a delete succeeds, then maybe I get a 204 response. Let’s do that on a WebSocket, I send a message over the WebSocket and then wait to receive a response. I have to keep track of the fact I made that request so I can inform the user of a success or failure. That is automatic with a regular request.

What if my deletes are expensive, so to provide a good user experience I provide a loading circle and let the user keep browsing and inform them when I’m done. Then they delete 2 more things. With web requests every request will have a response and I will have a promise or something to inform me of what action is succeeding or failing. With WebSockets, I have to keep track of those actions in the messages, then do the work of parsing and managing the messages then invoking a callback manually.

Now, those things are trivial for experienced developers. I knew exactly what I had to do, and knew how to route errors and such back correctly. A junior developer who doesn’t really understand how “AJAX” requests work would not.

There are like 5 other things that Phoenix provides around WebSockets that I can think of off the top of my head that aren’t easy. So I think calling it a thin wrapper is a little misleading, but that’s also a subjective assessment.

If you’re learning I would recommend AJAX. There should be a lot more tutorials/resources on APIs using that than websockets.

What do you mean when you say standalone and locally by the way? Is this not going through the internet?

i’d still recommend AJAX. probably no external API you are going to use will be a websocket one.

but it sounds a little strange to me. how vuejs on your website communicates to your phoenix application doesn’t really have anything to do with “modules accessing the net”, so i’m a bit confused. are you not going to run the phoenix application on some server? the phoenix app and the web browser will be on the same host always?