by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 05 23:50
    Jand42 commented #1103
  • Jun 05 15:42
    Jand42 commented #1044
  • Jun 05 13:27
    panesofglass commented #1044
  • Jun 05 00:18
    granicz commented #1103
  • Jun 04 22:31
    Krzysztof-Cieslak commented #1103
  • Jun 04 22:18
    isaacabraham commented #1103
  • Jun 04 21:16
    Krzysztof-Cieslak commented #1103
  • Jun 04 21:00
    granicz commented #1103
  • Jun 04 20:51
    granicz commented #1103
  • Jun 04 20:33
    mjarosie opened #1103
  • Jun 03 18:10
    mjarosie starred dotnet-websharper/core
  • Jun 03 01:32
    ederweber starred dotnet-websharper/core
  • May 31 18:09

    Jand42 on master

    #1055 multi-target compilers to… #1102 add option to hide WebSha… (compare)

  • May 31 18:07
    Jand42 commented #1100
  • May 31 18:05
    Jand42 labeled #1102
  • May 31 18:05
    Jand42 assigned #1102
  • May 31 18:05
    Jand42 opened #1102
  • May 30 14:43
    mjarosie commented #25
  • May 30 09:38
    ericnething starred dotnet-websharper/core
  • May 30 00:34
    granicz commented #25
Adam Granicz
@granicz
we can always be your followers and RT ;)
Artemy
@ArtemyB
But I've prettified the snippet a little bit already, so it looks a bit better

we can always be your followers and RT ;)

There is nothing to RT. :D

Adam Granicz
@granicz
can I tweet it?
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
Adam Granicz
@granicz
:) np
or just comment underneath with the tryWS link
13 replies
Artemy
@ArtemyB
Because there is no code in that link, only final output
Adam Granicz
@granicz
Nice to know gitter supports threads now - anyone know a quick way to find all past threads for a user?
Adam Granicz
@granicz
Hi all, we have started to use the CLA assistant bot for existing PRs - if you received a CLA request but you think it's in error (there are quite a few that went out to existing/past team members, for instance), let me know - thanks!
Adam Granicz
@granicz
@amieres @giuliohome @drssoccer55 @cata @endeavour @ArtemyB @frankebersoll - please consider submitting a talk proposal to fsharpconf, they are looking for F# used in production and would very much be interested in what you are doing!
András Jankó
@Jand42
@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
Conrad Steenberg
@hengestone
That would be nice to have for my case (using only .Net core 3.1 downloads from MS on Ubuntu)
Adam Granicz
@granicz
I believe a fix is being tested, but let's wait until @Jand42 confirms
Maciej J
@mjarosie
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!
Adam Granicz
@granicz
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
Adam Granicz
@granicz
re those valuable 3.x pages - some of these would be: piglets, formlets, and the references for both
Adam Granicz
@granicz
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
Conrad Steenberg
@hengestone
Well, there's of course the mega-comparison test at https://github.com/krausest/js-framework-benchmark
Adam Granicz
@granicz
looks good, any idea how much effort would be to plug into it a websharper test app?
Conrad Steenberg
@hengestone
Not sure, but the tests themselves actually look pretty trivial, and there are plenty of examples at least ;-)
Conrad Steenberg
@hengestone
There is a Blazor-wasm test which might at least have a similar project structure as WS
Adam Granicz
@granicz
yes, I saw that
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
Adam Granicz
@granicz
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
Adam Granicz
@granicz
there is a LOT of room for optimization with sitelets - switching asyncs to Tasks, etc. - @Tarmil / @Jand42 any other ideas?
Adam Granicz
@granicz
@Jand42 can you take a look at dotnet-websharper/core#1044
András Jankó
@Jand42
@granicz Thanks, replying.
Adam Granicz
@granicz
is it anything that might be related to #1055?
András Jankó
@Jand42
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?
Adam Granicz
@granicz
what can possibly break on DNC31 if something works on DNC21?
András Jankó
@Jand42
This is only about the compiler running on DNC31, so having a newer install framework requirement for build. That's it as far as I know, all netstandard2.0 libs that we depend on (e.g. FCS) should work the same.
And we can still target DNC2.0+ with a project built with WS.FSharp/CSharp of course
Adam Granicz
@granicz
but why can't the compiler run fine on DNC31 now, when it's targeted to run on DNC21?
András Jankó
@Jand42
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)
Adam Granicz
@granicz
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
András Jankó
@Jand42
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.
András Jankó
@Jand42
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.