dmjio
miso-native
Study the things, do the thing.
- https://trac.webkit.org/wiki/JavaScriptCore
- http://nshipster.com/javascriptcore/
- https://github.com/pzp1997/elm-ios
This would be a dream. Any idea when this would fit on the roadmap, or the scope of how big this would be? I'm imagining this to be a massive undertaking, as the mobile world is very complex and fragmented. Also would there be any concern with running GHCJS on mobile?
@smaccoun thanks for bringing this up. There are plans in the works. While we've shifted from the react-native approach (primarily due to how poor scrolling performance will be w/ GHCJS), native is definitely something we're going to target. @cocreature has recently refactored the codebase to support @hamishmack's work, jsaddle. This allows for developing quickly via GHC (and is a form of native). A byproduct of this refactor is the codebase is more modular and pieces of the miso architecture can be made swappable (including code that would be used for native). So the plan now is to actually write code in Haskell that interfaces with native code on the architectures we care about.
Going forward I'm looking into taking advantage of Haskell projects that interoperate well with Objective-C / Swift for cocoa, and eventually Java for android.
Interesting to hear about the poor scroll performance with React Native and GHCJS. Is it known why that's an issue...and if it's eventually fixable? Wondering if it's the (usual?) issue of GHCJS trying to imitate laziness in JS and in this case somehow unable to properly match the implementation in a performant way. I guess that'd rule out all projects that use GHJS and any attempts to interface with RN if that's the case.
Very cool about jsaddle, I haven't fully grokked the full implications of having that yet. I wonder if Eta could even be leveraged for the Android part, but given it only works for GHC 7.10 that might be a bit limiting.
I'd be very curious to see what kind of code share could be achieved by going to the native architecture approach rather than RN. I guess in theory you could match that of RN, which I often find in my own projects hits around at least 95%.
I guess for now I'll stick to Typescript RN for production mobile stuff, but I'll keep my eye on this and see how this progresses and maybe get involved once I understand a bit better the current Haskell for mobile landscape