For your first question, this would be dependent upon your application logic and what works best in the circumstance. For example, if you have a logon box on every screen, on a failed logon you may want to return the user to the same page and post a message or alert, since there intention may be to stay on the same page and then you save them navigation. In other cases, you may direct them to a page with just the warning or the members page with a warning saying blocked. I would say from a usability stand point you are probably better off keeping them where they are unless there is a clear separation between the "public" site and the "private" site. Metaphorically, is the logon on a gate or a light switch?
As for your second question in terms of security, it does not matter if it's a full page request or AJAX. The server side logic will still be needed to create the session, cookies, and any other backend settings that change the session to authenticated. If you are saying they could mess with the client-side validation, the response would be not to rely on client side validation. If you are concerned that some type of XSS attack or MiTM attack could prevent this message from being seen, then you would need to address the attack vectors separately.
The server side must be involved to create the session. If you were checking the password on the client side, that would mean you have already provided the password in a variable, cookie, local storage, file, etc. That would be a poor security choice. The session would still have to be setup on the server side. Most of the things you are doing with HTML/JavaScript/AJAX are going to be manipulating the content once its provided by the server.
If the security is just checking some local variable which is the password, anyone could change the logic check code locally and bypass the protection. If you require real security, not just a quick block for basic end-users, then you should be ensuring the password check occurs where you control the code only, the server side.
