Add a WebSharperProject=Proxy type

[Jand42]

Background and motivation

The Proxy attribute in WS effectively replaces every occurrence of a type in the WS metadata with another one. For example [<Proxy(typeof(DateTime))>] type DateTimeProxy = ... defined in WebSharper.Main shows up as a definition for DateTime in the metadata as far as WS compilation is concerned, allowing the use of DateTime in translated code.

(Note: the Proxy attribute also contains the effect of JavaScript, making the latter superfluous.)

Proxying an entire existing library is currently a bit tedious: you have to reference the original lib, and create proxies for every type/module.

Proposal

New WS project type "Proxy" would enable JS-translation to the whole assembly, but translate to WS-metadata only and write it to an empty dll. This would enable: taking a .NET library code, adding WebSharper.FSharp/CSharp package and set this project type in *proj or wsconfig.json and if the original code has no WS-incompatible features, then you get a proxy dll immediately. Meaning: no .NET content, but WS metadata for every type in the library. Then, referencing the original dll and the proxy dll makes the library fully usable in .NET and JS too.

[granicz]

(Some relevant discussions from the WebSharper Gitter channel here)

[cgravill]

Would this allow us to take something like https://symbolics.mathdotnet.com/ and assuming nothing incompatible more easily get a WebSharper compatible build?

In one of our tools we build an self-contained browser-mode using WebSharper but we've left out some functionality due to library dependencies. I've thought of forking the Math.net but didn't want to deal with the ongoing maintenance.

[giuliohome]

@cgravill
Just a quick confirmation, out of my curiosity: the point is that you want to run that math lib on the client as javascript without remote calling the web server and without binding other existing js libs (e.g. maybe algebrite?), right?

[cgravill]

@giuliohome
We build scientific modelling tools, and with WebSharper we've been able to get them working:

1. in browser via WebSharper with no calls to server (we also add some WebAssembly) after the initial static download
2. in browser but with an active server running some code
3. on Azure hosted clusters

We're trying to make as much as possible work with 1. rather than 2. so they can scale easily, avoid data handling questions, privacy etc. but support people to do 3. when they want to work on problems beyond single machines.

It's really useful to be able to run exactly the same libraries rather than bind to an equivalent JavaScript library as going that way we've ended up having to run node.js on server which is unenjoyable. Blazor/Bolero is my long-term hope for productivity on the client-side.

We've written fine-grained proxies for some of what we do, but have held-off forking or customising anything as big as https://symbolics.mathdotnet.com/ to do the same.

(apologies for going a bit off topic on this issue @Jand42)

[Jand42]

@cgravill No problem, thanks for the details! I will make a test first with FSharp.Data.Adaptive, but MathNet.Symbolics looks like a good target for this feature too.

[Jand42]

Experimental feature released in https://github.com/dotnet-websharper/core/releases/tag/4.6.0.361
More examples and full libraries upcoming.