Bolero
Bolero copied to clipboard
fsbolero
Next steps
I think the next step should be to make WebAssembly run in a Web Worker and keep the front end with WebSharper.UI. That would allow the integration of .Net libraries with the power of reactive UI.
I think it'd be wiser to wait for WebAssembly threading support to land in browsers+Mono/Blazor instead of having to deal with memory duplication and marshalling overhead between main thread and web worker. See also https://github.com/aspnet/AspNetCore/issues/5475
May I plug my shameless wish list?
- Hot reloading.
- A type provider for css classes. Maybe something like css modules.
- Time travel debugging and integration with ReduxDevTools.
With Fable it's possible to use Webpack for hot reloading and all sorts of goodies like this. Getting it all configured and working together can be difficult and fragile, but when it works development feels like magic. Which makes me wonder, should Bolero or Blazor implement some of these or rather make use of Webpack where applicable? Also relevant: https://github.com/aspnet/AspNetCore/issues/5459
As a general strategy for structuring web apps, what @amieres suggests would work perfectly fine in a WebSharper+Bolero app, just need a bit of orchestration to put the pieces together to enable calling the Blazor/WebAssembly component from a WebSharper client (so "JS calling WebAssembly"). The implementation details/technicalities (making these calls via web workers, seamlessly integrating them into the WebSharper code base, etc.) are relatively straightforward.
One key use case of Bolero, however, is to reduce/eliminate the interaction with/dependency on JavaScript and reverse the calling relationship to "WASM code calling JS if needed". If we take an actual use case, say TryFSharpOnWebAssembly, we can see that there is an HTML host page that brings in some JavaScript dependencies (ace.js, bulma.css, etc.) and embeds the whole Blazor app into it. This then makes occasional calls to the JS side (say, when it needs to talk to the Ace editor and tell it to highlight an error, etc.) All else/the core application logic (compiling F# code with FCS and running it) is running in WASM.
Now, as @cician mentions, there are some pretty heavy hitters with sharing arbitrary state between the Blazor runtime and a webworker. I also believe this is best dealt with from Blazor supporting threads.
- A type provider for css classes. Maybe something like css modules.
I just found this project recently that may be worth looking at - https://github.com/Fable-Fauna/Fable.Flora . It's just starting out, but there are a number of popular CSS libraries that are on the roadmap.
Making hot reloading work for code would be a huge benefit. The hot reloading for templates is a nice start. The benefits of state preserving automatic injection of updates is substantial when working on complex UIs.
@cgravill Yes that would be great. On the client we can simply serialize the model to local storage and reload the page, and on the server side we can look into https://github.com/humhei/FCSWatch/ for auto recompilation, which is apparently faster than dotnet watch according to this.
Nice, that project looks very interesting! I've played a bit with https://github.com/fsprojects/FSharp.Compiler.PortaCode but we're not using in general yet and just do a full server reset.
@tylerhartwig has been working on bolero client side hotreload using portacode here: https://github.com/tylerhartwig/Bolero.HotReload. it's at the point where we can find the update function to replace, but re-evaluating the current state model with the new function throws. If anyone's interested in jumping in and helping out there it'd be nice to have you!
Yes, actually Don revealed that how I was using it wasn't exactly supported.
I wrote a little work around last night that should work :) going to try and get some functionality out this weekend
The Bolero.HotReload looks really promising - the other use of portacode I was experimenting with was actually your https://github.com/baronfel/Giraffe.HotReload @baronfel I ran out of time and had to work on something else but I'm planning to come back to that too.
Oh great! Feel free to ping me anytime about it. It was easy to do with giraffe because the overall model was a reference to a single handler, so if I could re-evaluate a new handler I could swap out the middleware with a new version at will.