61–70 of 86 posts
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…
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…
I might be missing a point, but how is this different from tried-and-failed GWT? Apart, obviously, in language of choice.
It has it's niche just like every other framework. Google is now using it to share code between Web, Android, iOS, and Server (shared client side business logic). Google Sheets is the newest example of such Hybrid apps, and the gains are substantial, 60-70% code sharing between platforms, only the UI needs to be reimplemented natively.
Just because something is not monopolizing a particular area of development doesn't mean it's "failed". The ecosystem is large number for many different frameworks to remain vibrant.
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…
For example, using similar techniques that html5index.org uses, all browser native APIs are automatically covered by fetching the latest WebIDL definitions from Chromium or Firefox's repository or via standards docs, and used to generate the interfaces.
Or, using IDE FileWatchers, we use the Closure Compiler to read in Javascript libraries and/or externs, infer types, and write out interfaces. Likewise, we'll be able to read in typescript library interfaces and generate Java interfaces.
Combining the new JsInterop system, Java8, and SuperDevMode's <1 second compiles, the new system eliminates wrappers, reduces Java boilerplate overhead (lambdas, method references), and provides fast refresh times.
That's interesting. I appear to have actually accidentally written a chunk of this in C# for a product a couple of years back. The approach is pretty much identical.
what are the standard tools for working with databases with f# and websharper?
The idiomatic way to deal with databases is using one of the available type providers. Basically, a TP generates types at compile time, in a way that actually plays quite nicely with IntelliSense [1]. In the case of db TPs, they're parameterized by a connection string and connect to the db to extract the schema and generate the appropriate types. Several exist [2]; SqlDataConnection and SqlEntityConnection are built-in, FSharp.Data.SqlClient and FSharp.Data.SqlProvider are community contributed. They all use query expressions (basically, F#'s extensible version of LINQ syntax) except SqlClient which directly uses SQL in a string (but still checks the query at compile time and passes arguments cleanly, thanks to the TP) and is therefore more like a (safer) micro-ORM.
[1]: http://msdn.microsoft.com/en-us/library/hh156509.aspx [2]: http://fsharp.org/guides/data-access/
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…
Disclosure: I work at Microsoft Research but not on F# and have ongoing interactions with folks at Intellifactory
Earlier quoted context omitted.
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…
For example, company decides to change a license, and I need a new developer. What should I do in this case especially if I work for a startup and its only product is created with this technology?
I do get that there might be a question as to how you could get additional developers under the old license...
Earlier quoted context omitted.
For example, company decides to change a license, and I need a new developer. What should I do in this case especially if I work for a startup and its only product is created with this technology?
If you already have a project - you have a copy of the code under the old license. Is it really that different from a company changing from a bsd license to closed source? You'll have to negotiate or fork in either case. I do get that there might be a question as to how you could get additional developers under the old license...
Earlier quoted context omitted.
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.
AFAIK, even for the open-source license - you only have to provide source code to your client - i.e. when distributing... If you're using this framework for your personal project - you're free to not to release source code - since you're not distributing the binaries of your project either.
In this case you can't even publish the code, since compiled js is kind of binary.