As all abstractions are leaky I have to concede that it has to be, but considering the size of the abstraction it's actually surprising how little gets in the way of getting things done (short of getting the hand of it for which the learning curve is far within that of WPF must have been for some people).
As far as as doing away with Web Development skill I would say no. As opposed to what ASP.NET used to do WebSharper doesn't try reinvent Web Development so one can "leverage" their existing Web Development skillset as opposed to have it superseded with something else.
On the other hand, being that I myself am a pretty bad web developer (despite of it being my official title), having static typing on a set of library that maps to HTML can really help (IntelliSense and simply preventing you from compiling something that wouldn't work). The other abstractions are just on top of everything else yet uses functions with the names you may be familiar with to produce markup.
Plus, I find that having functions as opposed to open and closing tags with the XML syntax is better on the eyes:
Another aspect is how easy it is to refactor blocks of markup away into function calls and use all existing F# functions over collections to programmatically produce content:
[
"David", "Grenier"
"Anton", "T."
"Loic, "D."
]
|> List.map (fun (firstName, lastName) ->
let lbl text = Label [Text text]
LI [lbl firstName; lbl lastName]
)
|> UL
If you have a little imagination, you can see this can go a long way.
davidgrenier|11 years ago
As far as as doing away with Web Development skill I would say no. As opposed to what ASP.NET used to do WebSharper doesn't try reinvent Web Development so one can "leverage" their existing Web Development skillset as opposed to have it superseded with something else.
On the other hand, being that I myself am a pretty bad web developer (despite of it being my official title), having static typing on a set of library that maps to HTML can really help (IntelliSense and simply preventing you from compiling something that wouldn't work). The other abstractions are just on top of everything else yet uses functions with the names you may be familiar with to produce markup.
Plus, I find that having functions as opposed to open and closing tags with the XML syntax is better on the eyes:
as opposed to: Another aspect is how easy it is to refactor blocks of markup away into function calls and use all existing F# functions over collections to programmatically produce content: If you have a little imagination, you can see this can go a long way.