Full stack of `WebSharper.4.0-rc` packages are now available on NuGet.
Fixes for tail recursion optimizations, lighter representation of F# unions/records with no extra members
WebSharper 4 beta-6 contains updates to DOM and JQuery bindings, erased union types, JS output optimizations and fixes
One of the most fundamental design considerations any developer must deal with is handling change. In this article, we are primarily concerned with client-side state and changes to it. Change can be brought about by various external factors (user input such as mouse or keyboard events, server push messages, etc.) or by means internal to the application itself.
We started work on WebSharper 4 more than a year ago, open-sourced it in May and published first beta packages in August. It is a project with a big scope and still some features are planned before we would call it stable. This article is an introduction and also a status report.
Introducing new and improved WebSharper 4 beta features for RPCs: customizing both client and server side.
A while ago we rolled out a new UI for Try WebSharper, essentially changing it into a snappy single-page application (SPA). Among others, you can now switch between trying out various snippets and making your own without any noticable delay, no more annoying page refreshes. [more..]
This is a minor release with bug fixes and updates for dependent libraries.
Just over a year ago, last year in December we released WebSharper 3 on Apache, putting it into the hands of every F# web developer. One thing we learned from WebSharper 2 is that more frequent releases are better and this year kept the whole team busy with constant innovation and new releases. Below is a list I cherry-picked from the WebSharper blog.. [more]
This release adds a small client-side cookies library, a function to require resources in client-side markup, and various bug fixes.
We released WebSharper 3.6 which allows you to automatically point to our CDN for WebSharper libraries.
WebSharper 3.5.16 splits off the WebSharper.Testing framework into a separate package and fixes a few bugs.
F# has always excelled at accessing heterogeneous data sources in server-side code through its unique type provider feature: a metaprogramming technique that enables generating (or "providing") domain-specific code to be consumed during compilation, such as generating typed schemas for relational databases, CSV and other data files, or bindings for web services and integration with other languages such as R. Type providers are given an optional set of arguments in your code using custom F# syntax, yielding a type space in return.