Re: =[xhr]

On Sat, Jul 12, 2014 at 8:57 AM, Robert Hanson <hansonr@stolaf.edu> wrote:
> Hello, I am the principal developer of Jmol, which has been successfully
> ported to JavaScript/HTML5 as JSmol.
>
> The following statement at http://xhr.spec.whatwg.org/ concerns me greatly:
>
> Developers must not pass false for the async argument when the JavaScript
> global environment is a document environment as it has detrimental effects
> to the end user's experience. User agents are strongly encouraged to warn
> about such usage in developer tools and may experiment with throwing an
> "InvalidAccessError" exception when it occurs so the feature can eventually
> be removed from the platform.
>
> I do understand the overall desire to not load files synchronously. I have
> designed Jmol to use asynchronous file transfer whenever possible. However,
> this seems rather heavy-handed, as there are situations where asynchronous
> AJAX file transfer is absolutely critical. (Or convince me that is not the
> case.)
> JSmol is using Java2Script, which is a highly effective port of Java to
> JavaScript. I have been able to reproduce all the thread-based behavior of
> Jmol in HTML5 using just the one JavaScript thread, however a key component
> of this system is that "Java" classes (such as java.io.OutputStream..js,
> which is the JavaScript equivalent of java.io.OutputStream.java) must be
> loaded on the fly. For example, a call to
>
>  x = new java.io.ByteOutputStream(b)
>
> must hold while java.io.ByteOutputStream.js is loaded, if this is the first
> call to instantiate that class.
>
> Q1) I don't see how that could possibly be done asynchronously. This could
> easily be called from a stack that is 50 levels deep. Am I missing something
> here? How would one restart an entire JavaScript stack asynchronously?
>
> Q2) Is there an alternative to "the main thread" involving AJAX still using
> synchronous transfer?

You're right that this isn't really possible, but that's intentional,
as halting your program while you wait for a network fetch is a bad
idea (particularly when it can happen unexpectedly, because the "first
call" to a given API may be in different spots depending on user
behavior or other non-determinism).

This is why the module system being developed for Javascript doesn't
do this, and requires code to explicitly ask for the module, rather
than auto-loading.  The built-in syntax just waits to execute the
entire file until all dependencies are satisfied, while the Loader API
instead operates in a traditional async style.

~TJ

Received on Monday, 14 July 2014 22:50:43 UTC