Openui5: Synchronous AJAX should not be used

[rasmk]

UI5 uses synchronous AJAX to load modules.

This effects in a warning in Chrome console:

Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check https://xhr.spec.whatwg.org/.

The things have got much worse in the most recent release of Chrome, which has a bug in caching synchronous AJAX responses (https://code.google.com/p/chromium/issues/detail?id=583214). This caused my UI5 app not to bootstrap anymore.

Tried data-sap-ui-preload="async", but this did not solve the issue. Still the same warning, still the same caching issue.
It seems, currently the only solution is to disable caching, but then the app will have to download several MB of libs at every startup.

Although it's a bug in Chrome, they (Chrome devs) could legally drop support for synchronous AJAX at any time. According to the AJAX spec, section 4.5.1:

Synchronous XMLHttpRequest outside of workers is in the process of being removed from the web platform as it has detrimental effects to the end user's experience. (This is a long process that takes many years.) Developers must not pass false for the async argument when entry settings object's global object is a Window object. User agents are strongly encouraged to warn about such usage in developer tools and may experiment with throwing an InvalidAccessError exception when it occurs.

As such, using synchronous AJAX seems to be a bug in the library implementation. Please switch to async.

[emoticrab]

Interestingly this is also what stops you being able to build FirefoxOS and Chrome Apps using UI5. Also why you have to comment those calls out to get it working in Atom.

[codeworrior]

No, it's not a bug, it's heritage.

When spec owners decide to change the spec in an incompatible way, you can't blame projects that have built something against the old spec.

However, my perception is that both, WhatWG as well as browser vendors, are quite aware of the effort that is necessary to move away from sync XHR to async. That's IMHO why they've chosen this unusual approach of logging a warning in the console when such usage is detected for the first time. Apps that use sync behaviour in only a handful of places can relatively easy switch to async. Others (like DOJO or UI5) have built a full set of synchronous APIs around the sync XHR and moving such frameworks towards async mode involves a lot more activity than just flipping the flag on the XHR.

In JavaScript, you can't transparently move away from sync to async execution, only the other way around. Instead, UI5 has to establish async alternatives step by step for all its sync APIs. New APIs that involve backend communication are only designed for the async mode. At the end we'll allow apps to switch off sync usage of XHRs (obviously, apps also have to use only async APIs then).
For compatibility reasons we might even have to keep the sync way alive as long as browsers support it (Firefox is an exception, they've made sync XHRs useless on their platform years ago, but that's a different story).

Nevertheless, there is still some way to go before we can provide that switch.

Kind Regards, cw

P.S.: According to recent comments in the Chromium issue report, they regard this as a serious issue that'll be fixed soon.

[emoticrab]

Thank you for that detailed response.

[matz3]

Related issue: #777

[codeworrior]

Just an update: Chrome 48.0.2564.103 is available now and according to first tests, it fixes the sync XHR 304 response.

[rasmk]

Thanks for the update @codeworrior. Chrome update seems to solve the issue indeed.

[DerGuteWolf]

The console warning now reads "Invoking 'send()' on a sync XHR during microtask execution is deprecated and will be removed in M53, around September 2016. See https://www.chromestatus.com/features/5647113010544640 for more details." and we have September 2016... What now?

[codeworrior]

First, the Chromium project postponed the removal by one milestone (M54, planned for October 2016), then abandoned it due too much negative feedback. See https://bugs.chromium.org/p/chromium/issues/detail?id=605517#c25 .

[akudev]

To avoid the impression nothing is happening here: getting rid of synchronous XHRs is not an atomic task. Every single usage has other effects on existing applications and public APIs when replaced by async calls. Work on this is in progress, some recent example commits are:

• https://github.com/SAP/openui5/commit/0e271c9db0fbbd8a04b4c5a5a0e6abad8ed11808
• https://github.com/SAP/openui5/commit/621ec150a6ee47905036e6fba6f88e774ee7041b
• https://github.com/SAP/openui5/commit/de0b47b0989508008134dea5a228eb1e6a3565fd

[jonaszuberbuehler]

@akudev Is it still the case that we can't use ServiceWorkers to make an app offline available (I'm using version 1.60.18)? There are still a couple of synchronous requests. Is there any workaround we can use now?

EDIT: I'm using ui5-tooling and serving the dist directory. If I'm using https://sapui5.hana.ondemand.com/1.60.18/resources/sap-ui-core.js directly in index.html, it seems to be all asynchronous calls. Is this intended behaviour?

EDIT 2: Using ui5 build --all will create the bundles for the dependencies which eliminates close to all sync requests! Kudos to @matz3! (original slack thread: https://app.slack.com/client/T0A7MQSJ1/C0A7MHSSJ/thread/C0A7MHSSJ-1583169609.007800)