| 24 May 2026 |
 tks_123 | alexfmpe As for HLS (vscode, etc.) should I put js backend programs and normal backend programs into different .cabal projects somehow? So HLS/cabal (somehow) knows which backend to use? (I'm assuming you can put both normal haskellPackages and and pkgsCross.ghcjs.haskellPackages into the same nix environment?) | 12:56:04 |
| tks_123 | * alexfmpe As for HLS (vscode, etc.) should I put js backend programs and normal backend programs into different .cabal projects somehow? So HLS/cabal (somehow) knows which backend to use?I'm assuming you can (somehow) put both normal haskellPackages and and pkgsCross.ghcjs.haskellPackages into the same nix environment?) | 12:57:10 |
| tks_123 | * alexfmpe As for HLS (vscode, etc.) should I put js backend programs and normal backend programs into different .cabal projects somehow? So HLS/cabal (somehow) knows which backend to use?I'm assuming you can (somehow) put both normal haskellPackages and and pkgsCross.ghcjs.haskellPackages into the same nix environment?) | 12:57:13 |
| tks_123 | * alexfmpe As for HLS (vscode, etc.) should I put js backend programs and normal backend programs into different .cabal projects somehow? So HLS/cabal (somehow) knows which backend to use? I'm assuming you can (somehow) put both normal haskellPackages and and pkgsCross.ghcjs.haskellPackages into the same nix environment? | 12:57:24 |
| tks_123 | * alexfmpe As for HLS (vscode, etc.) should I put js backend programs and normal backend programs into different .cabal projects somehow? So HLS/cabal (somehow) knows which backend to use? (I'm assuming you can (somehow) put both normal haskellPackages and and pkgsCross.ghcjs.haskellPackages into the same nix environment?) | 12:57:36 |
 alexfmpe | You probably mostly want HLS only for native builds, if nothing else for speed | 12:58:17 |
| alexfmpe | There's no ghci for js backend | 12:58:25 |
| alexfmpe | I don't know if there's conflicts shoving both compiler/package sets in the same nix env, and it also depends on whether you just want the tooling from nix or also the dependencies | 13:00:15 |
| alexfmpe | Safest thing might be to make the native backend the default, and have a separate shell for js builds | 13:01:03 |
| alexfmpe | Past that you're into tinker-with-infra territory | 13:01:35 |
| alexfmpe | This is a bit old in early-adopter terms, but might help as a reference: | 13:05:08 |
| alexfmpe | https://github.com/bfeitknecht/impli/pull/6/changes#diff-93b556800e5bfe30a541d4c38712e88fc5763a362ab43de7446476ed3bddcee0 | 13:05:10 |
| alexfmpe | Well, technically you can throw your package into the nixpkgs haskelloverides, and then nix-build like normal or with pkgsCross.ghcjs | 13:06:11 |
| alexfmpe | But you asked about cabal.project so I assume you meant everyday local dev, not 'prod' build | 13:06:38 |
| tks_123 | Yes, everyday local dev :) But... for everyday local dev, I'd want to... check if the website ... works in the browser (I guess)? | 13:08:19 |
| tks_123 | * Yes, everyday local dev :) But... for everyday local dev, I'd want to... check if the website ... works in the browser. | 13:08:50 |
| tks_123 | while also develop the website's frontend and backend (in vscode) | 13:09:20 |
| tks_123 | (yes how the final thing is built is technically a separate question..) | 13:09:42 |
| tks_123 | * while also developing the website's frontend and backend (in vscode) | 13:10:02 |
| alexfmpe | Oh gotcha. Out of habit I was assuming jsaddle-warp for dev so the frontend would also be using native builds | 13:26:23 |
| alexfmpe | But it sounds like you don't assume that for your project | 13:27:43 |
| tks_123 | alexfmpe Hmm, it seems I was using jsaddle 2-3 years ago in my projects. it seems for some reason i wasn't aware of jsaddle-warp :S | 13:48:03 |
| tks_123 | so i thought i had to always run a full ghcjs (the old ghcjs in this case) build just to preview my web apps... :S | 13:48:30 |
| tks_123 | which makes me wonder, why i was even using jsaddle. Now i'm confused | 13:49:11 |
| tks_123 | * which makes me wonder, why i was even using jsaddle | 13:49:29 |
| tks_123 | This is how my JS program looked:
main :: IO ()
main = do
doc <- jsg "document"
x <- doc ^. js1 "getElementById" "jspage"
-- ...
Some of the imported modules:
import GHCJS.Foreign.Callback
import GHCJS.Marshal
import GHCJS.Types
import JSDOM.Custom.Window
Some of the packages in the .cabal file:
ghcjs-base
ghcjs-dom
jsaddle
jsaddle-dom
| 13:53:56 |
| tks_123 | Are these things (modules, cabal packages) still relevant for the new JS backend? (Is this still the modern way to do it?) | 13:54:32 |
| tks_123 | * This is how my JS program looked:
main :: IO ()
main = do
doc <- jsg "document"
x <- doc ^. js1 "getElementById" "foo"
-- ...
Some of the imported modules:
import GHCJS.Foreign.Callback
import GHCJS.Marshal
import GHCJS.Types
import JSDOM.Custom.Window
Some of the packages in the .cabal file:
ghcjs-base
ghcjs-dom
jsaddle
jsaddle-dom
| 13:55:00 |
| alexfmpe | jsaddle-* all works with js backend just the same | 13:57:37 |
| alexfmpe | same for ghcjs-dom | 13:57:53 |
