AJAX is the most popular, easiest and still very powerful. There are also many built-in libraries or libraries that contain powerful tools for HTTP calls like jQuery AJAX, axios, fetch and I'm sure there are many more depending on the language you're working with.
There are many ways to do this, but they all differ in their abilities. I'll explain a few and why you may want to choose one over another.
It seems like you've worked with AJAX before, but I'll explain it anyway for curious parties.
The main thing to remember about AJAX is that it sends a call to the server and then receives a response, but it only receives data from the server when a call is sent. Therefore it is unidirectional meaning, data must be requested before it is received.
Server Sent Events
AJAX is useful for certain applications that don't update often so it can be called with a timer or when the user requests an update (if you use social media, you may notice it notifies the user when new data is available). For a small application, this is really powerful, but on a production scale for something as large as a social media platform like Instagram, Facebook or YouTube, that could be very taxing on a web server that serves millions of requests per hour, so if it's on a timer that is called every 30 seconds that means every 30 seconds each active user (potentially millions), would make a request to the server (more like a cluster of servers tied together, but the point still stands). That's not efficient nor is it scalable. There are ways around it with AJAX which I'll get to and were workarounds in the early days of AJAX, but there have since been new technologies made available.
Server Sent Events is a really powerful tool that is somewhat similar to AJAX in that it creates a call and is unidirectional, but it works in the other direction. Essentially, the client makes a call to the server just like AJAX, BUT the difference is that the server responds with an event stream and essentially keeps the connection open. The connection is not closed and so when the server has new data (that you push to the event stream), it will send an event to the client with the data. This is very useful for an application that has a lot of real time data without much input from the user. A good example of this would be a news site that provides information about the weather. Instead of the user refreshing for new information or the client sending multiple requests, the client simply subscribes to the event source and when the data is available, the server sends it to the client.
Server Sent Events are really useful for certain applications, but I can attest (because I've implemented them myself) that they are difficult to implement properly and there are a lot of bad tutorials online. The most popular search results return guides that close and open the connection in between each request in turn defeating the purpose of Server Sent Events.
The problem with AJAX and Server Sent Events being unidirectional is the case of real-time applications. Imagine a chat application where you had to refresh the page or click a button or wait 30 seconds to see if someone replied, it would be annoying and not very user friendly. This is why AJAX is not very useful for real-time applications. There are workarounds for this such as polling, long polling or a combination of Server Sent Events and AJAX, but at last it is 2020 and WebSockets have shown up to the party.
WebSockets are a "newer" technology (introduced around 2010 and added to all browsers some time in the last decade) that allow for a client and a server to have a bi-directional connection by literally "upgrading" the HTTP connection. That means the client can send calls to the server, and the server can send calls to the client. That is very powerful and is why WebSockets are becoming increasingly popular with uses by Discord, agar.io, slither.io and I'm sure many others are out there as well as some that are on the horizon.
As promised, I will mention some workarounds in case you do need "real-time"-ish apps, but are not ready to make a WebSocket server (though it's very easy depending on the server-side language you're using).
Polling is pretty self-explanatory. The idea is that using AJAX, you'd keep making requests to the server until new data is available. Easy to implement, but pretty inefficient especially in a larger scale production environment. Not scalable at all.
Once again, pretty self-explanatory. The idea is that using AJAX, you'd keep making requests to the server until new data is available, BUT on the server side you wouldn't respond until their is new data. There's always a limit though and you can't keep a connection open until there is new data, what if it takes hours for new data to be available. In a dynamic application, you'd never know, that's what makes it dynamic. Still pretty easy to implement with a little extra work from the server, but still inefficient. Also, not scalable at all.
These workarounds were prominent and useful before WebSockets were available. I recommend that if you need to make a real-time application, you study the type of application and where your use case actually applies.
It's important to note that WebSockets aren't a replacement for AJAX. AJAX still has many use cases and is used widely for large scale applications. WebSockets are ONLY useful for real-time applications where you need data to be sent back and forth between the server and client for a period of time. You can and should still use AJAX until something better (if ever) is available. Even if you have a real-time application, a mix of both may be useful depending on the use case.
Understand your application's needs before making a decision.
tl;dr you can use WebSockets, Server Sent Events, Long Polling or Polling, but WebSockets and Server Sent Events are not a replacement of AJAX.