51–60 of 86 posts
Another monolithic framework that will likely catch some unsuspecting CTO or director and ultimately be his demise, or someone who doesn't want to learn javascript (such people still exist, sadly).
It's well intentioned, but this project is destined to go nowhere fast. Abstracting away web development and http has been tried again and again, and always ends up being more hassle than plain ol' HTML+JS+HTTP. Then you've limited yourself to interop with the js libraries they've provided leaky wrappers over, or you can write your own leaky wrapper if you want to use coolnewthing.js you saw on github. And to cap it…
It's well intentioned, but this project is destined to go nowhere fast. Abstracting away web development and http has been tried again and again, and always ends up being more hassle than plain ol' HTML+JS+HTTP. Then you've limited yourself to interop with the js libraries they've provided leaky wrappers over, or you can write your own leaky wrapper if you want to use coolnewthing.js you saw on github. And to cap it…
People have mentionned that such abstraction generally become more trouble then they are worth but I completely disagree.
In particular the question would be what are the corner cases that will make the abstraction more difficult to use and ruin your overall productivity and I haven't found anything so far.
What I find difficult though isn't creating wrappers around existing external javascript libraries but rather learning the quirks of each of them. For instance, I happen to maintain a WebSharper wrapper around the Kendo Web library (see here https://github.com/davidgrenier/Kendo) with the goal of abstracting away the complexity from my code base and where I spend most of my time is trying to figure out how to properly use any new control we've yet to use in production. This process is tedious and error prone because the examples on the Kendo website aren't exhaustive, the documentation isn't specific about the semantics of the library and just the brittle nature of javascript development. I spend lots of time in the chrome debugger and their online tool figuring out how things work. The productivity gain from isolating that from my code base is significant.
F# as a language is quite understated, more companies are using it than it seems (many of which in stealth mode) and so is the case for WebSharper. IntelliFactory has been selling licences to many of their closed-source clients, my employer being an example but also I'm aware that MSR uses it internally on a few projects and was told the developpers there love it. The fact that my employer continues to pay the licence, gives me work on the project and has recently hired another developer working full time with WebSharper indicates that they consider the value to be at least on par with everything else we do.
Over the 3+ years I've been using WebSharper, I've had to report only a single bug Monday of last week (see here https://bitbucket.org/IntelliFactory/websharper/issue/288/sy...) in the WebSharper core libraries related with compatibility issue in old version of IE and the bug was fixed within the week and had access to an updated WebSharper package from nuget.
WebSharper isn't just an F# to JavaScript compiler, they also offer powerful, paper-worthy abstractions to improve developer productivity:
-Transparent RPC calls from client to server (combined with static typing this is one of my preferred feature).
-Combinators for composing pages and managing routes in an elegant typesafe way.
-The ability to create standard server-side markup and yet SPA page building is even better as you get to pick what you carry over the wire and simply create all your markup on the client.
-Tools to create extensions around external javascript libraries (I've personally used WIG and works really well and I learned a few things about design while using it to boot).
-If you have access to Libraries that offer TypeScript bindings (like Kendo does) IntelliFactory can generate the wrappers for you.
-Tons of precreated wrapper for you to simply use
-Combinators to compose data/UI controls/event flow handling like Formlets/Piglets and now UI.Next which is excellent, I've come to appreciate all three and we're using Piglets in production though UI.Next should go a long way to allow you to do anything you need.
-Use existing abstractions in the standard F# development experience which would be hard to get otherwise (async workflows is an example).
I don't have strong opinions one way or another on licencing but as been mentionned before IntelliFactory generates revenues and as such I'd be skeptical of someone claiming that such and such model "doesn't work". Besides most of the concerns I've seen here seems philosophical rather than about direct impediments the licencing creates on what they had to do. Indeed the licencing cost my employer has to be is insignificant compared to the benefits and I personally do not pay for a licence on my own stuff.
Microsoft's position around the .NET ecosystem is sound, they provide the CLR, Base Library and a world class development environment. The rest is open to the community to drive the libraries/toolset they need, after all Microsoft can't do everything and it seems to me would tie in the community to Microsoft. You can see the latest open sourcing of the Roslyn compiler as a reflection of that. Likewise, the F# compiler service project and the direction taken by the F# Power Tools and the way Microsoft supports this initiative to enhance the VS development experience sends the same message. Speaking with Don Syme he indicated that technically there wouldn't be anything standing in the way of doing the equivalent of what IntelliFactory did with the new C# compiler, though you can be sure of two things: Microsoft won't be doing it and it's likely a tremendous amount of work.
I haven't played with any other similar toolset (ClojureScript/Purescript/GWT comes to mind) and as such I will not comment on those. But I will advise against listening to advice from anyone who hasn't used any of those specific libary. Even better, sit down and spend the time required to make it familiar and then you'll be a better judge.
If you are already using F#, I urge you to put 10-20 hours on it, you will thank yourself. If you aren't using F#, in my mind, WebSharper is just another wonderful reason to start doing so.
Earlier quoted context omitted.
How do you propose they make money to pay salaries?
Paid support, tools, there're plenty of companies which follow this business model. Extjs, Vaadin, Typesafe, etc. I understand that they want to make a money, however, using their license is unacceptable risk, especially taking into account there're comparable alternatives. I'd rather use GWT/TypeScript/Scala.js, than proprietary framework which I won't be able to work with if they changed license to something unacce…
Earlier quoted context omitted.
>It's less than 400 USD/year for a freelancer... if it's any good it should pay for itself, practically? The problem isn't paying 400 USD/year. This is negligible cost compared to how much it costs to hire a developer. The problem is that software created in such a way wouldn't be widely used for reasons mentioned in one of my other comments.
I can't seem to find that. You mention something about risk -- but I'm not sure which risk that is. As I understand their license page, you need a license per developer. The resulting code you're free to sell under a closed license. If you want to sell work under a closed license, you're covered. If you want to sell it under an open license, you can sell it under the AGPL. Exactly what are you missing from this kind…
Earlier quoted context omitted.
It's a F#-to-JS compiler, a UI framework, and an RPC system all built into one. Script# is similar, for C#, but I don't think it got that far? MS did start "Project Volta" IIRC but then gave up on it. There's also FunScript: http://funscript.info/ but that seems more focused only on the JS generation part. I don't know why Micrsoft doesn't buy these guys and deliver this as a core solution. I'd guess it's because it'…
There are already a few approaches out there for compiling C# to JS, like my JSIL ( http://jsil.org/ ) and Script#'s unofficial successor, Saltarelle ( http://www.saltarelle-compiler.com/ ). I believe there is a new Roslyn-based C#->JS compiler in the works as well. I'm not aware of anything that approaches WebSharper's level of integration, though. It's a really impressive piece of work.
I've been using WebSharper in production for 20 months now and I wouldn't consider doing web development any other way. People have mentionned that such abstraction generally become more trouble then they are worth but I completely disagree. In particular the question would be what are the corner cases that will make the abstraction more difficult to use and ruin your overall productivity and I haven't found anything…
And what is the state of F# on Linux these days?
The project is really great, however license is really bad. A modern framework, should be open source under liberal license. Licenses like this worked in 90s, but currently they don't work.
If you don't like the license, don't use the framework. It's that simple. Charging for commercial licenses for libraries is a perfectly valid business strategy, and I can see lots of F# developers paying for this.
That was the point, remember? Because of the terrible license, very few people will use it. So it will stay tiny and/or die out.
>and I can see lots of F# developers paying for this.
That's a non-sequitur. I pay for lots of free software. The problem is not cost, it is freedom.