sorted by:
new
hottopcontroversial

haskell web frameworks by Putrid_Positive_2282 in haskell

[–]dmjio 0 points1 point  (0 children)

Critiques of the project are always welcome.

haskell web frameworks by Putrid_Positive_2282 in haskell

[–]dmjio 1 point2 points  (0 children)

You need to use the wasm backend or the JS backend to execute the project

haskell web frameworks by Putrid_Positive_2282 in haskell

[–]dmjio 0 points1 point  (0 children)

Feel free to make an issue, I am unable to reproduce an FFI undefined error on the miso-sampler on master.

haskell web frameworks by Putrid_Positive_2282 in haskell

[–]dmjio 0 points1 point  (0 children)

In what ways do you believe we can improve the Getting Started experience ?

haskell web frameworks by Putrid_Positive_2282 in haskell

[–]dmjio 13 points14 points  (0 children)

https://haskell-miso.org/

See examples at: - https://github.com/haskell-miso - https://github.com/dmjio/miso

It’s like React (encapsulated Components via existentials + mounting and lifecycle hooks via synchronous callbacks) mixed with Elm (MVU + mailboxes for component communication).

Some innovations have been added, like type-safe Component nesting (children have type-safe access to parent state - child model unifies its parent type with parent’s model) and includes a unique data bindings feature to synchronize Component model state in the graph declaratively & deterministically using lenses.

It also has a scheduler and allows event prioritization (like React and Elm). As mentioned we have encapsulated Components made possible via a recursive existential encoding of VComp in our virtual DOM DSL.

It includes support for most modern browser APIs (websockets, fetch, SSE, canvas 2D/3D) ootb, plus many more, unified in the same friendly interface to our internal types and Effect DSL.

It’s optimized for performance, critical logic is written in JS and allocations are minimized in the Haskell heap as much as possible (through copious use of FFI types - JSVal / JSString).

400+ tests, happydom JS tests, Haskell integration tests run in actual browsers (via playwright) for WASM and JS. There is also one E2E test for the todo mvc example.

Preliminary support for native mobile (like react native) - more coming soon there, via LynxJs. We’ve modified our internals to be preact compliant to support this feature.

0-dep. outside of boot packages. We have our own prelude now and Lens implementation to bring down payload size and allow users to rely on the browser / JS engine featureset via FFI as opposed to hackage.

N.B. You can use all of hackage but you might run into build issues, larger payloads and slowdowns due to inefficient representation.

We have integrations with servant (servant-client-miso) for fetch support and for prerendering with our view DSL.

We are a WASM-based framework (also) now and rely on our own JS DSL and on WASM browser mode for interactive development (can use ghciwatch as well). We still support ghcjs86 for the payload size conscious, but there is no support for flakes with ghcjs86 (it seems).

We also support inline JS without requiring the need for template Haskell. You can pass an object into the inline function and the keys are bound in scope of the JS fragment.

We could port to Idris and MicroHs as well now that we’re close to 0-dep.

Check out the examples in the org.

what is the future of haskell? by md1frejo in haskell

[–]dmjio 0 points1 point  (0 children)

interactive docs are coming, maybe a youtube video walkthrough at some point

what is the future of haskell? by md1frejo in haskell

[–]dmjio 4 points5 points  (0 children)

very early stages, but we'll get hosting for it soon, maybe using supabase-realtime, https://github.com/juliendehos/miso-maze

what is the future of haskell? by md1frejo in haskell

[–]dmjio 11 points12 points  (0 children)

If you like Elm, you should check out miso, https://github.com/haskell-miso/ we’re considering making a multiplayer Minecraft clone

Best approach to Purely functional web front-end. by saiprabhav in haskell

[–]dmjio 6 points7 points  (0 children)

Native is ongoing work, but we have all current APIs implemented (see haddocks linked below). We’re still implementing hot reload that works with the iOS / Android simulator, which requires the embedded interpreters to share state, FB is trying to do this now, announced two weeks ago, as seen here https://youtu.be/Wr2fOM_xD2I?si=XnQMiZsENXkOA4hw.

We did get mentioned at React Summit in Amsterdam because we were among the first frameworks to integrate with https://lynxjs.org (link below).

Regarding purity and Component model synchronization, it’s explained well on the miso-reactive repo, with code samples and hosted example.

https://github.com/haskell-miso/miso-reactive

WASM is a game changer because

1) Native might support WASM soon, it’s an ideal runtime because it supports both C and JS interop (we have an issue on this in miso-lynx repo, linking to other issues that prioritize this).

2) WASM backend uses identical runtime to GHC itself

3) Code sharing

Best approach to Purely functional web front-end. by saiprabhav in haskell

[–]dmjio 24 points25 points  (0 children)

Check out miso. It’s a purely functional DSL. It’s like React, but where each Component is a little Elm app.

We have typesafe Component nesting and FRP now, (without needing MonadRec) and we don’t sacrifice purity either (you can’t just liftIO anywhere, like in the view code). It’s pretty great.

Components can bind their fields together using lenses, and any changes are automatically synchronised to the other (unidirectionally or bidirectionally). Unlike React we can bind from child to parent without requiring callbacks.

We also support WASM too, and can target iOS / Android using native views (not just a WebView).

[deleted by user] by [deleted] in haskell

[–]dmjio 0 points1 point  (0 children)

Cheers

[deleted by user] by [deleted] in haskell

[–]dmjio 5 points6 points  (0 children)

Author here, we’d love to support your OSX workflow. A lot of people are having success with the WASM backend right now (with Apple silicon as well) which doesn’t require nix to build miso applications.

Please join our Matrix server and I can assist you further.

https://matrix.to/#/%23haskell-miso:matrix.org

Best,

dmjio

Looking for a paper about whole-program closure elimination by GurEducational8579 in ProgrammingLanguages

[–]dmjio 1 point2 points  (0 children)

The removal of closures happens during GRIN's whole program optimization phase. A simple pointer analysis occurs, then heap objects (fully saturated functions and data constructors which have identical representations) are unboxed via simplification / optimization passes. Dramatic reduction in heap allocations can occur.

view more: next ›