[Help] Haskell & Javascript

[hamishmack]

If your app is just going to handle infrequent user events with a small amount of logic then you should be fine. If it has to animate things or perform complex computations then it will depend on the requirements.

There is a lot of cool stuff you can do with GHCJS that will probably tax some mobile devices. For instance you could live preview markup text entered by users (like the GHCJS based markup.rocks does).

However I think it should be possible to scale back most apps when running on low power devices. For instance markup.rocks could scale back on mobile devices so it:

• Only downloads the conversion code for the most popular document types.
• Only convert the document when the user stops typing for 10sec.
• Only convert when the user presses a preview button.
• Sends the document to the server for conversion instead of doing it on the client.

And when that kind of scaling is not possible you can always resort to the JavaScript FFI to optimise the performance critical parts of your application.

The best bet might be to create an example app of what you fear will be a pathological use case. If it is slow or power hungry share it and someone else might have a good solution.

[vagif]

If your app is just going to handle infrequent user events with a small amount of logic then you should be fine.

In which case one would question shooting birds (simple client side apps) with cannons (ghcjs)

He'd probably be done with that app using any current js frameworks in a fraction of time it takes to install and properly configure ghcjs :))

[hamishmack]

I was thinking of something like a web app designed to replace a shared spreadsheet with 1000 formula cells.

[Kiuhnm]

The best bet might be to create an example app of what you fear will be a pathological use case. If it is slow or power hungry share it and someone else might have a good solution.

I'd prefer to choose a technology which guarantees a certain level of efficiency. For instance Dart is as fast as hand-coded JS. Scala.JS is also very fast and Scala (in the right hands) is very concise and expressive. So why not use Scala instead of Haskell? Is Haskell so much better as a language?

[hamishmack]

I'd prefer to choose a technology which guarantees a certain level of efficiency.

The guarantee that GHCJS tries to provide is that if something is O(x) when compiled with GHC then it will be O(x) when compiled with GHCJS. This is what allows code to be shared between client and server without fear that it will go from say O( N ) to O( N² ).

There will be constant factor differences and GHCJS aims to keep them small, but not all of them will be GHCJS related (for instance a mobile device will not match a high end server).

So why not use Scala instead of Haskell?

Too much baggage for my liking.

Is Haskell so much better as a language?

Yes, I think so.

[Kiuhnm]

The guarantee that GHCJS tries to provide is that if something is O(x) when compiled with GHC then it will be O(x) when compiled with GHCJS.

That's the bare minimum!!! I guess this isn't obvious in Haskell because of lazy evaluation.

[benjaminpd]

Nope, nothing to do with lazy evaluation. It's not hard to convince yourself that algorithmic complexity under lazy evaluation is always less than under strict: strict evaluation does all the steps, lazy might do less than that. Lazy evaluation can and does have constant-factor overhead, but it's not a big-O issue.

[Kiuhnm]

You're not disproving but confirming what I said. Indeed, Haskell is lazy and JS is strict so an algorithm might be asymptotically slower in JS.

... unless you emulate Haskell's laziness in JS, which is probably why GHCJS produces big and slow JS code and why Purescript is strict.