7
comments
on 3/5/2013 11:46 AM

It is time for some long-awaited improvements in WebSharper: Direct API and TypeScript cross-compiler.

Direct API

While working on the CloudSharper (WebSharper IDE) project, we strongly felt the need to have a more flexible way to call into WebSharper, to have the compiler as a service. In particular, we wanted it to be able to compile code on the fly inside an FSI session, including parsing FSI-defined dynamic assemblies. While very reasonable in retrospect, this requirement was not on the table in the original design, and we had to put in quite a few changes to make it work. The good news is that it is working, and you can even compile F# to JavaScript inside an FSI session. The changes are already published in our official WebSharper repository, in particular see FrontEnd.fsi. I am now finalizing some cleanup tasks and will soon release a NuGet package update incorporating the changes.

Direct API makes a few frequently requested scenarios much easier. For example, it is now a lot more straightforward to avoid reliance on ASP.NET, to build more flexible tools, or to do things like targeting Node and a pure-JavaScript runtime.

TypeScript

In case you have not noticed, there is a new language from Microsoft called TypeScript. After working with deciphering its semantics for a bit, I am not a big fan of TypeScript design (this deserves another blog); but I will grant that it is a vast improvement on JavaScript. Moreover, TypeScript defines a standard way to describe JavaScript library interfaces, and people have started doing so en masse, see for example DefinitelyTyped. With the TypeScript cross-compiler tool we are trying to reuse all this work - and generate WebSharper FFI bindings based on TypeScript ".d.ts" files, using either a F# 3.0 TypeProvider or bulid-time API. A competing project, FunScript, has pioneered the approach.

TypeScript bindings are likely to be the future of WebSharper extensions story, even though the quality of the present TypeScript bindings strikes me as very poor. Well, so does the quality of TypeScript definition language. TypeScript does not, for instance, allow generics in the specifications, though they are considering to add them in the next release. Regardless, the reason that TypeScript bindings are exciting is social - due to excellent tooling and Microsoft backing TypeScript is picking up very quickly. There are already many more TS bindings than WebSharper bindings, and given the dynamic of its adoption, their quality is likely to improve quickly. We would like to ride the wave.

.

Does this mean that we can now write F# -> JS unit tests? What about building an OWIN host? I'd love to do this. Can you point out the specific API hooks?

By on 3/5/2013 6:45 PM ()

Thanks Ryan. The exact API is in FrontEnd.fsi, see the link above.

1. Can you elaborate on what you mean by F# -> JS unit tests? Sounds like it definitely should work; if you elaborate I will be happy to try building an example.

2. WebSharper is an umbrella term for many components. If you are just using the no-frills compiler to produce JS out of F# and you handle all things server-side yourself, then yes, with DirectAPI it should be relatively easy to do that on top of OWIN or anything else. Other components still need work. One is remoting host (responsible for executing [<Remote>]/[<Rpc>] methods. Another is sitelets - we will need to abstract a few things away before they can really be usable on OWIN (one other crazy idea was trying to make them usable on Node.js).

By on 3/5/2013 7:36 PM ()

Thanks Ryan. The exact API is in FrontEnd.fsi, see the link above.

1. Can you elaborate on what you mean by F# -> JS unit tests? Sounds like it definitely should work; if you elaborate I will be happy to try building an example.

2. WebSharper is an umbrella term for many components. If you are just using the no-frills compiler to produce JS out of F# and you handle all things server-side yourself, then yes, with DirectAPI it should be relatively easy to do that on top of OWIN or anything else. Other components still need work. One is remoting host (responsible for executing [<Remote>]/[<Rpc>] methods. Another is sitelets - we will need to abstract a few things away before they can really be usable on OWIN (one other crazy idea was trying to make them usable on Node.js).

By on 3/5/2013 7:36 PM ()

As to 1, I had asked a few years ago about writing unit tests that could compile and run along side the WebSharper functions. At the time, I was thinking of doing this before compiling to JS, as I didn't understand the mechanics properly. However, it seems that we should be able to either wrap qunit or jasmine or even write a custom test engine and compile to JS alongside the generated application scripts. Quite possibly, that was available in the previous versions of WebSharper, as well.

By on 3/6/2013 6:02 PM ()

Do you mean simply doing unit tests in JavaScript, something like below? WebSharper has been using a thin wrapper around QUnit for testing things:

[link:bitbucket.org]

Or is there something more to it? Thanks.

By on 3/6/2013 6:26 PM ()

If you can make it run on OWIN, you can kill two birds with one stone: [link:tomasz.janczuk.org] Thanks for reference. I didn't follow the link previously because it didn't look like it had to do with the back end. :)

By on 3/6/2013 5:58 PM ()

Wow, looks interesting. Did not realize you could do that with Node. OWIN definitely is a good idea - to introduce some loose coupling.

By on 3/6/2013 6:24 PM ()
IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy
Built with WebSharper