Is their algorithm so complex that it can't run in a reasonable time using client side javascript? I have trouble thinking of anything that isn't vastly over-engineered and runs slower than the network lag probably is.
Perhaps their algorithm isn't written in javascript?
Or perhaps they want to check the user's password choice against a multilingual dictionary, and they decided to save the user the multi-megabyte download?
No, it's more about leaking information to the JS client. If, for example, their password verification rules stipulate that you can't reuse any of your last N passwords, then they would need to make this check server-side as they don't want to provide that information to the client.
Which sending a POST on every keystroke won't really help with anyway, because they can't tell that you typing "h-u-n" will match your old password of "hunter2", assuming it's properly hashed.
If I were in charge of both requirements and implementation I'd debounce the input by 300-500ms and display a "loading" spinner in the password complexity box until the debounce timer and network request had fully resolved.
I was just trying to explain why, given some business use-cases, doing password validation on the client isn't always possible.
I think an overly complex password strength checker is probably dong it wrongly. Besides, when it comes to password complexity you need to tell the end user what the rules are!
Combining a password strength meter with password rules is the sort of thing where most implementations are going to get it wrong. It clutters up the UI a lot, to the point of being too complicated for "average" users to understand.
I prefer seeing one system or the other, but not both.
If you have rules, don't use a password strength meter. Rules are going to be a binary result - "yes the password is good enough", or "no, this password is not acceptable" - which is represented by showing which rule(s) were not respected by the user, or a green checkmark.
A password strength meter can be used when there are no rules enforced, to let the user decide for themselves whether that red progress bar showing a weak password is good enough for their needs. The meter doesn't need to be binary, with red/orange/yellow/green stages. The only reason I don't like password strength meters in general is that there is no standard across sites/services as to what constitutes a strong password. One site will show "password123" as weak, while another will say it's fairly strong. Each implementation has its own arbitrary algorithm that is likely not representative of "true strength".
Or perhaps they want to check the user's password choice against a multilingual dictionary, and they decided to save the user the multi-megabyte download?