What needs to happen in order to get a decent Reflex workflow with a new GHC and without Obelisk?

Learn
#1

As a person who:

  • Has had an amazing experience with devenv.sh
  • Has had an absolutely terrible experience with Obelisk’s Nix setup
  • Loves reflex, but is discouraged because of how flimsy the setup is (especially if you want HLS and don’t know a ton of Nix)
  • Needs an iterative workflow like ob run, but doesn’t want to deal with Obelisk’s lack of documentation and issues such as this one

Is there any hope to get a Reflex app working without Obelisk? What steps needs to happen?

Edit:

Okay, this might have been poorly phrased. I am aware that it is certainly possible to use Reflex without Obelisk.

However, I’m not aware of a way to get a decent workflow or use a newer GHC(JS).

By workflow I mean something akin to ob run (you make changes and you see those changes on the page, I have wrestled with getting something similar with jsaddle and ghcid but the result was horrible and there’s virtually no information).

6 Likes
#2

I guess you want to use reflex-dom, and would most likely also want a web app, ie compile the app to javascript. In that case you could make an app without obelisk by using reflex-platform. Though this will not remove use of nix. The nix is necessary to cross compile template haskell to javascript.

#3

I guess you want to use reflex-dom, and would most likely also want a web app, ie compile the app to javascript. In that case you could make an app without obelisk by using reflex-platform. Though this will not remove use of nix. The nix is necessary to cross compile template haskell to javascript.

I added an edit to my original post to clarify what I mean. You can compile an app using reflex-platform, but that doesn’t mean the experience is anything close to decent.

#4

Why? I don’t believe that you can’t get working cross compilation environments outside of nix.

Sure, it might be harder.

#5

Is there a working iserv for JS (or other platforms for that matter) off the shelf? One big part of TH-cross that Nix fixes IME is that all these Nix frameworks patch the shit out of iserv to fix bugs.

#6

Why are the patches not upstreamed or the project properly forked?

#7

No clue - although tbh I don’t know where iserv (and friends) actually live. I think they had been shuffled around.

Also, does anyone really use iserv without Nix? I wouldn’t ever bother using it for, say, gamedev because Nix is soooooooo good at x-compiling C compared to …any alternative.

(Nix is arguably the best C package manager in existence today though, so that’s not a surprise.)

#8

what I meant by “necessary” is that one does not need nix if they are not cross compiling, as they can already compile reflex-dom by simply cabal build. The necessity of nix, at the moment, only arises because of cross compilation, as it is harder to do it without nix.

The way reflex-platform achieves cross compilation is by dumping the template haskell generated splices during normal x86 compilation, and loading these splices while cross compiling for JS and arm. This needs to be done for each package, and every module. If you want to do this without nix, it would be hard. Though some clever scripting could achieve this.

The reason this isn’t upstreamed is because this isn’t the way cross compilation should work, this is a hack to make things work in the absence of proper, performant cross compile support. I remember there were concerns regarding performance of handling large modules in nodejs/iserv approach, which led some to fall back to the save/load splices approach.

1 Like