Why do we need asynchronous scripting?

As per the MDN guide,

In its most basic form, JavaScript is a synchronous, blocking, single-threaded language, in which only one operation can be in progress at a time. But web browsers define functions and APIs that allow us to register functions that should not be executed synchronously, and should instead be invoked asynchronously when some kind of event occurs (the passage of time, the user's interaction with the mouse, or the arrival of data over the network, for example). This means that you can let your code do several things at the same time without stopping or blocking your main thread.

The main idea of asynchronous functions is returning a result after the function completion so that it could be processed via a callback function independently of the main script execution.

General implementationThe concept is realized in the following styles of scripting:

Getting to know asynchronous JavaScript: Callbacks, Promises and Async/Await

Promises style has been implemented in Standard ECMA-262 6th Edition / June 2015 ECMAScript® 2015 Language Specification:

https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Asynchronous/Promises

https://medium.com/javascript-in-plain-english/truly-understanding-promises-in-javascript-cb31ee4878...

http://es6-features.org/#PromiseUsage

In JQuery promises are introduced as Deferred objects: https://api.jquery.com/deferred.promise/

AngularJS 1.x offers $q constructor: https://docs.angularjs.org/api/ng/service/$q

Async/Await style has been introduced in ECMAScript® 2017 Language Specification (ECMA-262, 8th edition, June 2017):

https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Asynchronous/Async%5Fawait

https://medium.com/@jackiekhuu.work/ecmascript-2017-async-await-my-iron-man-d98e5e3188e5

https://medium.com/javascript-in-plain-english/async-await-javascript-5038668ec6eb

https://medium.com/@%5Fbengarrison/javascript-es8-introducing-async-await-functions-7a471ec7de8a

So, as we can see, in the recent years asynchronous style has been presented widely in JavaScript and its frameworks.

What about ServiceNow?

While we still can use JQuery and AngularJS asynchronous methods on the Client side, there is a couple of methods as well as GlideAjax which allow us to perform asynchronous calls to the server-side: The Async Fight - getReference and GlideRecord.

What about asynchronous scripting directly on the Server side?

Community developers are also excited by this question:

Asynchronous Computing with JavaScript Promises

Path to ES6, ES7? Let's check how async style is introduced in JavaScript based server engines, for example, in the well-known NodeJS:

https://developer.ibm.com/technologies/node-js/articles/promises-in-nodejs-an-alternative-to-callbac...

https://nodejs.dev/modern-asynchronous-javascript-with-async-and-await

https://github.com/then/promise

https://www.promisejs.org/

At the same time, ServiceNow uses Mozilla Rhino engine of version 1.7 R5 which supports only Standard ECMA-262 5.1 Edition / June 2011:

https://docs.servicenow.com/bundle/orlando-application-development/page/script/JavaScript-engine-upg...

It is kind of hard to align Rhino versions and ECMA standards as the features are supported partly: https://mozilla.github.io/rhino/compat/engines.html. As far as it is shown in the table there is no sign of out-of-the-box supporting of asynchronous functions by Rhino.

Still, there could be some workarounds.

For example, using idea from https://www.promisejs.org/implementing/ which includes setTimout() client-side function. At the same time, realization of setTimout functionality in Rhino is suggested here: https://stackoverflow.com/questions/2261705/how-to-run-a-javascript-function-asynchronously-without-.... Also there is some suggestion here: https://gist.github.com/hns/375799 which has one more implementation idea of setTimout.

To sum up

Unfortunately, non-vendor developers in ServiceNow are limited by JS functionality and cannot use Rhino native syntax to test the methods above, but it is a question to the vendor developers if Promises functionality could be added to the backend ServiceNow library. At least, finding a method of custom implementation seems to be a more realistic way for improvement than just waiting for the out-of-the-box Rhino support.

Olga OsipovaServiceNow developer

ICL Services

Labels: