{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiatr5zd464g5tbeeoyostpxw2wsi74aike77ldpnpvhr2y46ys6pu",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mlvn2xrzc2e2"
  },
  "path": "/t/hatter-native-haskell-mobile-apps/13952#post_19",
  "publishedAt": "2026-05-15T13:28:47.000Z",
  "site": "https://discourse.haskell.org",
  "tags": [
    "sparkling"
  ],
  "textContent": "Interesting, cool write up. In my opinion it is kind of comparing apples and oranges. I’m writing JS bindings to an already mature set of native C++ libraries deployed in the TikTok app, I’m not attempting to write the native libraries themselves. I believe that is a monumental effort that requires corporate backing, hence ByteDance.\n\nI understand the compile-to-JS approach (as opposed to native compilation) might seem pathological, but since the project is half TypeScript (and a mini-React implementation) we’re following the React native path to target mobile phones. This is the path the virtual DOM ecosystem chose. LynxJS has now made that path available to all web frameworks, which is great.\n\nThanks for the agentic workflow link, will check it out. The recent VFrag (React fragment) additions did use Claude Sonnet 4.6 to test all the new edge cases introduced. It surprisingly did a good job, after some prodding.\n\nThis “repetitive cross-platform plumbing” (LLM speak?) is anything but, I can assure you. It entails re-architecting React internals, splitting event delegation, diffing / patching to execute in separate interpreters, using WebWorkers to communicate. There isn’t much prior art to go off of besides ReactLynx (preact) itself, and we’re not exactly identical to that. So we’re one of the few attempting this, now with VueLynx. Regarding “native modules, FFI bindings”, these are things we will soon get for free through the module system and ecosystem via sparkling.",
  "title": "Hatter: Native Haskell mobile apps"
}