Hacker News Reader

It sounds like you have a very language-centric view of the world. In practice, deployment is everything. (Why do people write code in Objective C? Because iPhone.)

Having a solid implementation for your target platform is very good reason to pick a language.

> It sounds like you have a very language-centric view of the world.

> Having a solid implementation for your target platform is very good reason to pick a language.

I'm not sure where you got that out of my comment; it was exactly the opposite.

My point was that neither OCaml nor Haskell have particularly strong implementations in this area (to my knowledge). Last time I checked, the ability to write Javascript using both languages was of experimental and/or novelty use only (hence the "cupholders").

And that still doesn't change the fact that a web app can be written in any language - the only part that needs to run in Javascript is the client-side. Depending on how you architect your app, this may not be much at all. (There are very few webapps that actually need much logic in Javascript - if you want to avoid JS[0] while writing complex webapps, it's actually very easy to do so in many cases.)

[0] or anything else that is translated into JS

> Last time I checked, the ability to write Javascript using both languages was of experimental and/or novelty use only (hence the "cupholders").

Facebook uses an OCaml js_of_ocaml-based frontend for a large chunk of their production code editing. Not a great video, but here's the CUFP 2013 talk on the topic: http://www.youtube.com/watch?v=gKWNjFagR9k

Haste is a strong, useful, and impressively complete Haskell to JS compiler.

Fay is used in production apps as well.

PureScript is less mature still but pretty nice.

I looked at Haskell options - fay and haste are both good, but not complete (try compiling tagsoup). GHCJS works, but generates 5mb JavaScript files.

This is what I meant when I said "by virtue of support for existing libraries". js_of_ocaml translates compiled bytecode and can therefore make any pure OCaml library work in JavaScript without recompilation.

Okay, sounds like a misunderstanding about what "web app" means. Sorry about that!

I think of a web app as the client side alone, which can be quite a substantial amount of code with something like GMail or Google Maps. Of course on the server side, you can make a mostly-independent choice of language, RPC mechanisms aside. But for the client side, I'd choose a language based on how well it compiles to JavaScript and can use browser API's and JavaScript libraries.

I don't know whether OCaml is ahead of Haskell in this space. I've tinkered with Elm a little bit.

>My point was that neither OCaml nor Haskell have particularly strong implementations in this area (to my knowledge)

They both do.

Car metaphors don't always match well with the situations they try to illustrate. Obviously if you had the chance to be offered either one of these two cars, you'd probably try them out and pick the one you feel the most comfortable with, but also which would best fit your needs. If all other factors have been weighted, and it boils down to the number of cup holders, would you stop there short of making a choice, because of the apparent superficiality of the argument? The author expressed his interest in both languages, and brought other arguments than just the js one.

js_of_ocaml has excellent DOM bindings: http://ocsigen.org/js_of_ocaml/api/index

I'm also looking at whether TyXML can be used with js_of_ocaml for statically typed goodness: http://ocsigen.org/tyxml/

BMW has legendarily terrible cup holders, by the way.

See, from what I took from the article, is that maybe it would make for a really solid client side web application language. On the other end of this, i feel like server side languages are moving more into the direction of multi-core support, i.e. Rust, Golang, Erlang... oCamel could fit nicely as a client-side web application language for DOM manipulation, like ClojureScript -- at least that's my take on it, but it really couldn't compete with the newer multi-core languages -- speedwise.

It does seem a little spurious at first, but part of the argument is that as js apps get larger, a static, functional language can be argued for to avoid problems with larger js codebases.

What's weirder about this is Haskellers have no problems using Fay, PureScript, and Haste for JavaScript.

I write all my javascript in haskell, and haven't had any problems. What do you need/want "DOM bindings" for?

As someone who would like to write his javascript in Haskell, how do you put text on the page without interfacing with the browser's DOM?

Is that a trick question? I don't know how or why you would try to do that.

You do it all the time in web apps. For example, changing the text of a toggle link between "show" and "hide." For example, with jQuery:

  $('#toggleLink').click(function() {
    if ($('#toggleLink').html() == 'Show') {
      showRollout();
      $('#toggleLink').html('Hide');
    } else {
      hideRollout();
      $('#toggleLink').html('Show');
    ]
  });

I think you misread something. He asked how to do it without manipulating the DOM.

I assure you that it's not a trick question, just a poorly worded one.

Imagine that I'm making a page that converts meters to millimeters. The obvious part of the haskell code is

convert :: Double -> Double convert = 1000 *

The part which isn't obvious to me is how I get input from the user or display the result. I know how to do that in the IO monad through standard haskell, but I wouldn't know how to handle it in Haskell compile to javascript for the web browser. I would have thought that you would need a binding to the DOM to read from forms and the like.

I think fay uses its own FFI, but with haste you just use the normal FFI to call normal javascript functions the same way you would interface with C code from haskell. There's no need for special bindings or anything. You could certainly make a wrapper for jquery if you were crazy (and I'm sure someone has already done so), but this idea that you need some special DOM library to do things that javascript already does out of the box is kinda odd.

Thanks for the clarification. The key part that I was missing was the FFI. I'd encountered projects like this in the past with either no FFI or no documentation for the FFI and I couldn't figure out how to talk to the DOM. I'm more than happy to drop down to javascript for those parts, but I wasn't sure that I'd have the option.

http://elm-lang.org/ for example. To display text in the browser you would use -

main = plainText "Hello, World!"

From the page: "Elm is a functional language that compiles to HTML, CSS, and JavaScript".

So yes, technically this is working with the DOM. But you are not writing code that interacts with a "DOM binding" directly per se.

I'm excited for PureScript for the property that it compiles to sane javascript.

http://purescript.readthedocs.org/en/latest/intro.html#hello...

Awesome, had not heard of this project before! Thanks for sharing.

I've played with Elm for a toy project before and I do have high hopes for it. I also think it's the greatest monad tutorial ever - you don't truly miss them until they're gone.

(To clarify: At the time that I last used Elm, the Signal type was a functor, but was intentionally being kept from being a monad for design reasons. Working around this restriction tought me a lot on why I needed monads.

I didn't really understand applicative functors until I was playing with Elm. Working with Signals was pretty fun, and when I found out they were applicative functors, it was like a light bulb going off above my head.

Elm is a really fun way to start exploring purely functional programming.

I'm curious about this as well so I did some searching.

Fay[1], a subset of Haskell that compiles to JavaScript, seems to be the primary choice. There are DOM and jquery bindings for it and this blog post[2] looks like a great introduction.

There are other options, this [3] article outlines a number of them as a greater overview of both server and client side programming with Haskell. I also found an intriguing article [4] on the Haskell site but it appears to be out of date, referencing libraries that are no longer in development.

[1]https://github.com/faylang/fay/wiki

[2]http://ocharles.org.uk/blog/posts/2013-12-23-24-days-of-hack...

[3]http://www.stephendiehl.com/posts/haskell_web.html

[4]http://www.haskell.org/haskellwiki/Haskell_in_web_browser