Yes, sure, a lot of it can be done asynchronously. And I do that as much as possible. But I suggest there are times where synchronous transfer is both appropriate and necessary. The case in point is 50 levels deep in the stack of function calls when a new "Java" class is needed.
This statement is inacurate; if you conceptualize your Java-to-JavaScript conversion to use Async calls where normal calls are done in Java, you should not suffer from any issue. As C# did show, every single piece of high-level code can be transformed in an asynchronous one by the mean of a state machine, which can be auto-generated from the initial code without any major syntax change. Sure, this will require a large rewrite of the conveter you are currently using, and this is a non-trivial work not a lot of people can achieve today, but I think everyone here understands that. We don't expect you to make the switch overnight, nor in the coming months.
The reason we don't expect this is that neither the browser implementation of the concepts nor the developer tools and experience with the technology required for this rewrite are tailored for a broad usage at this time. I think everyone also understands the old code relying on sync xhr will take a lot of time to go away. But, eventually, browsers will have to break sites. The hope is to reduce the amount of sites over time, by the use of scary warnings like this.
What you need to understand is that this feature will eventually be removed from the web platform, and therefore spec writers already warn now of what shall be done in the future, so that the phasing out will work the same way accross all browsers. This doesn’t mean this phasing out is planned anytime soon, but at least people will have received a fair warning for a long time when such phasing out will happen.
If you rely on synchronous xhr calls for your Java-to-Javascript converter, you would better schedule in the coming years a rewrite that makes use of async/await calls.
