By Loïc Denuzière on Tuesday, January 13, 2015 — 0 comments

CloudSharper 0.9.26 released Core team

In this new release of CloudSharper, we added a new HTTP API that allows you to create a workspace in a single click. For example, if you are the owner of an F# library, you can add a "Try in CloudSharper" link to your website which will direct the users to CloudSharper and create a project including the source files and NuGet packages that you specified. Here are some more details about the API. Sharing has never been easier!

We also updated the API references available in the Documentation panel or by pressing F1 on an autocomplete item.

Happy coding!

By Loïc Denuzière on Friday, January 9, 2015 — 0 comments

CloudSharper 0.9.25 released Core team

We just released a new version of CloudSharper alpha, 0.9.25. This version updates the CloudSharper interface and the project templates to the latest version of WebSharper 3.0.

You can of course keep working on projects using older versions of WebSharper. If you want to update your projects, simply update the NuGet packages for WebSharper and any extensions you are using, and follow this guide to upgrade your code.

Happy coding!

By Loïc Denuzière on Thursday, January 8, 2015 — 1 comment

WebSharper 3.0.8-alpha published Core team

As we advance closer to the stable release of WebSharper 3.0, more and more of the breaking changes we have wanted to implement for a long time are coming out. The main theme of the just-released version 3.0.8-alpha is naming conventions streamlining. With these changes, WebSharper should be more intuitive to use than ever. The changes necessary to update an existing project are fairly simple and detailed in the comprehensive guide below.

Naming changes

In names below, IF is short for IntelliFactory and IFWS for IntelliFactory.WebSharper.

JavaScript standard library

Until now, the JavaScript standard library was split into a number of namespaces and modules, making it sometimes difficult to find where something was. The new namespace IFWS.JavaScript is now the home of everything built in the browser, whether it's basic language constructs, DOM, HTML5, etc.

The general rule is:
If a module contains client-side code, you should open IntelliFactory.WebSharper.JavaScript.
If it only contains server-side code, you should not.

For the purpose of the above rule, WIG definitions ("Extension" projects) are not considered client-side code, since they are run during compilation to generate inlines. In fact, it is important not to open IFWS.JavaScript in a WIG definition because of a conflict on the (?) operator.

In more detail:

  • IFWS.EcmaScript and IFWS.Html5 are removed and all types defined under them are now under IFWS.JavaScript. The module IFWS.EcmaScript.Global is merged with the old IFWS.JavaScript and renamed to IFWS.JavaScript.JS. A few HTML5 items have also been cleaned up, and more will certainly come in the future. For example, code that used to read:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    
    open IntelliFactory.WebSharper
    
    let a = EcmaScript.Date.Now()
    let b = new Html5.Float32Array()
    let c = Global.NaN
    let d = JavaScript.Undefined
    let e : EcmaScript.WebGLRenderingContext = (* ... *)
    let f : Html5.Position = (* ... *)
    JavaScript.Log "Some text on the console"

    now reads:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    
    open IntelliFactory.WebSharper
    open IntelliFactory.WebSharper.JavaScript
    
    let a = Date.Now()
    let b = new Float32Array()
    let c = JS.NaN
    let d = JS.Undefined
    let e : WebGL.RenderingContext = (* ... *)
    let f : Geolocation.Position = (* ... *)
    Console.Log "Some text on the console"

    JS now basically contains all top-level values and language constructs defined in JavaScript. This includes JS.Window and JS.Document, which obsolete Html5.Window.Self and Dom.Document.Current, respectively.

  • IFWS.Dom is renamed to IFWS.JavaScript.Dom.
  • The auto-opened IFWS.Pervasives is split in two:

    • IFWS.Pervasives contains definitions useful for both client-side and server-side code, such as attributes ([<JavaScript>], [<Inline>], [<Rpc>], etc).
    • IFWS.JavaScript.Pervasives contains client-side definitions, such as:

      1
      2
      3
      4
      5
      6
      7
      8
      
      open IntelliFactory.WebSharper.JavaScript
      
      // notation for plain JavaScript object creation
      let g = New ["x" => 12; "y" => 14]
      // plain JavaScript field access
      let h = e?x
      // "dotted" operators, inlined to the corresponding JavaScript operator
      if g ===. h then ()

HTML combinators

  • The namespaces IF.Html and IFWS.Html have been a constant source of confusion for beginners. In WebSharper 3.0.8, they have been renamed to IFWS.Html.Server and IFWS.Html.Client, respectively. Hopefully this should make it more obvious when one or the other is needed.
  • Tag and attribute combinators that were previously under a HTML5 module are now grouped back together with the "normal" ones. We judged that it doesn't make sense to separate them out anymore.
  • The type IF.Html.Element<'T> was originally intended to allow embedding various types of client-side controls. But ultimately, only Web.Control has ever been used for this purpose. Therefore, we made the corresponding new IFWS.Html.Server.Element and all associated types (such as INode and Attribute) non-parametric.

Formlets

The following namespaces have been renamed for consistency with Sitelets and Piglets:

  • IF.Formlet --> IF.Formlets
  • IFWS.Formlet --> IFWS.Formlets
  • IFWS.Formlet.JQueryUI --> IFWS.Formlets.JQueryUI (extension)
  • IFWS.Formlet.TinyMce --> IFWS.Formlets.TinyMce (extension)

The NuGet package WebSharper.Formlet.JQueryUI has also been renamed to WebSharper.Formlets.JQueryUI.

Functionality changes

Web.Control and HTML type hierarchy

In preparation for an upcoming tighter integration of UI.Next, we changed the behavior of Web.Control. Namely, the Body property doesn't have the type IPagelet anymore, but a new interface IControlBody that is implemented by pagelets and will be soon implemented by UI.Next Docs. As a consequence:

  • The interface IPagelet is replaced by an abstract class Pagelet, which implements IControlBody appropriately.
  • The Body property of Html.Client.Elements now has type Dom.Node instead of Dom.Element. Some methods (such as JQuery.Append) require a Dom.Element; in this case, replace .Body with .Dom:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    
    // old code
    open IntelliFactory.WebSharper.Html
    open IntelliFactory.WebSharper.JQuery
    
    let e = Div [Text "some content"]
    JQuery.Of("#myElt").Append(e.Body).Ignore
    
    // new code
    open IntelliFactory.WebSharper.Html.Client
    open IntelliFactory.WebSharper.JQuery
    
    let e = Div [Text "some content"]
    JQuery.Of("#myElt").Append(e.Dom).Ignore

Assembly referencing

This one gets a bit more technical and is related to the WebSharper build process. WebSharper contains a custom MSBuild task written in F#, which is in charge of compiling code to JavaScript and extracting the compiled JavaScript code into a web project, among other things. Until now, this task was also in charge of adding all the WebSharper assembly references to the project just before running the F# compiler. This had several unfortunate consequences: the solution explorer in Visual Studio did not show the WebSharper references, and in some cases on Mono (such as when compiling a full solution in CloudSharper), XBuild would fail to add the references correctly. In this new release, we switched to a more conventional scheme where references are added to the project file itself by nuget install. This more standard behavior should harbor fewer opportunities for problems.

Conclusion

Phew, that was a long one! Overall these changes are fairly simple to apply to an existing project, and we are confident that they remove a number of idiosyncrasies that hinder the learning of WebSharper for beginners.

If you encounter any problems porting a project to the latest WebSharper, don't hesitate to tell us on the issue tracker. Happy coding!

By Loïc Denuzière on Tuesday, December 16, 2014 — 0 comments

CloudSharper 0.9.23 released Core team

It's been a few weeks since our previous release, and finally CloudSharper 0.9.23 is here.

The highlight of this release is the update to WebSharper 3.0.3 alpha. This update concerns:

  • The cloudsharper.com interface itself;
  • The CloudSharper Local Services component;
  • The project templates available inside CloudSharper.

Of course, it is still possible to work on WebSharper 2.5 projects within CloudSharper. Note however that if you want to run a 2.5 sitelets application ("Client-Server WebApplication") from inside CloudSharper, you need to add the following to your web project's Web.config file:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
       <dependentAssembly>
        <assemblyIdentity name="IntelliFactory.WebSharper.Sitelets"
                          publicKeyToken="dcd983dec8f76a71" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="2.5.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="IntelliFactory.WebSharper.Core"
                          publicKeyToken="dcd983dec8f76a71" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="2.5.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>

Happy coding!

By András Jankó on Tuesday, December 16, 2014 — 0 comments

WebSharper 3.0.3-alpha released Core team

This is our first release of WebSharper 3.0-alpha with a new feature: source mapping. If you enable it on your project, you can see the F# sources in your browser and set breakpoints in it.

Source maps

  • You can enable including source maps and the required source files in a WebSharper assembly, by adding the

    1
    
        <WebSharperSourceMap>True</WebSharperSourceMap>

    property to your project file.

  • To unpack the source maps in your web project, add this same property to the project file, and

    1
    2
    3
    
        <staticContent>
          <mimeMap fileExtension=".fs" mimeType="text/plain" />
        </staticContent>

    inside the web.config file's <system.webServer> element.

  • It is also recommended to set

    1
    
        <OtherFlags>--quotations-debug</OtherFlags>

    to have source position information inside reflected definitions available for WebSharper. Otherwise only the starting lines of functions can be mapped.

  • Single-Page Application projects are currently not supported.
  • In Google Chrome, you need to check the "Enable JavaScript source maps" setting in Developer Tools Settings.
  • For Internet Explorer, you need to have Windows 8.1 Update 1.
  • websharper.exe also has new flag -sm for source map embedding/unpacking.

Sitelets improvements

  • We added combinators to simplify writing Sitelets for sub-actions and embedding them into Sitelets for wider actions. See issue #307 for more details about these combinators.

WIG improvements

  • Added ObsoleteWithMessage function, with it you can specify a message for the obsolete warning.
By Loïc Denuzière on Monday, December 8, 2014 — 0 comments

News from WebSharper 3.0: NuGet, Visual Studio, Mono, upcoming features and API changes Core team

The community response to the WebSharper 3.0 announcement has been overwhelmingly positive. Thanks to everyone who keeps spreading the word! Here are some news from the front:

  • WebSharper 3.0.1.73-alpha just hit the NuGet repository, together with all the public extensions. Don't forget the -pre flag when running NuGet update, since they are marked as alpha.
  • We also uploaded the first version 3.0 of the Visual Studio extension, together with a few updates to the WebSharper website.
  • Thanks to some updates to IntelliFactory.Build and WebSharper itself, WebSharper 3.0 can now be built from source on Mono. Don't hesitate to try it out and report any issues you might encounter!
  • Work has also started on some API enhancements and simplifications and some new features:

    • We are implementing JavaScript source maps. This feature will allow you to see the original F# code in your browser's debug window, for a much better runtime debugging experience.
    • We are working on enhancing the foreign function interface, in particular regarding higher-order functions. Such functions are currently wrapped at the language interface in a helper that can take arguments either separately (for JavaScript calls) or as a tuple (JavaScript array, for F# calls); but this causes problems eg. with functions taking a single array as argument. We are still exploring solutions.
    • The branch js-stdlib-merge contains a simplification of the bindings for the standard JavaScript library. The gist of it is that everything that is built in the browser is currently spread between no less than five namespaces and modules; this change moves all of it into IntelliFactory.WebSharper.JavaScript. More detail in this commit message.
    • We are looking to rename the namespaces IntelliFactory.Html and IntelliFactory.WebSharper.Html to something more explicit. Many developers have been confused by this naming because the difference is not obvious: the former is for server-side markup, while the latter is for client-side markup. The server-side markup will probably be renamed to IntelliFactory.WebSharper.Sitelets.Html; we haven't yet decided a name for the client-side markup.
    • More enhancements will be coming; we hope to have the bulk of the breaking changes in before the end of the year.

Happy coding!

By Loïc Denuzière on Saturday, December 6, 2014 — 0 comments

WebSharper migration to GitHub complete! Core team

When we announced WebSharper 3.0 on Wednesday, we also mentioned that we would be migrating from BitBucket to GitHub. Well, this is now done!

Here is the new main repository for WebSharper. All tickets from the BitBucket tracker have also been migrated (apologies to everyone whose mailbox has been spammed by this!), and are available at this address. Finally, public extensions have been transferred too (for those that weren't already GitHub-based), and are listed under the IntelliFactory organization.

We eagerly await your suggestions, bug reports and pull requests on our new repositories!

By Adam Granicz on Wednesday, December 3, 2014 — 6 comments

WebSharper 3 alpha now under Apache 2 Core team

We are super excited to announce that as of the very latest 3.0-alpha commit, WebSharper is now available under the Apache 2.0 license, free of charge to anyone, for both closed and open source applications!

Over the years, WebSharper grew from an experiment in F# web development into a mature, enterprise-grade F# web framework and helped a multitude of organizations benefit from its type-safe, functional constructs and its powerful F# to JavaScript translation engine. From early on in its development, our main focus was establishing sound abstractions around common web patterns and chores, from simple representations of client-side content, through type-safe, composable, declarative ways of specifying user interfaces, to representing even entire applications in the type system. Some of these abstractions are the result of years of hard work and research, and are distilled into peer-reviewed academic papers, a good set of online documentation and samples, and several book chapters, among others, and make WebSharper a truly innovative, robust, bleeding edge web framework for the serious enterprise web and mobile developer and also for the academically curious researcher.

It is this fundamental power, elegance of expression, and unparalleled productivity that in our humble opinion deserves more attention and widespread use, and this is a great motivation for us going Apache. We have grand and ambitious plans to take WebSharper to places we could never foresee before.

During the past few months and before, we received overwhelming community feedback confirming that there is an ever-growing need for going beyond ordinary web development and continuing to push the boundaries of robust functional web development with WebSharper. Community feedback also confirmed that we are now ready to take WebSharper to the next level and bring it to a much wider audience via a less restricted license.

What does this mean to existing users? First of all, existing license holders continue to be able to use the 2.X releases for closed source applications as before, and they are also welcome to update to the 3.0-alpha line at their convenience. We are now aiming to deliver a set of systematic API updates as part of the 3.X feature set, and many such changes will be breaking changes and new features. If, for whatever reason, you prefer to use the 2.X line, feel free to contact us for licensing. However, we recommend that new users start with the upcoming 3.X releases, despite possible API changes (flagged as pre-release or alpha for the time being, with our aim to deliver most of these changes by the end of this year).

At the same time of going Apache, we will also be offering dedicated support for WebSharper, a new level of service for enterprise users and groups. We will announce plans and related information on this blog shortly. Similarly, premium tooling built for enterprise ex-license holders will now be available on separate subscriptions, with existing license holders enjoying uninterrupted access.

Incidentally, today is also the birthday of one of our main WebSharper team members, Happy Birthday Loic! This is also a great time to say thanks to all those dozens of people who contributed to the development over the years – thanks everyone!

All in all, we can’t wait to hear how far WebSharper can take you in your web development efforts! These are exciting times for both F# +WebSharper and the entire community, and we hope you take this opportunity learn more about WebSharper and fall in love with it like we did.

And last - keep an eye on NuGet: the first set of 3.0-alpha binaries should arrive there tomorrow, and be sure to turn on the “Include pre-release” flag when updating.

Happy coding!

By András Jankó on Tuesday, December 2, 2014 — 0 comments

WebSharper 2.5.134 released Core team

A lot of useful functions of FSharp.Core are now translatable by WebSharper.

Async cancellation

  • Proxies for CancellationTokenSource, CancellationToken, CancellationTokenRegistration.
  • Proxies for Async class members: DefaultCancellationToken, CancelDefaultToken, CancellationToken, OnCancel, TryCancelled
  • Async RPC calls are cancellable, the cancel continuation runs ASAP and the response are discarded.

MailboxProcessor

  • Proxy handles timeout arguments and cancellation
  • PostAndReply/TryPostAndReply methods are not supported as JS is single-threaded.

Printf

  • Proxies for sprintf, printfn, failwithf, Printf.kbprintf
  • %O uses JavaScript String(x) function
  • %A generates a recursive pretty-printer for F# types if type information is available. Currently supports lists, unions, tuples, records, 1 and 2 dimensional arrays. Other types are sent to a dynamic pretty-printer.
  • printfn prints to JavaScript console
  • Printf.sprintf is not supported, use ExtraTopLevelOperators.sprintf instead.
  • Printing as unsigned is not supported.

Fixes

  • Fix #300: Server-side runtime error in some regional settings (for example Turkish)
  • Fix #304: Converting string to char checks string length now
  • Async.FromContinuations ensures that continuation is called only once, throws an error otherwise.

Breaking changes

  • System.Web.HttpPostedFile type in Sitelets API have been changed to System.Web.HttpPostedFileBase to enable non-ASP.NET hosting (OWIN).
  • Indexed properties in WIG: Previously if a property was defined with name "item", it translated to a an indexer on the object. This is changed so that the empty string is usable for this (still will get .NET property name Item, the default indexer for the class).
1
2
// generates default .NET indexer
"" =@ T<obj> |> Indexed T<int> // has JavaScript inline "$this[$index]"
By András Jankó on Monday, November 17, 2014 — 0 comments

CloudSharper 0.9.22.2 released Core team

This is a bugfix release with some additions for FSI.

Full changes:

  • #568: Do not send multiple commands to local service when using the "Retry" button on the dashboard screen.
  • Markdown documents with embedded F# code blocks show two buttons now. "Send to interactive" was renamed to "Run" and "Edit" just sends the contents to the Interactive input box without executing it.
  • DLL files have a "Reference in interactive" context menu which runs an #r command with that library.
  • "Find in solution explorer" context menu item on tab headers is only visible when the file has a node in solution view.

Happy coding!