Don't worry, the terminology will get easy soon enough.
In an asynchronous request, the request / response is completely separate from how the main browser logic is working. So you can continue doing other work in the browser while waiting to get the response back (including clicking the button multiple times).
In a synchronous request, everything must happen in the order you specified, and it is only when one event has completed that the system is considered synchronized and can move on to the next task. Hence the comment that the browser can appear completely unresponsive while waiting for a response to come back.
Again, the note you mentioned is correct: generally speaking, anytime you force the user into a situation where they have no clue what is going on, and a system that appears to be dead, you risk them simply closing that system. This is a really bad user experience and should be avoided.
Normally I would recommend against using Ajax in a login screen - when you get the response back from the server (stating that the login was successful), you are presumably going to redirect to another screen. So you are effectively making the user wait for twice the length of time needed for roundtrip communications with the server.
However on the assumption that this is desirable for some reason, then I would approach it completely differently.
I would have the "def" function disable the login button until a response has been received. And I would have it always return false.
I would then have the "handleServerResponse" function check for whether the response was "y", and if it was, perform the form submission / redirection / whatever else is needed. If the response was not "y" then it would show the error message and re-enable the login button.
Just my thoughts.