Switching back to GHCJS 7

[malte-v]

I'd like to use GHCJS 7 with reflex-platform because GHCJS 8 doesn't support the REPL (see ghcjs/ghcjs#549). Is there a straightforward way to use that version of the compiler? Thanks!

[cgibbard]

It's not trivial to switch out GHC versions and get all the dependencies reflex-platform is trying to maintain to work out. An upgrade between two different versions of 8.x took around a week of fighting with various dependencies, to give some idea of the challenge. Also, there are patches like text-jsstring which you'll likely have to find versions which work on the old ghcjs as well. Also, you may have to use old versions of many other libraries, since there are extensions and features that were introduced with GHC 8.0 and at various points afterwards that many libraries rely on. I wouldn't recommend this approach, honestly.

Have you tried using ordinary ghci to run your application via jsaddle?

[malte-v]

Getting an ordinary GHCi REPL works fine, but the reason I'd like to use GHCJSi is because I need the JS output to update whenever I change the Haskell source (using ghcid). Do you know of some other way to get that "live-reloading" behavior?

[cgibbard]

Why do you need the JS to change? If you're using jsaddle, the javascript it's serving up shouldn't change between runs, it's a client that gets connected to by your app, and commands that cause javascript things to occur are issued to it over a websocket. This happens pretty much transparently, because the ghcjs-dom library is implemented in terms of jsaddle's abstraction, so all the stuff you ordinarily do to cause javascript to run will work whether you're compiling to JS or native code.

[malte-v]

To be honest I didn't exactly understand everything you've just written, but maybe I'm just approaching this in the wrong way. I would use a bundler (like parcel or webpack) to bundle the GHCJS output and some other stuff (stylesheets, static content) and use the bundler's development server to access the frontend. The backend would run somewhere else.

[srid]

@malte-v Tangential note: obelisk abstracts many of the stuff @cgibbard writes about. You might want to give it a try; ob run basically runs ghcid on frontend as well as backend.

[cgibbard]

To be honest I didn't exactly understand everything you've just written, but maybe I'm just approaching this in the wrong way. I would use a bundler (like parcel or webpack) to bundle the GHCJS output and some other stuff (stylesheets, static content) and use the bundler's development server to access the frontend. The backend would run somewhere else.

Well, that's how you would deploy, but for development, surely you wouldn't be doing that, right? You can just run the main widget in GHCi, and if it's compiled the right way, you get a jsaddle server running that you can open in a web browser. The frontend runs in native code then, but sends bits of javascript and the results back and forth with the web browser over a websocket. When you eventually compile with ghcjs, you'll get a bunch of javascript, and the mode of operation will be different, but for the most part, the app will look the same to the user.

(...and yeah, check out Obelisk, if you haven't already, it makes all this quite straightforward.)

[malte-v]

Thanks a lot for the explanations! I've tried Obelisk but didn't really find it easy to use since there is basically no documentation on the routing story. Now I'm using reflex-platform to run the frontend in GHCi via jsaddle-warp and it works really well.

[3noch]

@malte-v Thanks for the feedback. Getting docs for routing is pretty high priority. But in the meantime feel free to open issues against Obelisk as you explore it.

[troibe]

Could you in a little more detail on that approach? I was using the repl to get hints, types and error messages in my IDE. How do I accomplish a similar thing with just jsaddle?

Thanks a lot for the explanations! I've tried Obelisk but didn't really find it easy to use since there is basically no documentation on the routing story. Now I'm using reflex-platform to run the frontend in GHCi via jsaddle-warp and it works really well.

[malte-v]

@developandplay Have you been using GHCJSi?

[troibe]

@malte-v Sorry that might have come across in the wrong way. I was using GHCi previously and am completly new to GHCJSi.
If there is another easy way to get IDE support with GHCJS and jsaddle that doesn't invovle repl I'm happy to hear about that as well.

[malte-v]

@developandplay Why do you want to use GHCJSi? As far as I know it is no longer supported and GHCi is faster. You can easily compile your Reflex-Dom code with GHC using jsaddle-warp or jsaddle-webkit2gtk. GHCJS should only be needed when deploying, but for development purposes and IDE stuff I only use GHC(i).

[troibe]

@malte-v Thank you for pointing that out! Older tutorials used to mention GHCJSi for repl so I assumed that's the way to go.
Now I managed to get my IDE support with GHCi and use jsaddle for hot reload. If I used some of the terms wrong feel free to correct me I'm happy to learn.

[Ericson2314]

Mind pointing out these older tutorials which do that? It would be good to update them or add some sort of "out of date" notice.

[troibe]

This was on a few guides of the Miso framework . As a beginner that seemed simpler than reflex to get started.
For example: https://stackoverflow.com/questions/45651371/faster-compilation-for-haskell-miso/45651372
Sorry that I was using your reflex-frp issues. It was the only thing I could find online regarding ghcjs and repl not working.