-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Next steps #16
Comments
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 dotnet/aspnetcore#5475 May I plug my shameless wish list?
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: dotnet/aspnetcore#5459 |
+1 for supporting WebSharper.UI |
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. |
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. |
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.
The text was updated successfully, but these errors were encountered: