WebSharper 2.4

[Anton Tayanovskyy]

Hi everyone,

How is WebSharper working for you?

I have been rather busy improving the basic but important factors such
as compilation speed and output code quality for the 2.4 release [1].
Finally there is some progress along those lines, and I can spend
some time looking at new features. I remember about these features
that have been requested/proposed over time:

* --standalone option to merge libraries into a single JS file
* C# support
* support for writing tests (client-side, server-side)
* ability to deploy to Linux, perhaps outside of IIS, on an OWIN host
* better integration of sitelets with client-side code, in particular
an ability to use Action values directly on the client
* some support for cloud execution (Azure, EC2?)
* better API for InterfaceGenerator

My colleagues implemented an neat feature already allowing to deploy
WebSharper-compile code to mobile phones and use RPC methods to talk
to a public web server, that is actually included in the latest 2.3
installer. The rest of them remain to be done.

Your thoughts on these are very welcome.

Anton

[1] http://t0yv0.blogspot.com/2011/09/30-40-faster-and-leaner-websharper-24.html

[Richard]

These new features sound excited. Thank for your efforts.

I had a problem long time ago:
When I need to add a new page with server-side functionality
in my sitelet, l can only compile the whole project again.
This process (write-compile-test-debug loop) is very time-consuming.
Does any (more decoupled?) approach exists? Something like MEF?

For example: I can store blog posts in a database and get them
dynamically. But how can I store my pagelets in some kind of db and
pull them out dynamically?

[Ryan Riley]

If there are no dumb questions/suggestions, what about generating or managing Lively Kernel worlds? I would love to be able to edit F# in a live browser application and have that compile into my app immediately. :)

[Ryan Riley]

Replacing the use of tables in formlets with lists would make me very happy, even if it's an option/setting. In practice, I've found lists to be far more flexible to layout with CSS and generally provide the number of hooks without abusing the semantics of the table element. As a default style, you can always use the table, table-row, and table-cell css options that are now supported by all major browsers.

[Ryan Riley]

I'll add that the primary reason is for accessibility.

[Ryan Riley]

Another idea just struck me. It's something I've been puzzled about for some time. In samples using both client and server code, the availability of the two together looks more like a marriage of convenience. It is a nice feature, but suppose I have a number of services already deployed, and I just want a client-side app. Or take the other hand and suppose I just want to spin up a new service. Both are possible with WebSharper, but neither is well advertised. Further, if the two pieces were better decoupled, I would imagine you would have been forced to build a better InterfaceGenerator api. I'd love to see more and better samples showing the ability to leverage the InterfaceGenerator to tie client and server side code together, rather than building my client and server components within the same library.

[Anton Tayanovskyy]

Eekh, Lively looks too much like SmallTalk to me. Have you managed to
make sense out of it? I tried a few smalltalks in my life but never
"got it", maintaining and navigating hundreds of methods through the
class browser seems very distracting compared to module-centric
programming as in ML/F#.

> I would love to be able to edit F# in a live
> browser application and have that compile into my app immediately. :)

Yes many of us would! As things stand though WebSharper is not the
right tool for this kind of stuff. What you would want there is
IL-level translator that emulates complete .NET semantics (reflection,
generics, everything) in JavaScript. Such a system would be great for
running arbitrary .NET code but I imagine performance wouldn't the
best because of the overhead of representing everything. WebSharper
restricts itself to a tiny subset that is very close to JavaScript
itself, so there is little overhead but also no portability - we
definitely can't compile F# compiler to JS.

Another alternative of course is bypassing JavaScript altogether and
running the F# compiler code as is - in Silverlight. Have you tried to
embed FSC into it?

--
Kind Regards,
Anton Tayanovskyy

WebSharper™ - type-safe JavaScript in F#
http://intellifactory.com

[Anton Tayanovskyy]

Thank you Richard for the feedback. We are working on making the
process less time-consuming but the results so far are very modest (we
got about 30-40% improvement in 2.4). You are right, using MEF in
conjunction with some lightweight webserver that avoids the IIS stack
might further help with turnaround. I am looking forward to trying
that out.

--

[Anton Tayanovskyy]

Thanks, I will talk to Joel about this, sounds reasonable for all I know.

--

[Anton Tayanovskyy]

This is a valid point.

Yes we've been encouraging single-domain programs with [<Rpc>] methods
that allow client-side to talk to the server. With 2.3 mobile
templates there's an option to go cross-domain and have a client call
an [<Rpc>] method from a different server, but yes, it is not
sufficiently advertised.

It took me a bit to figure out why do you mention InterfaceGenerator
in this context, is this because you believe code generation is
necessary to solve the problem?

A simple solution comes to mind that does not imply code generation:

(1) We define a service contract, say as an interface. Both clients
and servers have access to this definition.

type IWeatherService =
abstract member GetTemperature :
System.DateTime -> Location -> Async<float>

(2) The client uses the type of the service and a URL to construct a
proxy object that is later used as a normal object:

let weather = Remote.Proxy<IWeatherService> "http://weather-example.com"
async {
let! x = weather.GetTemperature System.DateTime.Now
"Harrisonburg, VA"
return ()
}
|> Async.Start

(3) The server uses the type of the service and an implementation to
add it to the table of supported services on a site (say as part of
sitelets).

Does this solve the decoupling?

Of course if we want to non-WebSharper clients or servers in the
picture this does not quite cut it. I would wait until type providers
come out of beta before tackling that, to do the code generation in
the type provider.

Thanks,

A

--

[Anton Tayanovskyy]

I am being reminded we could use FPish.net for further discussions. I
am happy with the email interface too if you are more comfortable this
way. Anton

[Adam Granicz]

Indeed, you all please use FPish - the forum there has much larger
visibility, it gets archived, it's searchable by words and tags, and
so much easier to find answers. Please use whatever tags are
appropriate for each new topic, and be sure to include "websharper".

Thanks,
Adam.

On Tue, Nov 1, 2011 at 9:07 PM, Anton Tayanovskyy

--
Adam Granicz, IntelliFactory
www.intellifactory.com

[Ryan Riley]

I thought it was an unlikely request but thought I would ask just in case. Thanks!

[Joel Björnson]

Hi Ryan,

On Mon, Oct 31, 2011 at 6:36 PM, Ryan Riley <ryan....@panesofglass.org> wrote:

Replacing the use of tables in formlets with lists would make me very happy, even if it's an option/setting. In practice, I've found lists to be far more flexible to layout with CSS and generally provide the number of hooks without abusing the semantics of the table element. As a default style, you can always use the table, table-row, and table-cell css options that are now supported by all major browsers.

The reason we use tables for the default vertical layout is to be able to align the labels. Not sure how to do that with lists but will look into it. At the very least, we should provide alternative, non-table based versions of horizontal and vertical layouts.

Joel

[Ryan Riley]

I can't find an example on logos.com, though I know we used the same-level-labels at some point. Sitepoint's book The Art & Science of CSS has an excellent example, though, as does their book Everything You Know About CSS Is Wrong, re: table layouts. They appear to have several others:  http://products.sitepoint.com/?tag=&filters%5Btag%5D%5B%5D=css&filters%5Bdifficulty%5D=&simpleform_submit_marker=showme

[Ryan Riley]

On Tuesday, November 1, 2011 1:04:54 PM UTC-7, Anton Tayanovskyy wrote:

It took me a bit to figure out why do you mention InterfaceGenerator
in this context, is this because you believe code generation is
necessary to solve the problem?

A simple solution comes to mind that does not imply code generation:

(1) We define a service contract, say as an interface. Both clients
and servers have access to this definition.

type IWeatherService =
    abstract member GetTemperature :
        System.DateTime -> Location -> Async<float>

(2) The client uses the type of the service and a URL to construct a
proxy object that is later used as a normal object:

        let weather = Remote.Proxy<IWeatherService> "http://weather-example.com"
        async {
            let! x = weather.GetTemperature System.DateTime.Now
"Harrisonburg, VA"
            return ()
        }
        |> Async.Start

(3) The server uses the type of the service and an implementation to
add it to the table of supported services on a site (say as part of
sitelets).

Does this solve the decoupling?

This might resolve it for testing purposes, but it doesn't really address the problem I was pondering, which you identify below.

 

Of course if we want to non-WebSharper clients or servers in the

picture this does not quite cut it. I would wait until type providers
come out of beta before tackling that, to do the code generation in
the type provider.

A type provider solution is a good idea. I know that my company already has a heavy investment in several service apis they wouldn't want to rewrite if they were to switch to building new stuff in WebSharper. Further, if I want to build out a fully RESTful set of services, complete with conneg, doing so with WebSharper would be possible, but I'd probably want to do it in a completely separate project as it would be servicing far more than just my web client app. Maybe that's a mistake in my thinking. Also, I know I could build them together and might choose to do that. I might be stretching WebSharper beyond its intended design goals.

Ryan