Upgrade to new jszip #1055

2018-03-28T09:16:14Z

furstenheim commented

2018-03-28 09:16:14 +00:00

(Migrated from github.com)

jszip v3 has async functions that return promises instead of blocking the thread.

I've adapted the code and all the tests to run with the new version.

Of course there would be some missing parts: documentation is not updated (now xlsx.read and xlsx.write return promises)
It won't work in older browsers as I'm heavily using async await, probably babel could be used. For my purposes, which is using the library in Node 8, it is enough, but maybe you are interested in the changes.

cheers

jszip v3 has async functions that return promises instead of blocking the thread. I've adapted the code and all the tests to run with the new version. Of course there would be some missing parts: documentation is not updated (now xlsx.read and xlsx.write return promises) It won't work in older browsers as I'm heavily using async await, probably babel could be used. For my purposes, which is using the library in Node 8, it is enough, but maybe you are interested in the changes. cheers

👍 1

furstenheim commented

2018-04-01 17:10:14 +00:00

(Migrated from github.com)

This pr is related to a couple of issues #600 #1017 #869 #408

SheetJSDev commented

2018-04-01 18:20:02 +00:00

(Migrated from github.com)

@furstenheim to be clear, promises are "deferred". When the actual work is being done, it will still block the main thread (pure JS is still single-threaded, not too dissimilar to Python). Promises don't magically make things run off the main thread -- they merely shift the timing. Platform APIs have to provide the functionality in a way that doesn't block the main thread, like the zlib bindings in nodejs. The situation is similar to how NumPy circumvents the Python global interpreter lock.

To see this, try running the following command in your node shell:

setTimeout(() => console.log("done"), 1000); while(1);

setTimeout and most promise APIs don't preempt the execution.

If you want to process off the main thread in nodejs, check the server demo for a few strategies. You can use child_process.fork with a simple JS script or use exec to call the xlsx bin script or use the tiny-worker Web Worker "shim"

Note: If you want to process off the main thread in web browser, the standard technique is to use a Web Worker.

@furstenheim to be clear, promises are "deferred". When the actual work is being done, it will still block the main thread (pure JS is still single-threaded, not too dissimilar to Python). Promises don't magically make things run off the main thread -- they merely shift the timing. Platform APIs have to provide the functionality in a way that doesn't block the main thread, like the `zlib` bindings in nodejs. The situation is similar to how NumPy circumvents the Python global interpreter lock. To see this, try running the following command in your node shell: ```js setTimeout(() => console.log("done"), 1000); while(1); ``` setTimeout and most promise APIs don't preempt the execution. If you want to process off the main thread in nodejs, check [the `server` demo for a few strategies](https://github.com/SheetJS/js-xlsx/tree/master/demos/server). You can use `child_process.fork` with a simple JS script or use `exec` to call the `xlsx` bin script or use [the `tiny-worker` Web Worker "shim"](https://www.npmjs.com/package/tiny-worker) Note: If you want to process off the main thread in web browser, the standard technique is to use a Web Worker.

aivarasbiliunas commented

2018-10-03 12:35:20 +00:00

(Migrated from github.com)

@SheetJSDev it does make things "magical" because by deferring heavy calculation/work you are not blocking higher priority events which results in smoother experience at least for browser users.