Question

I've been looking at (mostly) functional languages that can convert to Javascript, and these two stand up top nowadays. But I have two doubts about them, (talking about ClojureScript and Pit for F#):

  • I suppose that, as both just translate the original language, the moment one makes a call to anything .Net or Java, the program can't directly compile to Javascript. Am I right with this? If so, in this case the ability to interact with the Java/.Net environments is "dangerous".
  • As far as I know ClojureScript can interact with any JS library out there (node.js, jquery, etc), whereas in Pit they are developing "extensions" to allow this... so I assume importing ANY js library is not supported. I read in SO that WebSharper does support this, but there isn't much evidence and is closed source. So, in practice, how is actually the state of any JS interaction from both languages?

Thanks a lot!

Was it helpful?

Solution

I'm not familiar with ClojureScript, but I can answer some of your questions about Pit (and WebSharper).

Calling .NET libraries
Pit only translates explicitly marked F# code, so when you call standard .NET library or some F# library that does not support Pit, it is not going to work (unlike Microsoft Live Labs Volta project, which is now dead).

However, you can re-implement any such library in F# and tell Pit to use that implementation instead - if the functionality is a part of standard F# library, you can even copy the source code from the open-source F# release. In practice, I don't think this is such a big issue, because most of the .NET libraries are specific to servers or desktops and so you probably won't need that many of them.

Calling JS libraries
Since F# is a statically typed language, it requires to know types of things that you're working with. In Pit and WebSharper, these are obtained by defining F# types (with no implementation) that then get mapped to JavaScript. In Pit, these have to be written by hand, although my guess is that in F# 3.0, this could be done automatically using F# type providers. I believe WebSharper has a tool for that, but it is only available as part of the commercial release.

OTHER TIPS

Interop with JavaScript is not a problem in WebSharper. We ship a lot of bindings to existing JS libraries, and if any functionality is missing, you can recover it fairly quickly in F# with code like this:

[<Direct "jQuery($x).hide()">]
let hide (x: obj) = ()

The challenge in F# is type safety - how much type safety and precise code completion are you willing to retrofit on top of the untyped (and often untypeable!) JavaScript libraries. I never used ClojureScript, but I imagine this is not even a question there since Clojure is untyped as well.

Interop with the underlying .NET platform is indeed "dangerous". As Tomas points out, WebSharper requires that all JavaScript-callable functions are annotated. We have worked around this limitations for some standard classes (strings, collections such as dictionaries, maps and sets), but the support is far from complete.

With WebSharper you can run .NET code on the server and use it via AJAX fairly transparently:

[<Remote>]
let add (x: int) (y: int) = async.Return(x + y)

[<JavaScript>]
let remoteAdd () =
    async {
        let! sum = add 1 2
        return JavaScript.Log("RESULT", sum)
    }
    |> Async.Start

Unfortunately, if you do have to run large .NET libraries on the client this is not a solution, and you probably have to look in the direction of Silverlight instead.

Disclaimer - I am developing WebSharper, so my input is obviously biased. That being said, when choosing between WebSharper and Pit, bear in mind that WebSharper has active development, support, and has been used on real projects. Since we used it in larger projects, we had to take care with optimizing output code and working around some limitations and bugs in the F# reflection model, even rewriting F# metadata reader for our purpose. This means I can take dozens of closed issues from WebSharper tracker and re-discover them as Pit issues. I do not, for humanity would be ill served by such duplication of effort.

I think ClojureScript is better fit. It has same dynamic nature like JavaScript and it may use Google Closure Compiler for output optimisation. It it designed to run on JS VMs.

There are few differences from Clojure.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top