
Compile OCaml to JavaScript, Run on Node - antouank
http://hyegar.com/blog/2015/11/05/write-ocaml,-run-on-nodejs/
======
murbard2
You can also run eliom
([http://ocsigen.org/eliom/](http://ocsigen.org/eliom/)) which offers reactive
DOM elements. Not as seamless as Meteor, but you get something pretty close
with the benefits of type safety, down to the HTML you generate.

~~~
Drup
As someone working on eliom, I would really like to hear you on the areas
where we can improve seamless-ness. :)

~~~
murbard2
To be honest, I haven't used it seriously enough to give you the good answer
this deserves.

A friend of mine evaluated it for his own need and went with Meteor citing
that reason (plus ease of hiring for js). I've gotten a similar feel looking
at the code samples.

Take for example this basic example:

    
    
       {server{
    
         let get_data_forum forumid =
           lwt messages = Db.get_messages forumid in
           let default = {'a option{
             try Some (Eliom_cscache.find_if_ready %forumcache %forumid)
             with _ -> None
           }}
           in
           Lwt.return (SharedReactiveData.RList.make ~default messages)
    
         let get_data_forum_rpc =
           server_function Json.t<int>
             (Eba_session.Opt.connected_rpc
               (fun userid_o forumid -> get_data_forum forumid))
    
       }}
       {client{
    
          let get_data_forum forumid = %get_data_forum_rpc forumid
    
       }}
    

This feels awfully verbose for what it does...

------
hbbio
Glad to see OCaml gaining steam. This is quite close to another project
written in OCaml: Opa ( [http://opalang.org](http://opalang.org) ).

Opa differs in that it is a new language though, but the compiler is written
in OCaml and compiles the Opa language to JavaScript (using by default Node.js
and MongoDB).

Compared to this project, Opa provides much more automation (ORM except it's
neither Object nor Relational, slicing i.e. separation of client and server
code, etc.).

Disclaimer: I'm the creator of Opa.

~~~
Drup
It's a bad comparison though. The real equivalent of opa in the OCaml
ecosystem is eliom. :)

(Also, isn't opa a bit, you know, dead ?)

~~~
hbbio
Opa is as dead as a project we use daily.

~~~
zem
good to hear!

------
r-cyr
What I REALLY want to know is... can it run "flow"
([https://github.com/facebook/flow](https://github.com/facebook/flow)).
Because it's very useful yet painful to install... And I don't even know if it
works on Windows.

~~~
tel
For some reason I remember there being a web version of flow that was being
compiled through js_of_ocaml. Maybe I'm confusing this with another project,
though.

~~~
e_d_g_a_r
I'm pretty sure the parser could be compiled with js_of_ocaml, but not sure if
everything can be. Would need to look...

------
tdurden
The amount of "compile to JavaScript" tools is impressive

[https://github.com/jashkenas/coffeescript/wiki/list-of-
langu...](https://github.com/jashkenas/coffeescript/wiki/list-of-languages-
that-compile-to-js)

------
mjt0229
The comments on the blog post are hilarious to me.

"And why do you need type safety? Because you are used to?"

Er. Well, if you _like_ driving a car with no seatbelts, crumple zone, or
airbags, I guess that's fine with me. But when I get in a car, I buckle up.

~~~
kod
That's a somewhat poor analogy, since airbags etc don't prevent you from doing
certain driving maneuvers.

Static type systems prevent you from expressing certain programs (I think this
is a good thing, but not everyone does).

A better analogy would be antilock brakes or understeer - safer but prevents
you from doing certain things.

~~~
to3m
A better analogy would be driving a car - it's not a tangerine.

