Haskell @ React Summit

Links
1

Thought people might find this interesting. One of the core developers / architects of LynxJS.org mentioned Haskell and the integration between GitHub - dmjio/miso: 🍜 A tasty Haskell front-end framework and https://lynxjs.org.

^ In this repo there is a link to the talk, and its queued up at the Haskell portion.

This is still heavily under development and requires nix to get a forked GHCJS (BigInt support needing a polyfill), we are able to draw native iOS UIView and native Android views as welI. It is also extensible with other native device APIs, which will be wrapped in JS and are accessible to us via Haskell.

This is the same code they use in the actual TikTok app, so it sees a lot of use.

Special thanks to the LynxJS team for democratizing react-native style development with their innovative API (PrimJS API) and dual-interpreter approach.

13 Likes
2

Does this really use GHCJS? Or the newer GHC with JS backend?

3

I call the new JS backend in GHC, GHCJS9122. In practice you still have to fetch a new compiler so it feels like the same experience as just using GHCJS86. Easier naming imo. But from a compiler developer perspective, it’s a new backend yes. From an end user perspective it’s just a new version.

Right now this only works with the latest GHC and its new JS backend (GHCJS9122)

4

8.6 vs 9.12 is a leap in capabilities, that’s years of additional improvements

5

Yes and no. Older versions of GHCJS produce smaller payloads than the current JS backend (by a large factor, maybe 5x). Luckily current minifiers help a lot.

In theory this should work with GHCJS86, but I haven’t tried yet.

1 Like
6

5x that’s crazy! Is that all runtime bloat or actual codegen just becoming bigger? I don’t think that’s supposed to happen.

In another project I noticed binary going from 5MB to 70MB just by adding -threaded. I don’t think JS needs that in particular for example.

7

Yea but the minifiers help, also on Android the code can get JIT’d so it’s faster

1 Like