To start with the English definitions again:
When we say that two or more things are synchronous we may just mean that they are happening at the same time, or we may more specifically mean that they are keeping pace with each other.
Asynchronous refers to the lack of whatever quality we're using synchronous to talk about.
Now, there are two important cases in computer science where this distinction comes up that are irrelevant for Javascript, but show how the jargon uses are really just a specialisation of the above rather than (as some jargon is) a new sense.
One case is in communications. With a synchronous communication, we need two devices to keep in step with each other. This may refer to the timing of bits sent along a wire or other medium, all the way up to the higher communication protocols built on top of that.
With an asynchronous communication, we do not need two devices to keep in step, and one can race ahead or fall behind without breaking the communication. Again, this may refer to the low-level transmission of bits, all the way up to higher communication protocols (some like TCP/IP may even allow bits of the message to arrive out of order and be put back into order again later).
While there's generally more work involved in making any given layer work asynchronously, there's generally advantages as it's more reliable (won't break due to timing issues), more flexible (being able to build a system on top of media that operate at variable speeds rather than lock into the lowest speed you can guarantee), and hence it can also even make things easier at the layer above.
As we can see, this relates directly to the normal English-language sense of synchronous where two or more things are keeping pace with each other.
Now, another case is with multithreaded programming (much of what I'll say now also goes for multiprocess systems with communication between them, and some other cases, but I'll just stay with multithreading for the description). When we have a multithreaded program, different parts of it can run simultaneously (or concurrently). Sometimes, it may be necessary to coordinate the work of these threads, for example to collate final results, or to make use of a shared resource that can only tolerate access from one thread at a time.
When we need to synchronise different threads like this, we are using synchronisation. However, the less we can have different threads depend on each other like this, the more efficient things would be overall, because one suffering a delay will not hurt the others.
For that reason, we have a variety of techniques for dealing with I/O, accessing APIs, or delegating work to other machines which are designed to not require this sort of synchronisation between different threads, but will handle the fact that we then can't depend upon the success or failure happening to any given time-frame. Since these simultaneous processes need not be synchronised in the sense of being kept in time with each other, we call each of these techniques asynchronous.
Again, we can look back at the general English definitions and see why they are called what they are called, at least in comparison to each other.
Now, Javascript does not have multiple threads*, and for the uses it is used for that is just as well, it would be far more trouble that it's worth. This means that we don't have to think about the concerns just mentioned, but also means that if we do something that takes a long time (like accessing a stream from the web), the single thread will be stuck waiting and doing nothing else.
So we have another option: We start a network operation, and then leave it to run and our script continues until it is finished. When the network operation concludes, this triggers an event that lets our single thread act on the results.
While there is only one thing happening at a time in the Javascript (though there are two or more operations happening in the browser overall) the technique is a copy of some of the asynchronous techniques used in multithreaded systems to avoid the need for synchronisation between threads.
So there we have an answer that is perhaps too programming-related to suit EL&U and too English-language focused to suit migrating back to Stackoverflow, but an answer all the same.
*Though different scripts can run on different threads in e.g. different server requests for server-side script, or different tabs on a browser for client-side web scripts.
