Hi Petre – thanks for reaching out. Let me give you some background so you can make a better decision for your case.

Over 10 years ago, IntelliFactory developed the first incarnation of WebSharper as an internal toolset that we ourselves used to develop F# web applications for our customers. Back then your only alternative was F# code behind files with ASP.NET. Our main motivation was leveraging the JavaScript ecosystem without having to code in JavaScript and utilizing F# instead for writing shorter, more robust code for both the client and server.

Since then, we employed 20+ F# developers who worked on various extensions, libraries, the compiler and its tooling, evolving WebSharper into a set of coherent abstractions/components (sitelets, piglets, UI.Next, etc.) “that just work” and work really well together. (Not just for toy examples, but for 10--50-100k LOC full-stack F# web and mobile applications. So yes, WebSharper is above all targeted to building large, complex business applications, and has been used in this capacity extensively.)

These components are best leveraged together, but nothing keeps you from integrating other, external libraries and tech. You can bring in whatever else you prefer working with. You can create wrappers/extensions using WIG, via TypeScript declarations, or binding them manually. To your particular question, UI.Next for instance can substitute for a lot of what Angular, React and others can do, but you can always drop back to them if you like. We certainly recommend giving UI.Next a spin, once you get over the initial hurdles you will discover the same kind of ease of use and versatility but inside F#. Wrapping Angular or React with all of their features would require somewhat of an effort, and you will likely be still missing key UI.Next features like templating.

One criticism WebSharper often receives is that "it does too much.” Converting F# and now C# to JavaScript, an optional server-side with OWIN and ASP.NET integration, strongly typed templating, safe URLs, declarative forms, client-side routing, SPAs, client-server apps, HTML/JS applications, etc. and new vocabulary like sitelets, piglets, pagelets, formlets, flowlets ”scare people.” Heck, WebSharper is even declared “evil” by some, who claim that it is too opinionated, monolithic, overly complex, greedy, etc.

The other is that “WebSharper doesn’t fully embrace JavaScript tooling”, and it’s “too much .NET.” This is definitely changing (see upcoming webpack support, etc.) but it’s still mostly true: you indeed need to have a .NET mindset to start with WebSharper. This is inherent in its languages of choice (F#, C#, and now TypeScript) and the default target application paradigm (ASP.NET and now ASP.NET Core).

I could really hammer on what makes WebSharper the best toolset, but then I am biased. But feel free to ask anyhow. You should carefully consider your options and choose what's best for you. I definitely agree that WebSharper needs better documentation on comparing it to ASP.NET MVC, Fable, etc., and I am sure it will be coming soon.

And last, we are trying to dispel mindset that we "own" WebSharper. We are a company that drives its development and provides support and other services around it, but we are only one among the growing number of other contributors/companies around it.