What reasons are there to avoid doing this asynchronously?

(Please note that I’m opposed to requiring user agent javascript to access something claiming to be a website, but let’s assume we’re talking about something behaving like a single-page application post-authentication anyway.)

I'll give my perspective as a web dev, it can be tricky to time the requests and decide when to query the API asynchronously.

Consider a user starts typing an email address, when do you send out the first async request to find out what authentication flow is required?

On each onChange event, first time the email is valid, would have issues that your email is [email protected], but [email protected] is already valid, so you're probably going to debounce the call by a few hundred ms.

What if the user makes typos, or if they are typing in the email very slowly, and so on.

You might say it doesn't matter, just don't show any UI feedback until its valid, or keep refreshing the current status, but the problem is your control flow is decided by the email that's typed in. You want to redirect certain users to an SSO page, others to type in their passwords, and so on. [email protected] might need a different authentication flow than [email protected], which are both valid addresses.

Another choice is the onBlur event, but this becomes clunky. Think about when it's triggered and how you would incorporate this into a nice UX, I don't think it's possible.

The inversion of control, giving the user time to fill the form in, and press an explicit "Ready, I've typed my correct email in, what's next?" button, makes the flow easy to code.

I hope this helps.

This is so true it hurts. It honestly sounds like a pretty great idea, so I can see why product would be behind it. "We won't have a login experience like other providers, it would be a total $BRAND_EXPERIENCE_HERE" Then you start getting into the weeds and it's really just not possible to do well.