dmjio
MicroHs
Yes, there are plans.
I have been dragging my feet on the JSVal implementation work, I was side-tracked by an unexpected release announcement that I had to scramble for and FRP stuff.
This week I can pick the ball back up on JSVal and run with it - and also on the MicroCabal build work in CI - since it seems many things have progressed there (like stm support), and you have already implemented foreign javascript import support.
I discussed some with the CPython community on how they handled their JSVal implementation with emscripten. They recommended I use something called FinalizationRegistry, after poking around GHC it seems this is what the WASM backend uses as well.
There is great documentation here on the JSVal implementation in the WASM backend by @terrorjack that I think could be very useful.
It seems the actual JavaScript values are stored in a global Map on the JS side, and the Haskell heap maintains a lifted value (named JSVal) that holds the keys to this Map along with some finalizers that will purge the JS values from the Map when invoked during GC.
I view JSVal as the biggest thing to support, along with the JSString API and synchronous / asynchronous callbacks (which miso needs for its Component lifecycle mounting / unmounting hooks).
MicroCabal might need to be modified to accept a js-sources: field (if it doesn't have that already maybe it does), so extra JS can be passed along to emscripten.
From there we might be able to get @amesgen 's jsaddle-wasm ( or a form of it ) to support this. jsaddle being an abstraction over different JavaScript FFIs (that can support hot-reload with jsaddle-warp). Also, ideally this JSVal implementation could work with emscripten's -sWASM=0 (so just JS). This way we could target mobile phones w/ miso-lynx. The phone runtimes don't support WASM yet, but there are open issues for that.
Lastly, this https://github.com/augustss/MicroHs/pull/255 should address this issue https://github.com/dmjio/miso/issues/195 in miso, to allow users to interactively build apps in the browser.
Will you need weak pointers to implement this? I will add them to MicroHs soon.
Awesome, taking a look. Will experiment with a JSVal implementation in a fork. Will link here, or do a draft depending on progress.
A light update on this, I am still in the process of getting miso to build with MicroHs, I have removed 6 dependencies from miso to aid in that process (I still have aeson and stm left, but am considering removing those two if I can). I think having a working build of miso w/ MicroHs will be a good guide for the JS FFI implementation work as well, to compare implementation semantics.
I'm still in the process of researching the JSFFI w/ emscripten, along with building out a couple different packages related to accessing native device APIs on the phone via (https://lynxjs.org), and getting the MicroHs build working. JS FFI is still a priority.
A little unrelated, but since MicroHs is portable C code and builds very quickly, I think we could host it on NPM (lots of other C projects on there that have JavaScript wrappers to drive them). Then we'd have a much wider audience that is already familiar with that toolchain to consume these projects.
npm install microhs
MicroHs would be available in their PATH as long as node_modules/ is on their PATH. This way it could be a 0-config solution for new users to Haskell and miso, to get started very quickly. Just an idea for now. The package.json file could serve as a Makefile that would drive MicroHs commands.
MicroHs has stm support, so you can leave that in.
How does one get a package added to NPM?
It seems we can create node packages from C projects using the node-gyp project. This should allow us to make MicroHs a node package for upload to npm.
npm init -y
We'd need a "binding file" for the MicroHs C for instructions to node-gyp.
{
"targets": [
{
"target_name": "addon",
"sources": [ "mhs.c" ]
}
]
}
then we could configure / build it
node-gyp configure
node-gyp build
after its built we should be able to invoke MicroHs commands from JS (we should only need a single index.js file)
const microhs = require('./build/Release/microhs');
console.log(microhs.version());
^ should be able to run the above with node index.js
This might require some modification to MicroHs itself to expose an API, maybe for invoking a build, the repl, version, etc.
Then assuming we have a package.json ( from the npm init command above ), we could just push MicroHs to npm whenever a release is made using npm publish.
This is all high level, hand-wavy, I can try to make an example for this (without MicroHs first), and then can make a PR to MicroHs, but again it might need modification, maybe some post-processing after the C is generated.
Also, regarding long term, I think MicroHs could benefit from other things in terms of increasing collaboration, adoption.
Dedicated communication channel
Haskell and GHC have been using https://matrix.org these days, and @simonmichael has been gracious enough to help miso in its efforts to establish communication channels on matrix as well. This has helped address bugs and provides fertile ground for synchronization and a lot of feature development (forgive me if this already exists and I am unaware).
A MicroHs GitHub organization
This way the following repositories could be housed:
- MicroCabal
- VSCode plugin integration w/ MicroHs + Debugger
- etc. sky is the limit.
Both GHC and OCaml have organizations as well. This opens up the doors to other opportunities including adding new users, domain name verification, granular permissions, branding. etc.
You then have the choice to move MicroHs to your organization, and then "pin" it on your profile (if you want). The opposite is not yet possible, maybe someone at @github could address this.
A MicroHs domain name
I think an internet domain for MicroHs would be a good idea. Once an org has been established (as noted above) and verified by @github it becomes easy to add subdomains for things like blog, etc. to host something like the MicroHs user guide, or official website. Further, all new repos in the org have the ability to host static files via github pages at a subdomain. @juliendehos has been helping miso use Github Pages to host its examples in this way, along with the official website. This cost us $0, and we don't have to manage servers.
A flake.nix file
nix is used heavily by Haskell developers to target other architectures. To address nix-minded folks we could create a Nix flake. This allows users to enter a shell w/ mhs, mcabal on their PATH and MHSDIR set correctly. Syntax would look like nix develop to enter a shell w/ mhs. I could upstream the nix build I already have and make a flake for this. This is how the WASM backend by @terrorjack currently operates.
npm integration
We discussed this above. Big gains to be had here I believe in terms of community adoption and web integration.
Summary
I know myself and many others would be happy to help with the above initiatives. Maybe @simonmichael can help us get a channel going on matrix. In regards to setting up a Github org, I'd be happy to help with that, along with pushing microhs to npm, while ensuring you retain sole admin authority of both the org and npm.
A #microhs matrix room would be great! Anyone can create it - someone who's a project owner or long term admin is best, though they can designate additional admins/moderators to help with room oversight.
(Related, choice of room creator is a bit more significant going forward because they have more permanent powers, since https://matrix.org/blog/2025/08/security-release .)
I'd never heard of matrix, but sure, it seems worthwhile.
And I did acquire the domain name microhs.org. It currently points at nothing.
It might be nice to have MHS as an option in GHCup. It's very easy to install anyway, but it gives microhs more visibility.