Abandon hope of removing sync XHR from the web platform? about xhr

[Nashorn]

Framework designers and architects of API's and DSL languages and tools rely on synchronous XHR requests. Do not remove this feature. Developers are whining like baby-crys because of a little bad experience they had, none.

Here's the truth from a 20+ year engineering veteran. Elite engineers and computer science professionals know how to use thread blocking features like this at the right time, in the right place, (hey isn't that pragmatic?) coupled with intelligent framework hooks and tools for post removal or disabling of these blocking calls.

We leverage xhr sync to load import statements just-in-time in the browser in under 50lines compared to using an over-engineered babel or post build tools. For production buillds, the build tool stitches any import calls so live run-time code never relies on XHR, it will be all baked by then. We're talking framework design here. Not your mom's cup cake shop that you work on in the weekends (to the kid fresh out of college with a BA in computer science) So its a great feature for real-time debugging and quick development (minus the builds on every change).

TRUTH OF THE DECADE:
You see, ECMAScript was infiltrated by lobbyist groups who don't know dynamically typed language concepts at all, probably never heard of the SELF language(Sun Microsystems) or used Smalltalk, just a bunch of young soy boys with wishes about how they want the lang to operate. The committee sold out to massive corporations of employees that instead of making javascript even more dynamic and real-time, is now pushing for strongly typed, strictness and anything the noob developers see as a problem, they lobby for removal. Developers are just that. Engineers build stacks. Developers are complaining about technology like sync xhr that they have no idea when and where to use. Developers only have a faint memory of some bad experience they had when xhr momentarily seized up their browser during an exit beacon api call. NOT our faults you're browsing some xxx website and/or torrent, ad-spamming trash sites.

Even Mozilla, Chrome.....sold out. The Rhino animal was the mascot given to JavaScript, it came from the Rhino book (https://www.amazon.com/JavaScript-Definitive-Guide-Activate-Guides/dp/0596805527). The creature itself is tough, resilient, silent and deadly, armored, is the unicorn, surviving ages, is rugged and built to last.

But at the rate ECMAscript is changing to a soy-boy language.....i think it's being hunted by poachers for it's ivory, the beauty of the language.

[bedney]

So I'll chime in here with the standard response that I always tend to leave whenever I see articles and issues on the Net having to do with removing some already standardized feature based on 'metrics' or 'instrumentation' and watching pages fly by on the public Internet. Google has done this for a while and now Microsoft has taken up the practice as well.

At first blush, this sounds like a great idea. The problem is that almost everyone involved is looking at the public Web (probably because they work at companies that only do public Web work). The problem is that there are literally millions of web pages behind corporate/organizational firewalls that no search engine will ever see - ever. I work very closely with developers of internal corporate web applications whose app will never see the light of day outside of their org.

These developers use features that the W3C or the originator of the technology told them were standardized long ago. The effort to rework these applications to accommodate removal of these features are staggering in terms of both time and money. Sync XHR is one of those features.

My opinion, which I've expressed elsewhere, is that the Web needs to a purely additive platform, at least in terms of technologies that have been standardized by either the W3C, WHAT.org or (in a few cases before these organizations existing or had the force behind them) an ad-hoc standard.

Putting a deprecation warning might make folks here feel better, but it isn't really going to change the reality of all of those Web apps that no one can ever 'see' that contain code written long ago by developers that have long since left the project that will break when changes like this are implemented.

[I-Maps]

I have been developing WebGIS mapping applications for 20 years. Over the last ten years, I have developed a technique that requires javascript code to be loaded with synchronous XHR in the head of the document before the maps are initialized in the body onload event. Synchronous XHR is the only method I have found that works for this technique. I have developed mapping applications using this technique for numerous clients that serve thousands of people per day. Over all these years, no one has ever complained that my interactive mapping applications that use the synchronous XHR technique have locked up their browsers.

Several of my projects have been long-term development projects that have required large investments of my own time and money. I am wondering if the people who are complaining about synchronous XHR have ever run their own companies and invested something like a year of work and $100K of their own money in a project that relies on synchronous XHR. If they did, they might not be so enthusiastic about eliminating it.

The people who want to kill synchronous XHR seem to ignore others who say they have legitimate and necessary uses for it and have large time and money investments in projects that rely on it.

The only complaint I see here is that some programmers use synchronous XHR incorrectly or use it where it is not required and that incorrect use can cause problems with a client's browser. I have never encountered this issue with any site. I have never heard anyone say anything about it except for the people complaining here, so it is apparently not a significant or widespread problem.

If you want to put out a warning message that says "Synchronous XMLHttpRequests may have detrimental effects on the end user's experience, please be sure you are using it correctly", that would be OK, but to use the deprecation message to try to kill it's use appears to be a misguided effort that would be detrimental to web programming technology and businesses that have large investments in projects that rely on synchronous XHR .

I hope that other legitimate users will also encourage the abandonment of this effort.

[mreshadi]

If sync XHR is taken away, what alternative mechanism are you proposing to achieve same effect. We have a javascript-streaming optimization which breaks the js into smaller pieces and loads the missing ones on demand. It has been very effective in reducing the size of js and removing unused parts (http://www.instartlogic.com/products/performance/streaming/javascript-streaming). This optimizations needs to pause the js execution until network response is received and as of now, only sync XHR can achieve this.

Browser is constantly touted as a platform that can replace even OS. In a platform scenario, there will all kinds of people offering different tools / value.
Removal of sync XHR because it slows the page, assumes that the web community only consists of browser gurus and naive web developers who can shoot themselves in the foot!!

If the page is slow, google search ranking will anyways punish the page, why do you want to dumb down the browser for the rest of us?! How does this helps browser to become a true platform, and not a nanny framework for less capable programmers?!

[JamesDunne]

There are several valid and useful patterns that require the use of synchronous XHR for which there is no alternative available. This proposal of deprecating synchronous XHR and the inclusion of a warning in developer console is an unnecessary scare tactic. Yes, I understand the warning is aimed at developers who don't know better with the presumably good intention to incite action aimed at improving the "general" user experience once a page is loaded, but to smack the hands of the capable and take away a powerful tool for which there is no alternative is not an acceptable solution.

[glittle]

To me, this is very strange. When I click on a link to go to another page, the browser UI become unresponsive as it goes to get that page.

I have a few cases in my code that I need the browser to wait while it talks to the server using XHR. The user has just clicked a button, and is expecting a short wait.

If I can't do that call synchronously, I'll have to build an artificial approach to freeze the UI until the response is received!

I can live with a "warning" in the developer terminal, but to remove this feature from the spec is going to hurt a lot!

Timeouts can be used to ensure the UI isn't locked for too long!

[marcoscaceres]

@glittle thanks for the additional details. Best of luck with the refactor! Your users, and local Browser Vendor, will thank you for it :)

In the slim chance you are using ES6, there are ways of keeping your code looking like it's sync, but actually running async (with generators and promises).

[caitp]

Software developers generally don't like warnings in their terminals (or dev consoles). If they know why they shouldn't use it, they're less likely to ignore it. If warnings show up, their users are slightly more Likely to report issues with their product.

There are good reasons to remove this use pattern from the platform, so folks should not give up on the idea.

[hallvors]

Probably discussed to death, but if the browser can just keep its UI responsive does it really matter if a script author sometimes makes his/her page freeze by a sync call to an unreliable or slow server?

[domenic]

I think it would be good to leave it. For every 1 developer who gets outraged and believes that their use case is truly unsolvable without janking the user experience, and comes to complan here, there may be 10 or 100 more who see the message and improve their user's experience, and alongside it the health of the web ecosystem.

[BourgeoisBear]

The opinion voiced by the WHATWG members here seems to be: "If only we can educate these fools who are still using async: false, then usage will drop low enough to where we can remove it!"

No one uses async: false by accident. It is not the default. No one stumbles into it. No one wants to use async: false. Developers use async: false because they have been painted into a corner where it becomes the lesser of two evils. My particular corner involved a 3rd party library that I would rather not fork. Others' corners seem to involve 3rd party libraries that they cannot fork.

The usage is not low because you are spreading the gospel. The usage is low because, like a lifeboat or a spare tire, you only need async: false on a rare occasion.

There would be far less griping over this if one of the proponents took the time to write-up why async: false is so evil. Not just slow! unresponsive! [Duh], but an actual, technical, non-insulting article on why this feature is better dead than alive.

[BourgeoisBear]

With enough time and effort, yeah, I can program around this, but I have many customers with many different systems. If one day they all upgrade their browsers, and sync XHR stops working, that's not a good day! Lots of billable hours? Yes. Billable hours that I want? No.

I'm having a hard time understanding the value-system that gives priority to a cosmetic concern (which can be self-remedied) over not-breaking existing code.

Look at how many terminal-based applications that we use as developers. As a platform, the terminal lacks a great many things, yet it is stable, which lets the developer focus on the problem instead of the platform. When you have a platform that makes changes lightly (windows, gnome, android, iOS, etc.), instead of being able to double-down on the quality and functionality of your program, you end up in a perpetual struggle to keep it functioning correctly across all of the different versions of the platform. It's stagnation. It's IE all over again.

[annevk]

@hallvors yes, because the user experience of such an application sucks. Sites need to be motivated to use good practices so they don't become abandonware.

@foolip apart from the desire to remove, anyone using this also should really reconsider. Is the warning really that harmful?

[BourgeoisBear]

People use javascript for things other than public-facing websites.
Breaking "user space" (so to speak) is a big deal. If there is some
security issue at stake here, I would understand, but no one has raised one
in this discussion. If the reason for removing it is "I think you should
have used async there buddy!", that is a crap reason to break user space.

On Thu, Mar 17, 2016 at 3:36 PM, Domenic Denicola [email protected]
wrote:

I think @foolip https://github.com/foolip is more pessimistic than
most, but there are still many who would like to remove it from the
platform---like we did with showModalDialog, despite similar people
claiming that it was crucial to their site. Especially given Chrome's
recent focus on interventions, I can imagine such a push to take place for
sync XHR in the near-ish future.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#20 (comment)

[timoreith]

I am looking for an alternative for sync XHR requests for our SCORM platform. The following code is an example as found in thousands of existing and in use SCORM e-learning modules.

This (simplified) code is called by the content, follows the SCORM API, and can not be changed(!):

Example 1:

var initResult = api.Initialize();
if (initResult) {
	// start SCORM communication
} else {
	// something went wrong 
}

Example 2:

var maxCount = api.getValue('interaction.count');
api.setValue('interaction.' + maxCount + '.foo', 'bar');

Example 3:

var isPassed = api.getValue('passing_score');
if (isPassed > 0.8) {
	// do something...
}

I think you got it ... ;-D

The (SCORM-)api methods "Initialize", "getValue" and "setValue" are implemented by our LMS application and use sync XHR to ensure data integrity.

As mentioned:

the code is part of third party content and can not be changed to use promises, workers or the like.

I would be pleased about suggestions, because currently I see no alternative for sync XHR in this case of SCORM API communication.

[foolip]

@annevk this is the console warning in Blink with by far the highest usage, around 2%:
https://www.chromestatus.com/metrics/feature/timeline/popularity/581

There's trade-off here, between training web developers to ignore console warnings because they happen too often and for things that aren't actually going to break, and nudging people away from sync XHR even if it will never be removed. 1% would be better than 2%, after all.

What the spec says on the topic (quoted above) goes too far, I think. I don't think sync XHR is "in the process of being removed from the web platform" and no browser will be able to throw InvalidAccessError any time soon. If it were made a bit more tentative like "sync XHR on the main thread is bad for the user experience, browsers please show console warnings and developers please stop using it, if usage is eventually low enough maybe we'll remove it" that would be better.

[agilehands]

Feeling relieved to know that sync XHR is going to stay!

@marcoscaceres Sync XHR is important in advertising platform, perhaps it falls in <2% cases. Here goes a practical example. Please note, I tried to make the example "readable" by changing the actual codes as it might be too specific to the domain knowledge.

--- begin example --
Current problem: Supporting 3rd party tag based demand in MoPub SDK w/o Sync XHR.

Here is how mopub javascripts/html page looks like if XYZ ad network wants to add their tag:

<script>
// XYZ script here. It adds a script tag dynamically
// in the document with the ad request url expecting a JSOONP response 
// OR makes an Async XHR request.
XYZ.loadAd();

// mopub assumes, that if loadAd fails to deliver an ad,
// it should call MoPub.fail() here. so the next script won't be loaded
// or will have no effect.

// BUT, the script tag, even w/o async mode, 
// will be executed after the next script tag is evaluated. 
// I.e. following script tag will be executed either before or in parallel. 
// there is NO way to stop the JS engine to render the next script tag 
// w/o sync XHR, as far as I know.
</script>


// The following script tag is added by MoPub SDK before loading the full html page
// into the browser.
// So we don't know what is in there beforehand. We can only inspected what they added.
<script>
// It is last block, so MoPub assumes that if reached here then
// an ad is delivered.
MoPub.AdReceivedSuccess().

// if  XYZ.loadAd() fails to deliver an ad and but if
// the above call is made before that, then MoPub 
// will count a false impression. That is really bad for business.
</script>

--- end example ---

Hope that gives you at least one use case of Sync XHR. However, If MoPub had a better/another way e.g callback/delegate etc, Sync XHR wouldn't be needed.

But till then, in such many cases where we cannot change a big player - such 3rd party integration needs Sync XHR.

[BourgeoisBear]

The spec should definitely remove this bogus deprecation message. I have wasted so much time reading through all of these issues for something which is probably never going away.

Worse still, when anyone brings up the fact that sometimes (albeit rarely) sync is appropriate, @annevk gives a curt knee-jerk dismissal instead of offering solid proof of why sync is never neccessary, and an explanation of why it is so dangerous that it is worth breaking working code over.

[domenic]

One thing we've talked about in Chrome is measuring how many uses of sync XHR are in third-party iframes (often ads) vs. top-level pages; if the majority is in third-party iframes then we may be able to disable it more aggressively. @ricea and @tyoshino were planning to look into that sometime, I believe.

[emahuni]

I was going through this whole discussion to point where i thought adding my 2 cents worth is right. I think this message about deprecation and the actual deprecation should just be removed. Browsers should be coded not to freeze over this simple issue. I have never seen browser source code before to know what's going on in there, but I think this should be solved in the browser js engine not in the scripts being run. I was thinking why not multi-thread the browser? There are situations that cannot be solved with async/promises etc at all. consider this;

An app loads its scripts through webpack and some through async calls as required during runtime. The app wants to load a settings script from the server and those settings are to be used by various areas of code almost immediately after the settings request has been done. The catch is that this settings file cannot and shouldn't be bundled up into the webpack bundle file since these are settings that can be changed by other clients during runtime, then when the app reloads next time it has to use those new settings. Most of this code is modular and cannot be put in a single resolve function of promises as js would have just moved on deeper into the code. However, letting the code continue further without waiting for the settings will break it as there is no way of telling when the settings will arrive from the server. The only way is to wait for the response and then continue or throw an error after a timeout (because this file has to be there and exactly when needed)... hence sync XHR.

This is a scenario I have faced and was actually looking for another solution offered by anything else outside of sync XHR. I tried refactoring the code several times using promises and most other methods and they never worked as effectively and simple as sync XHR requests. Throughout the code there is use of promises, async ... await, generators etc, but they don't work for this one scenario in the codebase. By trying to use these other methods has proven wasteful of valuable time and effort on unnecessary complicated and unsatisfactory trials, meanwhile knowingly ignoring the only solution that works perfectly without the detrimental effects being reported in the console.

So I am wondering why this would be removed at all. The page works fine without any detrimental effects as in the doomsday warning message being thrown in the console.

To my point of view, if this problem is inherent of javascript, then the language is poorly designed, and removing this simply makes it worse. Async await is actually a way of trying to mitigate this, howbeit, it encapsulates the code in a function again, which is the same as promises. I think the people who threw this in were actually trying to solve this, but i don't know how or where they lost it. They ended up doing the same this over. I don't think there is anything you can do with async await that you can't do with regular promises... But there is one thing you can't do with promises that you can do with sync XHR and that's wait for a response from the server before you continue with execution.

[shakyjake]

Well I can only speak from personal experience - I'm currently using sync XHR with FormData for a drag & drop file upload system. Async causes issues with script timeouts on the server when uploading multiple large files so I need to keep it synchronous. Web Workers seemed like the ideal solution for this but the poor support for FormData means I can't use it yet.

[shakyjake]

No, it's just that using async in this situation causes multiple uploads to start at (roughly) the same time, slowing the time required for each file to finish. Error events all happen (and ar received) as expected.

The spec is fine:)

[foolip]

@reshadi, this is a bug about accepting that we cannot remove sync XHR, and having the spec reflect that.

[TheJaredWilcurt]

Can we get some examples put in place for better practices designed to be as easy and simple to understand as possible, so those baby programmers this warning is meant for can actually update their code accordingly. Meanwhile put a harder to understand message for senior developers to understand that this is a false warning and XHR Sync, like Disco, will never die.

[hallvors]

Isn't this issue handled by promises and other work on making JS itself more "asyncish"? In other words, I would consider an implementation somewhat obnoxious if it warned me against doing something like

new Promise(function(resolve, reject){
    var foo = new XMLHttpRequest();
    foo.open('GET', 'bar.txt', false);
    foo.onload = function(){resolve(foo.responseText)}
    foo.onerror = function(){reject(foo}
    foo.send();
}).then( /* do the work that required waiting for the response */ );

FWIW, I think I'd vote for allowing synchronous APIs in the web platform and solving the problem with browsers being so single-threaded by focusing on that problem.

[sideshowbarker]

I think it would be good to leave it.

I do also.

For every 1 developer who gets outraged and believes that their use case is truly unsolvable without janking the user experience, and comes to complain here, there may be 10 or 100 more who see the message and improve their user's experience, and alongside it the health of the web ecosystem.

Yes. Speaking from my perspective in development of messages for the HTML checker, and seeing the results, I know messages about deprecated-but-still-supported misfeatures can make a difference during the time while browsers have to continue to support them and we continue to be stuck with them until more developers learn how bad they are for users and quit using them.

So in the interim, such messages have the potential to eventually reduce the usage to the point where we can actually remove the misfeature.

In this case I realize the odds might seem long right now, and the usage may end up remaining high enough forever that we never actually get there—but if we just give up on doing things like continuing to raise developer awareness of the problem by emitting console messages, we’ll never know if we might have been able to reduce usage below the threshold.

[ricea]

What I mean is you can do:

<script src="/applicationContext/getApplicationContext"></script>
<script type="text/javascript"  crossorigin="anonymous" src="/js/dist/applicationCore.js.gz"></script>
<script type="text/javascript"  crossorigin="anonymous" src="/v7/v7Core.min.js.gz"></script>
<script type="text/javascript"  crossorigin="anonymous" src="bundle.js.gz"></script>

This requires that getApplicationContext return valid Javascript that sets context itself, but if you control the server this just means prefixing the existing JSON with something like window.context = . The other Javascript files are guaranteed to be executed after it is loaded.

[thw0rted]

I guess this explains why I've never had a good experience with a SCORM platform, then. The API designers did a bad job, and they should feel bad.

Now, you say it "cannot be changed", but one of the beautiful, terrible things about Javascript is that if you dig deep enough, everything is global (eventually), and you can monkey-patch it. I'm not saying that's the right solution for your case, but I'd say there's an argument to be made. If nothing else, your front-end could talk asynchronously to a Web Worker that calls the (awful) synchronous API in the background. Anything is better than a wait-loop in the UI thread.

[foolip]

At this level of usage, it doesn't seem likely that console warning will be able to drive down usage enough so that sync XHR can be removed. If console warnings is the only tool in our tool box, I think giving up hope is appropriate.

[marcoscaceres]

@glittle, can you explain how you "need" to pause the browser? Maybe show us some code? It can't be that 98% of other developers don't have this issue, but you do. Can you explain what is so critical in the interaction with the server that the user is forced to not use the browser or the page?

[mreshadi]

@foolip thanks for clarification. I think I miss read it. I'm glad this decision is made! :)

[JamesDunne]

@hallvors Promises are orthogonal to the issue here. The foo.send() line in your code above produces blocking behavior, i.e. JavaScript execution will pause at that line until the request is completed, making the rest of the Promise wrapper rather pointless in terms of asynchrony.

[agilehands]

There is no blank, you got it right. As you said: "only report them as successfully downloaded and rendered when they really are", this should be the ideal solution. But as long as MoPub keeps adding the last script segment "automatically" and doesn't provide a mechanism to callback on success, Sync XHR is the only way.

Few notes:

1. There is no such thing like MoPub.AdReceivedSuccess() or MoPub object. I used these for clarity instead of their javascript codes and url redirections.
2. At present I can "swizzle" some mopub methods found by inspecting and make it work w/o Sync XHR. But its not reliable as mopub can change their implementation anytime.

[BourgeoisBear]

Chrome debug window it is!

I strongly lean towards not having a message (unless sync actually is being
slated for removal). If sync is staying, the message should probably go.
There are so many ways an unskilled dev can shoot himself in the foot. If
the plan is to make a message for each one of those ways, the debug console
is eventually going to be so choked up with noise that people will just
disregard it.

If the message has to stay, changing the verbiage from "deprecation" to
"try to use async" would be a great improvement.

On Thu, Mar 17, 2016 at 3:17 PM, Philip Jägenstedt <[email protected]

wrote:

@BourgeoisBear https://github.com/BourgeoisBear, was it the deprecation
message in Blink (Chrome) that led you here? Not that it matters much, but
the one in Blink is what prompted me to file this issue to begin with, and
I'm wondering if it would be best to remove or leave it, all things
considered.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#20 (comment)

[domenic]

I think @foolip is more pessimistic than most, but there are still many who would like to remove it from the platform---like we did with showModalDialog, despite similar people claiming that it was crucial to their site. Especially given Chrome's recent focus on interventions, I can imagine such a push to take place for sync XHR in the near-ish future.

[foolip]

What kind of date handling is done of the server that there are no good APIs for in the browser? I guess it's not simply adding/subtracting a timezone offset, so something to do with human readable strings like "America/Pacific", maybe?

If you know up front the offset between performance.now() and the server-side time in UTC, then I doubt you'd need to sync it more than say once a week/month or so. How much does performance.now() drift, in practice?

As for just lowering the timeout, in order to ensure that scripted animations are not janky, the timeout would have to be before the next animation frame callback, so never more than 16ms. Even on the fastest of networks, that's not going to be reliable.

[littlebee]

I have heard the arguments, some religious, and up until a few months ago, I would have agreed that there really isn't a need for async: false. But then in the process of removing the last entanglement requiring server rendering of the base DOM and layout by PHP for the app I work on, I happened upon a very real use case.

During my app's initialization it uses an XMLHttpRequest with async:false to pause all scripts from loading while it fetches application options and current user context information. This information was previously bootstrapped into the page by the php layout and much of the UI code uses information in the context data in static initializers or other ways that assume it is available at time of script load.

I've tried reworking the code to make the api call to get the context information async and then dynamically generate script tags to load the remaining scripts that depend on this data being set. The result was much slower page load times stemming mostly from the browser not caching the scripts loaded via dynamically generated script tags. :(

I sure hope that it's just an idle threat to remove async:false.

BTW, I also think it's just a little pretentious to assume that you understand my user's experience needs better than I do. Just a little.

[Jemt]

We are working on a product that has JS code dating back 15 years. Not being able to dynamically load these snippets of code and inject it when needed, while holding back DOM processing, would pretty much cost us 300 hours of refactoring. While this is not impossible, I really don't see the value in removing support for sync execution. How is it different from <p>test</p><script src=".."></script><p>more content</p> behaviorally? I'm aware that the browser would be able to optimize by downloading the JS code asynchronously before executing it synchronously alongside the DOM, but the order of execution is the import part here which is what we use sync XMLHttpRequests for.
I'm fine with Developer Tools throwing one warning about the use of Synchronous XMLHttpRequests, but it should not be marked as Deprecated.
Seriously, we are developers, not kids in need of course correction. We can't just rewrite every poorly designed (but functional) snippet of JavaScript out there.

Also, at least give us a time frame - when will it be acceptable for browsers to remove the functionality?

[thw0rted]

I am a web developer, and a web user.

As a web developer -- particularly one who has worked in a big corporate environment, on legacy code, that requires a huge effort to migrate away from bad design decisions made a decade or more ago -- I can absolutely appreciate the value in making the web a "purely additive platform" (per @bedney). Any time we drop an existing feature, we break legacy code, and a lot of that legacy code lives in unseen systems that don't have a proper support tail. Any such decision should be made only after careful consideration.

But. I am also a web user, and as a user, I love to see developers forced to stop using shoddy design patterns that make my experience worse. As a user, I don't care if they're saddled with some architecture decisions somebody made 20 years ago, or a 3rd-party library that their business relationships force them to integrate. Burn it to the ground and do it right. If you honestly believe the browser APIs you have available to you don't allow you to design your application without blocking the UI thread for a network call, get on the WHATWG boards (hello!) and lobby for what you need.

I don't expect sync to go away any time in the next 5-10 years, but I agree with the principle of doing everything we can to discourage it -- yes, even for your use case, that you think is "legit". It may well have been, back when you started your project, but you could do it all asynchronously now. I'm not saying to rewrite everything from scratch today, but you will have to eventually, if not for this breaking change, then for the next one. The web is alive, and any product you make that doesn't have a maintenance plan, that isn't kept up to date with living standards, will become unusable -- not tomorrow, maybe not next year, but eventually it will.

So: I like #178, the idea of site-specific opt-out. I'd like to take it a step further, and encourage browser manufacturers to put sync support behind a config flag, exposed to (power) users. Of course it would default to permissive mode, but maybe in 5+ years I could realistically turn it off. That's how the web gets better -- we deprecate the bad features. Sync XHR was one of them.

[ricea]

@anubi Use async / await makes this really easy and natural to do asynchronously with fetch(). It may also protect you from overflowing your stack.

But, as you say, I can think of no scenario in which recursive ajax wouldn't be a terrible idea.

@Nashorn wow, well said.

I have used xhr sync extensively in non-production, framework, code, and it has been incredibly useful. I think usage numbers are often equated to usefulness; this is a mistake in that some features--such as xhr sync--are more likely to be used in "not your mom's cup cake shop" code that never goes to production, so of course usage numbers would be low.

If xhr sync were to be removed, an option would need to be retained in the browser to enable it. Maybe make harder to do, but do not remove it.

As an aside, I dislike the mob/totalitarian mentality that has taken over web technology, i.e., "if we (your average unimaginative and inexperienced web dev groupie) think x should not be done, we will not be content till x cannot be done"...as @Nashorn said, their concern is about the ivory.

[foolip]

Some discussion (by me) at https://code.google.com/p/chromium/issues/detail?id=392311#c17

[glittle]

In this case, the call for data is sent down a number of levels, and an answer is expected. If the server call is async, there won't be an answer returned. I can see that that sounds like a bad approach in an async world. I guess I'll have to bite the bullet and redesign each of the levels of code to use async calls, and keep the user entertained while they wait!

[annevk]

Given the discussion in https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/thread.html#msg232 I guess we can consider alternative wording. I think the wording was based on showModelDialog()...

[shakyjake]

I don't think we'll see a drop off until support for FormData in Web Workers improves (currently only Chrome and Opera support it). Until then there's no real alternative for developers.

[foolip]

That's a connection I was not aware of, which uses of sync XHR can be replaced by FormData in Web Workers?

[foolip]

I'm not sure I understand, does the server timeout not result in an error event in the async case like it should? Is this to work around an implementation bug, or is there something actually broken in the specs here?

[foolip]

Oh, so I suppose it's a matter of bookkeeping, using sync XHR saves you the trouble of keeping track of pending uploads and starting them when one is finished?

[foolip]

@JamesDunne, this is a bug about accepting that we cannot remove sync XHR, and having the spec reflect that.

[hallvors]

(I admit that I have not tested that code to see if browsers implement sync-xhr-in-promise the way I'd expect them to do it ;). Perhaps we should add a test or five in due course?)

[hallvors]

Bugger. Well, thanks for clearing that up. Too bad.

[tyoshino]

Updates about Chromium metrics (with metric names as the box sometimes does not get set):

• https://www.chromestatus.com/metrics/feature/timeline/popularity/465 XMLHttpRequestSynchronous has gone down to ~1.57%
• https://www.chromestatus.com/metrics/feature/timeline/popularity/472 SyncXHRWithCredentials has gone down to ~0.04% in last December and staying around there.
• https://www.chromestatus.com/metrics/feature/timeline/popularity/581 XMLHttpRequestSynchronousInNonWorkerOutsideBeforeUnload has gone down to ~1.3%

[foolip]

It sounds like the problem is that if MoPub.AdReceivedSuccess() is reached it's simply assumed that the previous ad was loaded successfully. Even with all the sync XHR in the world, why would that necessarily be true?

The example is a bit too abstract to give advise about, but in principle it seems straightforward to load ads without sync XHR and only report them as successfully downloaded and rendered when they really are. Can you fill in the blanks for me?

[foolip]

OK, sounds like the hypothetical MoPub needs to make some changes and that sync XHR is a workaround. Maybe you can tell the real MoPub that you're getting console warnings because of them and ask them pretty please to change their model :)

[agilehands]

exactly, thats a very good suggestion (y)!

[foolip]

@BourgeoisBear, was it the deprecation message in Blink (Chrome) that led you here? Not that it matters much, but the one in Blink is what prompted me to file this issue to begin with, and I'm wondering if it would be best to remove or leave it, all things considered.

[foolip]

It is true that I'm pessimistic about any "wait and see" approach to this, but together with a more active plan to get rid of this, the deprecation message could still make sense. What's still missing is someone to formulate and execute such a plan.

[foolip]

@BourgeoisBear, there isn't a shared WHATWG stance on this, I'm involved in the WHATWG and filed this issue precisely because I doubt that usage can drop by enough, at least unless there are additional efforts to understand and drive down usage.

It's interesting that you mention 3rd party libraries, which seems to have been the problem in #20 (comment) as well. What do the details here look like? Are those 3rd party libraries using document.write, so that some init data for them is fetched using sync XHR?

[BourgeoisBear]

In my particular case, I’m using a 3rd-party date-time-timezone widget. On init, I can supply it with a “get current time” callback that is supposed to return the current date/time/timezone (for when the “Now” button inside the widget is pressed). The widget takes care of updating the DOM to reflect the new date/time (calendar, sliders, dropdowns, etc).

Here’s what pushed me towards async: false:

• Have to get “now” time from server since I can’t trust the user’s system time to be correct.
• Have to handle timezone stuff server-side since JS Date object timezone handling is very poor.
• Could re-init control every time the user presses the “Now” button, but that would make it necessary to save the full state of the control (size, position, etc) and restore it on re-init (which is doable, but much more trouble than setting async to false, and introduces flicker, and may duplicate-create certain DOM elements that have to be cleaned up).
• Could alter the 3rd-party widget’s code to pass a continuation to the “get current time” callback so that the remaining work can be postponed until after the async time request has finished, but then I have diverged from upstream.
• Could make a synchronous call to the server to get the current time/date for a given timezone inside the “get current time” callback, and return a date without having to change 3rd-party code. No stalls, no unresponsiveness, completely indistinguishable from async from the user’s perspective.

From a little web research, it seems as though async: false is used a lot for file-upload scenarios and browser-based desktop-style applications.

https://bugs.jquery.com/ticket/11013
https://core.trac.wordpress.org/ticket/33349

I’m a little fuzzy on the rationale for getting rid of this feature (aside from it blocking the main thread and not being the most desirable practice). Can anyone point me to a deeper discussion on why this has to go?

[foolip]

OK, so there's a "get current time" callback that the widget calls every time the user clicks a "Now" button, and inside that callback you do sync XHR? Or do you do sync XHR before the widget becomes visible and use a cached value + interpolation?

Have you looked into delivering the server's time in <html data-server-time="2016-03-21T10:25:25Z"> or similar? And if it's a long-lived page and time drift is a problem, maybe sync with async XHR once in a while?

Whatever is the case, while the sync XHR request is in flight, it won't be possible to interact with anything else on the page, right? That's the problem, it doesn't go any deeper AFAIK.

[BourgeoisBear]

@foolip:

The sync XHR call is inside the "get current time" callback that I provide to the widget.

The page is long-lived. The time polling idea is close. Minor drawback is that the server will have to constantly source multiple polls--instead of sourcing singles on an as-needed basis. Major drawback is that the "now" call takes the user-selected time zone as an input (like America/Pacific), and the server returns "now" in that time zone. If I polled in UTC and cached it, I would have to do time zone conversion client-side. JS native date/time facilities are anemic, so I'd have to pull in another dependency (moment.js or the like). Or, I could pull "now" in all time zones and cache them all. Still far less elegant than setting async to false.

If the sole problem we're trying to solve here is excessive blocking in the rendering thread, why does it have to be something as drastic as full removal? Putting a tighter ceiling on the timeout would have the same effect, wouldn't break as much code, and would give the developer an opportunity handle the timeout gracefully. It couldn't possibly be as bad as just silently ignoring the async flag so that things which were originally developed to run synchronously mysteriously stop doing so.

[BourgeoisBear]

It uses human readable time zones since there is more to time zones than offsets (different time zones can temporarily share offsets, like for daylight savings time, then the offsets will diverge). Moment.js does these, but pulling in a new dependency (the quality of which I cannot vouch for) is not as nice as changing a flag.

As for the performance.now() thing, it is certainly doable, but then we’re adding state to a process which was previously stateless.

[foolip]

The kind of jank I'm talking about is any script that's using requestAnimationFrame to drive an animation, as that animation would stop while the sync XHR is in progress. Maybe your page doesn't have any animation like that, but the browser can't assume that in the general case. And even if there are no animations, you won't be able to select text, follow links or otherwise interact with the page.

Demo: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4020

If it's too fast to see the problem, just emulate a slower network or XHR html.spec.whatwg.org instead.

It sounds like you know how to avoid using sync XHR here, but that it's more work. It's not a case where you're truly stuck with sync XHR because of a 3rd party library, as is undoubtedly the case sometimes.

[foolip]

It's not merely a cosmetic concern, if the user is on a bad network the whole tab can freeze for a long time.

Everyone I know who works on the web platform takes compat and interop very seriously, but they're not the only concerns and don't always trump all others. I don't know how sync XHR will work out, it can't be removed right now at least. I kind of doubt the deprecation is going to help drive down usage much, which was the point of this issue to begin with.

[BourgeoisBear]

Thanks for hearing me out Philip.

[I-Maps]

If you use XHR with jQuery.getScript to load a JavaScript file there can be timing issues when the page loads. The simple solution that works is to set async to false. Why ruin such a simple solution? Why do away with this method and have people worry about finding alternatives when the working method already exists?

[saschanaz]

but together with a more active plan to get rid of this, the deprecation message could still make sense

If we want really be aggressive probably browsers can forcefully block n seconds whenever sync XHR occurs and irritate users so that devs will actively remove it. Not sure browsers may do it. 🤔

This way the sync XHR won't break but the user experience will break, which is similar with the Flash deprecation thing.

[BourgeoisBear]

What are the obstacles to having stronger versioning facilities? By versioning, I mean having a way to specify a compatibility level that implies an agreed upon set of API features. If we developers had some way to specify compatibility requirements, the browser could either swap JS engines, or at least give a meaningful error to the user that the code they are trying to run is outdated.

It would also reduce the need for Rube Goldberg feature detection schemes like this one: http://stackoverflow.com/questions/29046635/javascript-es6-cross-browser-detection

[ricea]

We have an action item to add metrics to Chrome with the aim of splitting Sync XHR by use case and then knocking out one use case at a time.

We also discussed some ideas for identifying where Sync XHR is used via a framework such as older versions of jqeury. Anecdotally it appears this inflates usage stats quite a bit.

Something that bothers me is that we can certainly drive down usage by 9X% but we only get the technical payoff if we get usage down to 0.

[reshadi]

As many have already mentioned, there are rare, but legit use cases for sync xhr that have no alternative solutions as of now. In an ideal world, everything, including browser api, will be async. But until then, and during transition, there should be possibly dangerous or unsafe solutions for real world cases.

I have been involved in optimizing other people's applications for a long time. In many cases, even if the app developers want to follow best practices themselves, they cannot easily influence the behavior third party libraries they need. Which makes transition to better api very hard.

What I have noticed in most cases is this: although the JS itself is single threaded, it still sometimes need to synchronize with external events. In a web app, we run into a lot of non-deterministic elements such as state of the browser cache, network behavior, user behavior ...; which make optimizations hard.

In general, we can have aggressive solutions that rely on common case scenarios, but have a fall back mechanism for correctness. In these cases, we need a mechanism to pause the execution of the JS "without unwinding the whole call stack" and un-pause when some event happens. This is equivalent to the necessary evil "wait-on" mechanism in other languages or platforms. To discourage casual usage, we can make it hard to use, e.g. require explicit api for taking a snapshot of call stack, and then explicitly restoring it at the beginning of the event handler.

As of now, sync XHR is the only available mechanism for simulating this behavior. Unfortunately, the "wail-on" feature of sync XHR is mixed up with network activity. I think if these two were separated, a lot of current legit use cases for sync xhr would go away, or can be re-implemented with some effort.

[BourgeoisBear]

@I-Maps, it seems like most of the push for this is coming from Google & Mozilla due to the impact that abuse of sync XHR has on requestAnimationFrame(), which probably has substantial dollars-and-cents consequences for their businesses. Since they can't fix sloppy coding on the 3rd-party pages that host the ads, killing the pain-point in the API is probably their best bet.

I suspect most of the web application developers complaining here are largely being talked-past because we at least have control over our own code, and most of us aren't supporting browser development in any meaningful way, so why should they care?

[nicolashenry]

@I-Maps

a technique that requires javascript code to be loaded with synchronous XHR in the head of the document before the maps are initialized in the body onload event

I am curious, why don't you just initialize your maps in the xhr load callback (and wait that the document is ready) instead ?

You could do something like :

var loadPromise = new Promise(function(resolve) {
	window.addEventListener('load', resolve, true);
});


var req = new XMLHttpRequest();

req.onreadystatechange = function(event) {
	if (this.readyState === XMLHttpRequest.DONE) {
		if (this.status === 200) {
			var mydata = this.responseText;
			loadPromise.then(function() {
				initialize(mydata);
			});
		} else {
			console.log("Error: %d (%s)", this.status, this.statusText);
		}
	}
};

req.open('GET', 'http://myapi.com', true);
req.send(null);

[I-Maps]

I tried goofing around with the Promise technique before without success. I am passing ASP data through the web page to the ASP - JS page that needs to be there, but I suppose I could pass the data through the URL in the XHR call. It is a lot easier to use one line to call the code synchronously in the head of the page and then pass the ASP data in the onload event. <script language="JavaScript">$.ajax({type:"GET",url:"code.asp",dataType:"script",as ync:false})</script> Using ajax to load the ASP-JS page may seem unnecessary, but I have my reasons for it. People are saying the browser will hang if the requested resource is not there. In this case, the web page and the js page are coming from the same place. If the server was down, the web page wouldn't load in the first place. This has worked for 10 years with no problem. As they say - "If it's not broke, don't fix it". So, unless the folks who are trying to change this succeed, I will leave it as is.

[nicolashenry]

@I-Maps

<script
language="JavaScript">$.ajax({type:"GET",url:"code.asp",dataType:"script",as
ync:false})</script>

Why not doing this instead ? : (I don't know how to get a timestamp with ASP)

<script src="code.asp?_=<%= timestamp() %>"></script>

From what I understand, it should do the same thing.

[I-Maps]

I don't know about that either. I've never seen anything like that. There is a timing issue with the code and the related objects on the page also, so it's complicated Anyway, thanks for the suggestion.

…

---------------------------------------- From: "Nicolas HENRY" <[email protected]> Sent: Monday, May 29, 2017 4:42 PM To: "whatwg/xhr" <[email protected]> Cc: "I-Maps" <[email protected]>, "Mention" <[email protected]> Subject: Re: [whatwg/xhr] Abandon hope of removing sync XHR from the web platform? (#20) @I-Maps <script language="JavaScript">$.ajax({type:"GET",url:"code.asp",dataType:"script",as ync:false})</script> Why not doing this instead ? : (I don't know how to get a timestamp with ASP) <script src="code.asp?_=<%= timestamp() %>"></script> From what I understand, it should do the same thing. - You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[ricea]

I just spent a couple of days debugging a problem in a major piece of enterprise software caused by use of sync XHR. Let me assure you, it does cause problems for real-world applications. Expensive problems. Chrome has a long history of hacks aimed at mitigating the problems. Even if you think you know what you're doing, you're actually relying on hacks that make it mostly work mostly well enough most of the time.

[ricea]

@littlebee Would it be possible to format the options and context as Javascript, so that you can use a <script> tag to prevent other script from being executed before it has loaded?

[littlebee]

Not sure I'm following you, @ricea. I think maybe the approach you are suggesting is what I did to attempt to make it asynchronous. Keep in mind that there is no server rendered DOM, the initial DOM is delivered from a static index.html file.

The speedy thing about the synchronous solution is you have this in your static index.html:

    <script type="text/javascript"  crossorigin="anonymous" src="/js/dist/applicationCore.js.gz"></script>
    <script type="text/javascript"  crossorigin="anonymous" src="/v7/v7Core.min.js.gz"></script>
    <script type="text/javascript"  crossorigin="anonymous" src="bundle.js.gz"></script>

the browser immediately starts to simultaneously load all 3 js bundles and during eval of the first, applicationCore.js.gz, stops the eval of the remaining scripts by making a single synchronous ajax call to a super fast redis backed api that does the usual session cookie lookup of the user info and provides the same system config data that is bootstrapped into the older pages. There isn't a browser that this doesn't work well on and none have an issue caching all three bundles.

The only way I came up with for making the call asynchronously, without a 1-2 month refactoring effort was to instead do this:

    <script type="text/javascript"  crossorigin="anonymous" src="/js/lib/zukeeper-auth.js"
      data-dependent-scripts="/js/dist/applicationCore.js.gz,/v7/v7Core.min.js,bundle.js"
      data-dependent-scripts-debug="/js/dist/applicationCore.js.gz,/v7/v7Core.js,bundle.js"
    ></script>

First download the auth code that was removed from applicationCore, and then have it inject script tags in the head after it loads:

module.exports = class ZukeeperAuth 
  
  # see README.md in root for doc and options.  returns the context data
  # returned by the /applicationContext api if user has valid session
  @getContext: (options={}) ->
    console.log("zuKeeperAuth: getContext(#{JSON.stringify(arguments)[1...-1]})") if options.verbose
    options.dependentScripts ?= []
    options.dependentScriptsDebug ?= []
    options.verbose = false
    
    httpRequest = new XMLHttpRequest();

    if (!httpRequest) 
      throw new Error('zuKeeperAuth: Cannot create an XMLHTTP instance')

    httpRequest.onreadystatechange = () => @_onReadyStateChange(httpRequest, options);
    url = '/applicationContext/getApplicationContext'

    # this is for the static examples and tests. zombie.js can't handle non http(s)?
    if document.location.origin == "file://"
      url = 'https://events.zulily.com' + url
      
    console.log('calling api ', url) if options.verbose
    httpRequest.open('GET', url);
    httpRequest.send();    
  
  
  @_onReadyStateChange: (httpRequest, options={}) ->
    if httpRequest.readyState == XMLHttpRequest.DONE
      if httpRequest.status == 200
        @_onAuthSuccess(httpRequest, options)
      else 
        @_onAuthError(httpRequest, options)

    
  @_onAuthSuccess: (httpRequest, options={}) ->
    console.log("zuKeeperAuth: successfully authenticated:", httpRequest.responseText) if options.verbose
    context = JSON.parse(httpRequest.responseText)

    window.ZuKeeper ?= {}
    window.ZuKeeper.context = context

    headEl = document.getElementsByTagName("head")[0] || document.documentElement;
    dependentScripts = if context.isDebug then options.dependentScriptsDebug ? options.dependentScripts else options.dependentScripts
    for scriptUrl in dependentScripts
      scriptTagEl = document.createElement('script')
      scriptTagEl.setAttribute('src', scriptUrl)
      scriptTagEl.setAttribute('type', 'text/javascript' );
      # scriptTagEl.setAttribute('crossorigin', 'anonymous') 
      scriptTagEl.async = false

      if scriptUrl == dependentScripts[dependentScripts.length - 1] && options.onSuccess?
        scriptTagEl.onload = options.onSuccess
        
      headEl.appendChild(scriptTagEl)
    
      
  @_onAuthError: (httpRequest, options={}) ->
    console.error("zuKeeperAuth: There was a problem with the request. #{JSON.stringify(httpRequest)}");
    # none of the dependentScripts are loaded anyway so just call directly
    options.onError?(httpRequest, options)

    document.location = "/auth?redir=#{document.location.pathname}"            
  

[Z3TA]

I have a module loader (like in Node.JS) that sync loads modules in the browser. Any ideas how I can achieve that without sync xhr ?

function foo() { var bar = require("bar"); ... }

[domenic]

@Z3TA https://github.com/substack/wreq

[Z3TA]

Thanks @domenic. wreq however requires you to change all the script tag's type to "text/wreq". And it parses the script, which might freeze the page longer then a xhr would. It will also require a lot of maintenance to update the parser to handle new JS syntax. And the project itself is not maintained.

[domenic]

JS parsing will freeze the page for much less time than XHR + the browser's JS parsing will.

Regardless, I was pointing you at a proof of concept you could use to adapt your module loader to no longer freeze the page.

[nhatchett]

Removing the ability to perform synchronous AJAX calls will certainly make my life far more difficult. As a business oriented web and desktop designer/developer I often face the challenge of modelling a highly synchronous process into a asynchronous program/web application - this is a problem that has been around for many years and will be around long after I have ceased programming. Examples of this problem are applications that require user interaction and do large database updates, file updates/reads, javascript web apps that maintain state with a server and passing data to other computers on a network, network messaging.

Unfortunately many business processes are synchronous (i.e. step B cannot be performed until step A is complete). Many synchronous processes can be modelled (i.e. programmed) using an event driven system. The major problem with such an approach (i.e. using asynchronous programming to represent a synchronous process) is how you deal with gap between submitting a request and receiving the reply (we could all start mining for bitcoins). In short the user has to wait for the reply regardless of whether the program is synchronous or asynchronous - the main advantage of the asynchronous approach is you can enable the user to abort the process before it is completed (totally unacceptable in many business applications).

The solution to this problem is to ensure that the back-end server, that is servicing the AJAX request, is man enough for the job and the application has been intelligently designed. Removing this facility to cure the problems caused by useless designers and developers is totally stupid (similar to the people causing this problem).

[foolip]

@timoreith if "can not be changed" is true then it's game over, no way around it. If usage across the web dropped by enough (unlikely IMHO) and sync XHR was removed from any browser this would be broken forever. (If not, then "can not be changed" was not true.)

[timoreith]

@foolip Thanks for your reply. It could be changed with a new SCORM standard and adapting any existing content and LMS's (like Moodle) to it. This is not likely.
Therefore, removing sync XHR would cause huge problems for a large part of the e-learning industry based on SCORM and its developers, who know why they use sync XHR. No user feels offended by a loading animation that takes a second.

This discussion feels more like demonizing an unloved technology (disliking supportive comments...?). There are indeed applications in which it is justified and its shutdown after years of availability (without an equal alternative) cannot be the solution.

If the hint in the dev console is not just an educational measure for careless developers, official dates about when sync XHR will really be removed would be helpful.

[foolip]

@timoreith, did you come here from the Chrome DevTools warning? I'm wondering if perhaps we should change that to make it very clear no change is planned as of now.

[timoreith]

I've been familiar with that message from Chrome for some time. The message in Edge was more confusing because it sounds like it already doesn't support sync XHR anymore (I can't reproduce it right now).

[ibash]

Another use case: synchronously reading a file object into memory. We can do this async, but this is a trade off we want to make (not done often, and since the file is local the delay should be limited, etc).

[thw0rted]

None of this is hard with promises (as returned by fetch):

function factorial(n) {
  if (n <= 1) { return Promise.resolve(1); }
  return factorial(n-1).then(result => mult(n, result));
}

// Pretend this is a fetch to a REST service that multiplies numbers for some reason
function mult(x, y) { return new Promise(resolve => setTimeout(() => resolve(x * y), 1000)); }