Upcoming WebSharper Changes

Anton Tayanovskyy

Anton Tayanovskyy

Mar 05, 2013

Reading time:

3 mins

Share via:

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 repository1, in particular see FrontEnd.fsi2. 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.


  1. This link has been updated to point to new location.

  2. This link has been updated to point to new location.

Read more from

Can’t find what you were looking for? Drop us a line.

Anton Tayanovskyy
Found a typo?

This blog post is hosted on GitHub here. Feel free to file a ticket or send a PR.

Newsletter

We will not spam you or give your details to anyone.