Re: =[xhr]

I would suggest taking a look at what you can do with Generators and
Promises in ES6 for example ( https://www.npmjs.org/package/co ) or if
you want to try something from ES7 async functions
https://github.com/lukehoban/ecmascript-asyncawait

I work on applications of over 200,000K LOC and we load everything in
one go, are you bundling and gzipping your source? Minifying?
150,000 LOC doesn't seem to require this complexity.

> Jmol utilizes a virtually complete implementation of Java in JavaScript.

I hope you aren't trying to force idoms from one language and
environment into a totally different one and then complaining that
there is an impedance mismatch.

B.

On Sun, Aug 31, 2014 at 11:12 AM, Robert Hanson <hansonr@stolaf.edu> wrote:
> Thank you for the quick reply. I have been traveling and just noticed it.
>
> I think you misunderstand. If you want to see what I have, take a look at
> any of the demos in http://chemapps.stolaf.edu/jmol/jsmol, in particular
> http://chemapps.stolaf.edu/jmol/jsmol/jsmol.htm or
> http://chemapps.stolaf.edu/jmol/jsmol/test2.htm There are hundreds of
> implementations of JSmol out there. We are seeing documented (very partial)
> use involving 150,000 unique users per month utilizing JSmol. Maybe a drop
> in the bucket, but it's a pretty good chunk of chemistry involving just
> about any involvement of molecular models on the web. I can give you some
> examples: http://www.ebi.ac.uk/pdbe/pisa/pi_visual.html
> http://www.rcsb.org/pdb/explore/explore.do?structureId=1RRP just to give you
> an idea.
>
> Jmol utilizes a virtually complete implementation of Java in JavaScript.
> Including Class.forName() -- that is, Java reflection. Now, the reason that
> is done is that with 150,000 lines of code, you don't want to load the whole
> thing at once. Good programming practice in this case requires
> modularization, which Jmol does supremely well, with over 150 calls to
> Class.forName().
>
> 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.
>
> You want me to make the asynchronous call, which could involve any number of
> dependent class calls (most of these are just a few Kb -- they do NOT
> detract from the user experience -- drop the thread (throw an exception
> while saving the entire state), and then resume the state after file loading
> is complete? Has anyone got a way to do that with JavaScript? In Java it is
> done with thread suspension, but that's not a possibility.
>
> Wouldn't you agree that a few ms delays (typically) the user experience
> would be far worse if the program did not work because it could not function
> synchronously or would have to be loaded monolithically? Downloading 5 Mb in
> one go would be a terrible experience, obviously, asynchronously or not.
>
> I'm simply reacting to what I am sensing as a dogmatic noninclusive
> approach. Are folks really talking about disallowing synchronous transfer
> via XMLHttpRequest? No use cases other than mine? Really?
>
> Can you also then give me creation of threads (not just web workers, but
> actual full threads for the DOM) and allow me to suspend/resume them? That
> seems to me to be the necessary component missing if this spec goes through
> removing synchronous file transport.
>
> This is not a minor matter. It is a very big deal for many people. I assure
> you, this will break hundreds of sites in the areas of general chemistry,
> organic chemistry, biochemistry, computational chemistry, crystallography,
> materials science, computational physics, and mathematics -- today, if
> browser designers follow the recommendation to "experiment with throwing an
> "InvalidAccessError" exception"
>
> It will shut down essentially all sites involved in web-based molecular
> modeling.
>
> Why so draconian a recommendation?
>
> I'm very seriously concerned about this -- that it would even be suggested,
> much less implemented.
>
> Again, I understand your concern. But absolutely seriously, this
> recommendation is actually, in my opinion, simply irresponsible. Peoples
> livelihood could be destroyed. (Not mine, I mean all those working on the
> professional sites that depend upon Jmol/JSmol for their proper function.)
> Huge huge expenses to figure out a work-around.
>
>
> Bob Hanson
> Principal Developer, Jmol/JSmol
>
>
>
>
>
>

Received on Sunday, 31 August 2014 11:01:16 UTC