dmjio

Added React-style web components.

Yes, miso uses the JS backend in GHC, and mobile phones have embedded JS interpreters (e.g. JavaScript Core). These interpreters can access native libraries to draw native views, or access native device APIs.

Projects like lynx and react-native automate this process using something akin to node-gyp, exposing kotlin / swift libraries via C ABI w/ a JS API. Miso accesses the kotlin / swift native modules by FFI'ing into the JS that exposes them.

The JS doesn't get compiled, but on Android it does get JIT'd. So it's "native" in the sense that the views drawn are native (not WebViews), and the device APIs are native, but not "native" in the sense that it's compiled.

https://github.com/dmjio/miso-lynx

Building native applications for iOS, Android and Huawei devices in Haskell.

Yes we do.

https://github.com/haskell-miso

I'm working on miso-lynx

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

It's a way to build truly native iOS, Android and HarmonyOS applications in Haskell using https://lynxjs.org and https://github.com/dmjio/miso, it uses a similar approach to react-native.

This project is an integration between https://lynxJS.org and the Haskell miso web framework (https://github.com/dmjio/miso).

Miso has hydration w/ a global event event handler.

https://haskell-miso.org/

Haskell will accept you !

https://haskell-miso.org/

Would you be able to share more details as to what caused this bad experience? My experience with GHCJS on a big project has been the opposite.

There is a company that has a 400 module miso application and the bundle size is not an issue (https://www.polimorphic.com). After closure compilation GZIP'ing, pre-rendering and caching of the JS, it's a one-time cost, and is negligible due to pre-rendering. We build websites for users, who care only about experience, not about how large the payload is. Payload only matters insomuch as it adversely affects user experience. This argument is strictly a developer concern and is in no way correlated with end-user feedback. There are many <1MB js payload size websites with 0 users.

This post dismisses Elm on the basis of lack of typeclasses, but fails to mention miso (https://haskell-miso.org), that includes typeclasses. Miso is Elm-as-an-embedded-DSL written as a Haskell library for GHCJS that allows one to share types on the front and backend, take advantage of the entire Haskell ecosystem and has experienced commercial use.

A few companies have used this (https://haskell-miso.org/) to make useful software w/ Haskell.

Rewriting Elm in Haskell.

[0] Project Homepage: https://haskell-miso.org

[1] Github: https://github.com/haskell-miso/miso

If decoding json in Elm is considered hard, I'd recommend checking out miso (https://github.com/dmjio/miso), a Haskell re-implementation of the Elm arch. It has access to mature json libraries like aeson for that sort of thing, along with mature lens libraries for updating your model. Here's an example of decoding json with GHC.Generics using typeclasses. https://github.com/dmjio/miso/blob/master/examples/xhr/Main....

If you want a powerful type system (i.e. Haskell), but the benefits of Elm, Miso is a project that implements the Elm Architecture in Haskell. It obviously has typeclasses, and can encode / decode JSON on the frontend using GHC.Generics quite well. https://github.com/dmjio/miso

You do excellent work sir. Use bulma /a lot/.

Project: https://haskell-miso.org, https://github.com/dmjio/miso

Synopsis: Elm arch. in Haskell, but supports isomorphic js

Show HN link: https://news.ycombinator.com/item?id=14685677

Status: Still kickin', ~17k views, top 15 repo globally on GH (for a day)

Agreed, could have chosen a better title.

Couldn't agree more.

Why thank you kind sir :) Using advanced optimizations with google's closure-compiler, the todo-mvc example can get down to 500kb. Compressed it might even be smaller. This is why having the "isomorphic" part is important. This way the user will see content immediately while the app bootstraps in the background and sets up event delegation. Then events will get routed through the vdom to pure haskell functions and the app is responsive again.

The choice of using Haskell was due primarily to 3 things.

1) Code reuse - The ability to share types on both client and server.

2) Hackage - by using Haskell you have access to 90% of Hackage on the frontend (this means nice lens and json libraries).

3) Types - Haskell's type system can express higher-kinded and poly-kinded types (something which Elm cannot afaik), this gives the user flexibility, expressivity and safety.

The code is quite performant, but for the fast stuff miso FFIs into hand-written js.

In regards to output size, the generated js can be very large. But, the generated code is in a state where it can use the closure compiler's ADVANCED optimizations. That combined with caching the rts.js and gzipping, you can probably get down to a few hundred kbs (which is large by a lot of people's standards), but workable

This is fantastic feedback, better documentation is the next step so I'll be sure to include a comparison section between the two.

Ah, my bad, I wasn't aware someone else submitted it, what was the question? Would be happy to talk about it.

yea... that's another issue to add

The RFC says all JSON text must be an array or object, null is a value. JSON text is made up of JSON values.

per the RFC,

"JSON can represent four primitive types (strings, numbers, booleans, and null) and two structured types (objects and arrays)."

"An object is an unordered collection of zero or more name/value pairs, where a name is a string and a value is a string, number, boolean, null, object, or array."

We'll all be programming in Haskell soon enough

Allen, think it's time to switch to emacs ;)

If you put $0.00 as the amount it changes the button text to say "add card"

To show that haskell and C can achieve equivalent performance on certain numeric calculations.

I believe it is called stream-fusion. The intermediate data-structures are optimized away (since they're unboxed), allowing for faster operations.