Client-side code should not use synchronous AJAX ; Really ?

[Fred Jean]

Hello,

It is a well known, and I believe accepted, good practice to avoid synchronous AJAX in client script.  This is for reasons such as UI responsiveness and perf bottleneck. And having such synchronous AJAX will trigger Healthscan findings.

While reviewing such Healthscan findings where a catalog client script was using a synchronous call, I discussed the topic with the script developer to know if there was any reason to do so.

The reason I was given was to avoid the user from submitting the form before we get the Ajax answer to update other form fields.  (yes, the user would have to be very quick or the network very slow, but it can happen).  So here we want to avoid submission of incomplete or inconsistant data.

So then I thought, doesn't this actually also apply to like 90% of the client scripts using AJAX calls ? Don't we mostly use AJAX to update other fields ? Isn't it an issue most of the time if a form is submitted before the script and AJAX does its job ? So, isn't it actually a good thing to have synchronous calls and get the form blocked (yes I know there are other ways to achieve this) ?

What do you think ?

[M Iftikhar]

@Fred Jean 
Synchronous AJAX may feel safer, but it hurts performance, freezes the UI, and is flagged by HealthScan.
Best practice is to always use asynchronous calls (GlideAjax, getReference with callback) and control submission with onSubmit. Leverage g_scratchpad to preload values and avoid unnecessary calls.
If timing is a concern, use onSubmit to prevent submission and show an info message like “Please wait.. loading required data” until the async call finishes.

https://www.servicenow.com/community/queensland-snug/client-script-best-practices/ba-p/2273951 

Thanks & Regards,
Muhammad Iftikhar

If my response helped, please mark it as the accepted solution so others can benefit as well.

[Fred Jean]

I know all that, but having he UI freeze is actually what was wanted here.

Of course we could have alternatives by adding controls on the onSubmit script, but that makes things more complex and could actually require also AJAX calls on that onSubmit (and here it would necessarily be synchronous).

[M Iftikhar]

@Fred Jean,

synchronous AJAX does exist for a reason, and I see your point that in some scenarios you really can’t proceed at all without the data. As the spec itself says, while async is best most of the time, sync calls are there for those rare cases where user interaction must be paused until the server responds. Your logic makes sense in that context.

Thanks & Regards,
Muhammad Iftikhar

If my response helped, please mark it as the accepted solution so others can benefit as well.

[Fred Jean]

You say "in some scenarios", but my point that it might actually "in most scenarios"". I mean when would we actually be happy that a form gets submitted before having the other fields be set by the AJAX call ? So async might not actually be best "most of the time".