4 ms·
Has anyone tried Reflex? Really interesting concept in Haskell + GHCJS https://github.com/ryantrinkle/try-reflex https://github.com/ryantrinkle/try-reflex I li
by bribri 11y ago
Has anyone tried Reflex? Really interesting concept in Haskell + GHCJS
https://github.com/ryantrinkle/try-reflex https://github.com/ryantrinkle/try-reflex
I liked Elm but I felt the language was a bit limited coming from Haskell, ex no type classes so you have List.map, Signal.map, Set.map, etc
Overall Elm is great in terms of tooling, setup, error messages, performance, js interop though
- ablesearcher 11y agoReflex is great (and its author is a genius) but it's not really useful yet for non-desktop apps. Because Reflex + GHCJS is impossibly slow on mobile. As an experiment, try using chrome (iOS) or android to load this: obsidian.systems/reflex-nyhug/ or this: https://obsidian.systems/ https://obsidian.systems/ They're both reflex apps. GHCJS is bees-knees. But unfortunately, minimizing-code-size/mobile-performance has not been a priority. (It's understandable, as Luite can't do everything himself.) (Aside: the best solution I've seen -- in terms of generated code size -- in GHCJS-land right now is: https://hackage.haskell.org/package/react-flux https://hackage.haskell.org/package/react-flux. Anecdotal, though. YMMV.) I can't wait for GHCJS to be ready for prime time. I wish all these alt-JS-haskellish language authors (of Purescript, Elm, Roy, etc.) would just work on making GHCJS better. It's a bummer that Clojure and Scala are much newer than Haskell and yet they both have a mature, production-ready JS compiler. The statically typed ML-family is too small for multiple JS compilers. The entire community needs to pick one and let the others die. Otherwise, we end up with several half-baked solutions and not a single industrial-strength one.
- purescript 11y ago> I wish all these alt-JS-haskellish language authors (of PureScript, Elm, Roy, etc.) would just work on making GHCJS better. All three of those have very different goals and trade-offs from GHCJS. I agree that it would be nice to share more work/knowledge though. One of the nice things about AltJS is that several languages can coexist in the same codebase.
- ablesearcher 11y ago> "All three of those have very different goals and trade-offs from GHCJS." And therein lies the problem. In my view, the most important goal is to have at least one really good AltJS-Haskellish language with a fully-featured ecosystem of libraries. (I'm fine if that language is PureScript, btw. PureScript is fantastic.) The problem -- which Clojure and Scala programmers seem to have sorted -- is that our community is too small to support several Haskellish-AltJS compilers. Do we really want several perpetually nascent solutions? > "One of the nice things about AltJS is that several languages can coexist in the same codebase." Theoretically, you're right. But how many production code bases are there in AltJS-Haskell (vs. say, Clojurescript)?
- galfarragem 11y agoNormally very smart people have an huge ego and hate politics. It's always a pity to see so much potential wasted.
- rudolf0 11y agoCan something like JSX be used with this? It looks like a cool language, but I was never able to get behind HTML "DSLs". Their only advantage is ease of implementation and that you get to write in your current language, at the expense of write/read verbosity and comprehensibility. Even Jade/HAML/Slim I'm ok with, since they're a terse iteration on HTML rather than a nested monstrosity of code blocks. But I prefer JSX or Handlebars.
- beefsack 11y agoI'm yet to see strong objective reasoning either for or against JSX, it seems to really polarise people. From an Elm perspective, I feel that the HTML API is well designed and doesn't get in the way, so I'm not entirely fussed.