Consider mentioning reflex-platform in the README

[tysonzero]

As of now reflex-platform has a relatively up to date version of miso built in. Also Ryan is working with me to make sure that reflex-platform works well for miso (or more generally for any non-reflex frontend framework). I think it is worth mentioning it in the README, as it enables things like incremental compilation and will make it easier to use miso on mobile.

For isomorphic apps a simple default.nix like the following should work:

(import ./reflex-platform { useTextJSString = false; }).project ({ pkgs, ... }: {
  packages = {
    common = ./common;
    server = ./server;
    client = ./client;
  };

  shells = {
    ghc = ["common" "server"];
    ghcjs = ["common" "client"];
  };
})

Assuming that common, server and client are Haskell projects with cabal files (although it seems like they do not need their own default.nix files).

[FPtje]

I'm not exactly sure what building miso into reflex-platform means. I see that the commit you refer to puts miso in the overridden haskellPackages, but I'm not sure as to why. Reflex and Miso are competing platforms. Now I'm not much of an expert on reflex, but the README of the reflex-platform repo shows that it is to help to develop and deploy reflex based applications before showing examples of reflex-frp. How and where does Miso fit in that story and why should that be mentioned in Miso's README?

[tysonzero]

So reflex-platform is becoming a generic way to deploy Haskell apps to multiple platforms (ghc, ghcjs, and mobile). Off the top of my head It improves over stack by handling mobile deployment and doing a good job of handling ghcjs, it improves on raw nix by supporting incremental building, and by supporting mobile deployment. I'm sure there are plenty of other benefits but those are the ones I know of.

You are correct that it was originally designed for reflex, but it really isn't fundamentally attached to reflex, just the name and some optimizations (that should help miso to a similar degree that they helped reflex) and probably a few QoL things that are currently specific to reflex (but can I'm sure be extended). The name is actually going to change sometime (once a good name has been decided on) to emphasize that it is not tied to reflex.

miso was put into the overridden haskellPackages so that you could get a relatively up to date version of miso when building with reflex-platform. @ryantrinkle is working with me to make reflex-platform work as well as possible for miso and by extension hopefully every other Haskell web framework that does or will exist.

You can think of reflex-platform as a competitor to stack or to "vanilla nix". I am actually using it right now for both of my miso projects (and I do not know reflex), and the incremental building has been a substantial workflow improvement.

[dmjio]

Reflex team / platform has done a lot of incredible work in upstreaming features (GHC cross compilation for ARM) into nixpkgs, which miso now utilizes as of 1.1, along with jsaddle, per @cocreature's work. It seems incremental building is achievable via a blend of cabal-new build w/ nix-shell. Core functionality for building / deployment should be present in miso now, but building miso via reflex-platform is always a viable option as well.