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.