Support for web workers

[Bananas-Are-Yellow]

The only example I can find for using a web worker with WebSharper is this old demo:

https://bitbucket.org/IntelliFactory/websharper.demos.webworker/src/53a08c18e9f9e62ba494fb154f05751738d26986/websharper.demos.webworker/Client.fs?at=default&fileviewer=file-view-default

With a single page application this appears to work, because all the JavaScript required is put into a single js file. But with my regular application, feeding the js file of the current project to the web worker fails because there are dependencies on other js files, including WebSharper.Core.JavaScript/Runtime.js.

[cgravill]

Having explicit support for targeting a web worker from WebSharper would be useful. What I'm currently trialing in WebSharper 4.x/Zafir is:

Configure projects as libraries
Set

<WebProjectOutputDir>Content</WebProjectOutputDir>

(previously this was <WebSharperProject>Bundle</WebSharperProject>)

that outputs everything into \Content\Scripts\WebSharper

You can then manually determine the libaries you need and import them (and bundle as desired):

    importScripts("build/WebSharper.Core.JavaScript/Runtime.js");
    importScripts("build/WebSharper.Main.js");
    importScripts("build/WebSharper.Collections.js");
    importScripts("build/WebSharper.Web.js");

    importScripts("build/ourlibrary.js");
    importScripts("build/anotherlibary.js");
    importScripts("build/yetmorelibary.js");
    importScripts("build/ourapp.js");

Hope this helps, having something like this route documented would be really useful! In WebSharper 3.x this was a bit easier as you can get everything in concatenated form.

[cgravill]

To add some background on this, it seems potentially very useful to have direct support for web workers with build templates. This would let us progressive add our F# based modules to larger web based tools – ones where we currently call onto the server for those parts. There would also the be the possibility to optimise those modules as the functions we actually call don’t touch much of the BCL.

Presently we bundle up the various parts including other bits of UI type code then stick it all in a web worker. I’ve considered using one of the JavaScript optimisers but WebSharper has far more context for this.

[cgravill]

Unfortunately, this seems to have gotten more awkward, possibly with recent versions (using Zafir.4.0.159.36-beta6) as the generated code directly looks for Global on window. I've been able to workaround this by modifying the equivalent global self in web workers around the import:

eval("self.window = self");
// Load the transcompiled F# code.
importScripts("websharperlibs.js");
importScripts("ourtranspiledlib.js");
eval("delete self.window");

note: I used eval as TypeScript sensibly marks self as read-only so this may not work indefinitely but you might also be able to do without that.

It would be great if WebSharper could look for its global on self as well (or avoid globals).

[FilippoPolo]

Any word on this? We mostly use W# to do the lengthy math operations as F# is nicer for that kind of stuff, and they need to go in a worker.

[Jand42]

We still keep an eye on this, will be high priority after 4.0 stable release, coming soon.

[cgravill]

Any news on this one? It would be great to have direct, clean support for Web Workers.

In case it's useful, as an update I needed to use this in a context where eval was prohibited. I found a better approach in TypeScript of just casting away read-only (and rest of type):

let selfLocal: any = self;
selfLocal.window = self;
// Load the transcompiled F# code.
importScripts("websharperlibs.js");
importScripts("ourtranspiledlib.js");
delete selfLocal.window;

[granicz]

Yes, I think we are now ready to tackle this between .NET Core support (4.2) and full TypeScript support (5.0).

[Tarmil]

I posted plans to implement web workers at #970, @Bananas-Are-Yellow @cgravill @FilippoPolo I would love to hear your thoughts about it!