

ASP.NET and F# - Creating MVC web applications in F# - NumberFiveAlive
http://cs.hubfs.net/blogs/tomasp/archive/2010/05/09/14050.aspx

======
luffy
First off, I love F#. I use it extensively for offline data processing,
managing our build process (via FAKE), and general purpose Windows scripting.
I've also dabbled in DSL creation, and if you follow any of examples it really
is pretty easy to do. As Don Syme (F#'s creator) has said, F# is a lot like a
statically typed Python (with lots more syntax).

But I wouldn't use it with ASP.NET. Learning F# is pretty heady and it would
give your average .NET developer fits to learn it. You'd lose an advantage of
using the .NET platform then - it's pretty easy to get average developers to
be productive in .NET/C#. Forcing developers to learn F# would grind
productivity to a halt.

Also, because of the whitespace requirements, F# is lousy in the webforms view
engine. (Perhaps a Mako-like templating engine for F# would make sense).

Stick with C# for your web work and your libraries that your web site are
using. Life will be easier.

If you really want to delve into F# on the web, these guys did a framework
designed to be used with F#: <http://www.bistroframework.org/>

They also did a .NET port of the django templating engine:
<http://ndjango.org/>

~~~
MichaelGG
Most of the time, we use F# on the backend, using C# as little as possible.
For web apps, that usually means the ASPX files themselves. For the MVC
controllers, writing them in F# seems to work great.

The largest contention point arises when we pass F#-ish types to the ASPX page
for rendering. It works, it's just that the C# required at that point can be
sort of ugly.

Also, don't forget WebSharper, which provides a way to write all your client-
side code (JavaScript) in F#. It handles all sorts of things, including async
RPC calls. <http://www.intellifactory.com/products/wsp/Home.aspx>

~~~
luffy
The Intellifactory guys really know their F#. But this seems too much like
WebForms and MSAjax for my tastes. After a while autogenerated javascript and
HTML becomes very problematic, to say the least. If I want javascript, I'll
just write it myself.

Now what I'd really like to see is an F# stand alone webserver - that would
operate outside of ASP.NET/IIS. I envision a functional Request/Response
pipeline, where you can augment the pipeline using function compositoin.
Perhaps this could even handled by a computation expression or workflow. ( For
those unfamiliar with F#, this is one of the killer features. See how simple
it is to handle Async or parallel processing in F#).

Chris Smith has an interesting example of a Session State workflow in his F#
book - I would like to see someone attempt that with a full fledged server.

------
batasrki
Hmm, good article, but I think it does more to expose Microsoft's inability or
unwillingness to integrate F# into the .Net platform the way C# is.

He had to create a C# web project, as Visual Studio doesn't support that for
F#. He had to create a C# LINQ-to-SQL project to generate model classes as
there's no support to do so in F#.

This saddens me greatly. Here is a potentially great language in the .Net
ecosystem and the support for the most basic of things is missing.

------
contextfree
Has anyone used the WebSharper framework
(<http://www.intellifactory.com/products/wsp/Home.aspx>) designed for F#? It
looks like it addresses several issues I have with web development in general
and F# web development in particular ...

~~~
MichaelGG
We've started too, but not on any sizable projects yet. The guy that does our
UI stuff loves it, and looking at the code, it looks pretty easy.

To keep apps interactive, you have to doing a lot on the client side. To keep
sanity, you want to use a decent language. WebSharper seems to fix both of
those.

------
henning
If you get to write all your business logic in F# and there are no needless
sources of headaches, I guess that could be pretty nice if you already use
ASP.NET.

~~~
contextfree
The main headache-inducer I've encountered is that to really get the benefits
of F# I'd like my model objects to be immutable records, but the ASP.NET MVC
model binding infrastructure (along with the binding/serialization/etc. parts
of a lot of other .NET frameworks) assumes mutable model properties (and
default constructors). You can create a custom model binder, which works but
isn't 100% satisfactory for other reasons.

The example gets around this by just using LINQ to SQL generated C# classes as
the model, but that's a big compromise.

------
DennisP
Somewhere I read an article about how easy it is to create your own view
engine for MVC. Given F#'s facility with DSLs, it seems it wouldn't be too
infeasible to make an F# view engine too.

~~~
SanjayUttam
Some links to create your own engine in asp.net mvc:
[http://www.singingeels.com/Articles/Creating_a_Custom_View_E...](http://www.singingeels.com/Articles/Creating_a_Custom_View_Engine_in_ASPNET_MVC.aspx)

[http://amazedsaint.blogspot.com/2010/06/creating-custom-
view...](http://amazedsaint.blogspot.com/2010/06/creating-custom-view-engine-
for-aspnet.html)

Unrelated, but every time I see an F# article I think of a quote from Juval
Lowy I heard on the Dot Net Rocks podcast (I think), which went something like
"Yeah, with F# you can just slam your fingers onto random keys and it will be
valid code"

(edit:formatting)

~~~
jackfoxy
_...and it will be valid code_

There are a lot of subtleties to the syntax that are not easy for someone new
to the language to figure out, especially if you are new to the functional
family of languages. The error messages are not always helpful. I can see F#
will be a great tool for certain problems, and once you are really proficient
I can understand making a statement like this.

~~~
SanjayUttam
Agreed, just found Juval's quote entertaining.

