we can always be your followers and RT ;)
There is nothing to RT. :D
i'll use your tryws username so no one can suspect it came from you ;)
Ah, sorry, wrong link
Have to re-post with the correct TryWS link
or just comment underneath with the tryWS link
13 replies
@drssoccer55 @AlexPeret Sorry for the very long turnaround, I am now taking a hard look at the netcoreapp3.1 assembly redirection issues. Some WebSharper functionality such as outputting offline sitelets and locally defined macros make the compiler load the freshly compiled assembly dynamically, and the compiler for netcore is still running on netcoreapp2.0. I have tried playing around with assembly redirection in config (having no upper bounds) with no success, currently testing to multi-target the netcore wsfsc between netcoreapp2.0 (used for netstandard2.0 and netcoreapp2.x) and netcoreapp3.1 (used for netstandard2.1 and netcoreapp3.x) I think that would solve it while breaking no existing build scenarios.
1 reply
Hi folks, I'm a newbie when it comes to both F# and WebSharper (I've got some knowledge about functional programming though, I dabbled with Haskell recently). I've been trying to spin up examples from the "Overview" documentation page, to no avail. I've documented my progress here: dotnet-websharper/docs#25 Would anyone be able to point me to some working "Hello world!" examples? I don't mean spinning up the SPA template, but how to modify the snippets from the documentation so that they work. After I'd succeed, I'd be keen on improving the documentation so that the newcomer experience was better than I had. Thanks!
Indeed, the docs need a serious revamp - any help is appreciated! See my comment on dotnet-websharper/docs#25
one big problem is that we left off several valuable doc pages from the 3.x docs in the current set
then we introduced the silly version selector
so I am all for taking a fresh look and do the getting started guide right
has anyone by any chance looked at https://github.com/evancz/react-angular-ember-elm-performance-comparison and figured it would be possible to update it with latest React/Angular/Elm/etc? This would be a good base to benchmark WebSharper too
Well, there's of course the mega-comparison test at https://github.com/krausest/js-framework-benchmark
I would like to benchmark WebSharper.UI and WebSharper.Mvu vs some of the notable reactive JS libs
last time I looked into this, something like 3 years ago, reactive WS code was ~10% faster than React
I'll try to dig up the numbers, I think I used them in a talk somewhere
Hi @panesofglass, thanks for adding WebSharper here: https://github.com/the-benchmarker/web-frameworks/pull/2874/files - we were just talking about doing a client-side/reactive benchmark too
Yes. I got stuck with packaging issues on that one, paket producing invalid nuget packages. By now, I think having the back-compatibility for non up-to-date build boxes does not worth the package size bloat. So it would be better to just run on DNC3.1. (and prepare for when .NET5 comes out, just deprecate .NET 4x version with a WS5.0) Thoughts?
And we can still target DNC2.0+ with a project built with WS.FSharp/CSharp of course
Most of the time it can run ok. Only breaks if: a) build box/Docker instance only has latest 3.1 and not 2.0 runtime. Also it seems that there were some TP issues on DNC 2.0, this was the original problem on #1044 b) some reflection-based functionality in WS compiler tries to load a project output dll that is built for higher netcoreapp version (e.g. locally defined macros, or offline sitelet running - latter is the case in #1055)
with that reasoning (can't load into a DNC21 compiler "a project output dll that is built for higher netcoreapp") we will always have to pin the compiler to a near-latest DNC, and soon we will have the reverse problem: people will find they are unable to work on WS projects without constantly updating their SDK - whereas in reality, there is nothing in our chain that requires it
this means that the "DLL hell" is now an "SDK hell"
all that mess for the inability to load higher targeted DLLs doesn't seem to be worth it - I'd instead try to figure out a different way to the loading problem
only needed for major releases of DNC, we could stick to LTS versions. Patches are not a problem. It is tied to a runtime identifier, exact SDK version does not matter, that affects the extra tooling only, once wsfsc.exe got started it does it's own thing based runtime libs available. And afaik - checked some dlls like in my local installs - patch versions still come with the exact same framework assembly versions - they must or otherwise patches would be breaking. So it is really just an update once a year or so.
There is no fully safe "different way to the loading problem". DNC versions do come with breaking changes https://docs.microsoft.com/en-us/dotnet/core/compatibility/breaking-changes
A non-self-contained app can roll forward with minor runtime versions, but not major.