Skip to content
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

Open
amieres opened this issue Jan 1, 2019 · 11 comments
Open

Next steps #16

amieres opened this issue Jan 1, 2019 · 11 comments
Labels
discussion Idea or discussion

Comments

@amieres
Copy link

amieres commented Jan 1, 2019

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.

@granicz granicz added the discussion Idea or discussion label Jan 1, 2019
@cician
Copy link

cician commented Jan 3, 2019

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?

  • 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: dotnet/aspnetcore#5459

@cata
Copy link

cata commented Jan 4, 2019

+1 for supporting WebSharper.UI

@granicz
Copy link
Member

granicz commented Jan 4, 2019

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.

@granicz granicz changed the title Next step Next steps Jan 9, 2019
@zakaluka
Copy link

  • 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.

@cgravill
Copy link

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.

@Tarmil
Copy link
Member

Tarmil commented Apr 11, 2019

@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.

@cgravill
Copy link

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.

@baronfel
Copy link

@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!

@tylerhartwig
Copy link

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

@cgravill
Copy link

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.

@baronfel
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Idea or discussion
Projects
None yet
Development

No branches or pull requests

9 participants