Added --fableLib arg

[ncave]

• Added --fableLib arg in fable-compiler-js

[alfonsogarciacaro]

Thanks @ncave! I wanted to ask you, what do you think could be the use cases of fable-compiler-js from now on? How should we present it in blog posts, etc? (Or whether we shouldn't.) Before the main advantage was it was easier to setup. Now on one hand it's even easier because there are less dependencies but on the other the dotnet fable tool provides a similar experience without the limitations (packages, type providers).

I replaced fable-compiler-js with the new dotnet fable tool to compile build.fsx in this repo for dogfooding. I didn't do any proper benchmark but I've the feeling fable-compiler-js was actually faster to bootstrap. When compiling the test it's slower than dotnet fable, but it may happen that it works better for small workloads.

Anyways, I need to update the repl so we can check the speed improvements. I guess I'll leave the dependencies out for now.

[ncave]

@alfonsogarciacaro The use case is, as it always has been, that it is completely in JavaScript and doesn't need dotnet to run. Now that it doesn't need Babel anymore, it's very lean, almost no npm dependencies. I think Fable packages are supported, as they're compiled from source code. I haven't looked at type providers yet. Yes, it's about 2-3x slower than the (highly optimized) dotnet version when compiling big projects, but as you said it might start faster in smaller workloads.

[alfonsogarciacaro]

Thanks @ncave! Yes, supporting packages should be possible. Just, if I'm not mistaken, we're still missing the machinery to resolve the dependencies and get the location of the assemblies (that in turn point to the package fable folders containing the source code), which is what Dotnet.ProjInfo does for us. I also wonder if we should try to share more code between Fable.Cli and fable-compiler-js.

BTW, I published the repl for Fable 3 here. Performance seems to be roughly the same.

[ncave]

@alfonsogarciacaro Support for nuget packages was added a year ago in #1943, so it's available in Fable 2 as well.
Adding paket.references support is possible, but see some caveats in the PR notes.

Thanks for publishing the new repl3, that's great. I think we're ready to release an RC for fable-compiler-js as well, unless you want to wait and see some feedback first.

[ncave]

@alfonsogarciacaro Yes, Fable 3 compilation performance in the repl3 (in Chrome) is roughly on par or slightly better than Fable 2, but that's a good thing, given how many changes there are in Fable 3. Performance of the compiled code also seems to be same as in Fable 2 (in Chrome).

Performance of some compiled code in Firefox seems worse, we probably need to look into that. In some cases it can be up to 6x slower, see the RayTracer sample.

[alfonsogarciacaro]

Oh my, I had absolutely forgotten about that PR 🤦 I need to try that out. Yes, let's publish an RC for fable-compiler-js (we can even consider renaming it to fable-compiler later).

Firefox always lagging behind with the repl :/ I've compared the Fable 2 & 3 outputs for RayTracer and the main differences are JS classes and iteration. Fable 2 uses the Seq/iterate helper while Fable 3 translates directly the F# pattern getEnumerator, try ... with ... finally Dispose. I've tried using iterate in Fable 3 output, seems to help a bit but it's still around 5x slower so I guess it must be the classes 🤔

[ncave]

@alfonsogarciacaro Yes, unfortunately it looks that way. Switching list iteration from for x in xs to List.iter, and the structs to tuples, brings it down to 1x.

[alfonsogarciacaro]

Ok, I guess now the performance issue with composing BasicPatterns is fixes we could try to capture the for ... in pattern again and replace it with iterate.

About the structs, maybe we could try to implement them as tuples. Hopefully we don't have the issues we had with records (reflection, comparison...). The only problem I can think of is when implementing an interface, but we could just forbid that or disable the optimization in that case. What do you think?

BTW, in order to test this kind of things in the REPL I've implemented the following:

• Now in repl3 the JS editor is actually editable, so in the case of the RayTracer you can make a change in the JS code and hit Cmd+S or Alt+Enter to see the effect in performance.
• I've added the watch-standalone target in fable repl, so if you have repl3 also cloned you can run this build target and pass it the location where the repl is building the bundle, like: npm run build watch-standalone ../repl3/public/js/repl/bundle.min.js. Then in repl3 run ./fake.sh build -t WatchApp and whenever you make a change in Fable compiler you can just refresh the repl (after a few seconds) to see how this affects the generated code in different browsers.

[ncave]

@alfonsogarciacaro It's not just about structs, perhaps any record or class type will perform badly in Firefox if compiled to classes.

I've started doing some work in #2279 (based on your #2236) for erasing unions and records to named tuples. It's just an experiment to see if that improves performance or bundle sizes. It's still WIP and not fully functional yet in the sense that it's not passing all tests, but it's most of the way there.

[ncave]

One benefit of having the two repls up is we can easily make performance comparisons. I'm actually not seeing a big difference in the Raytracer, it was already slower in Firefox for Fable 2.

@alfonsogarciacaro Yes, I can confirm that for whatever reason Fable 3 is now back to Fable 2 performance levels on Firefox.
Something must have changed since, either in Fable 3 or in Firefox itself, but it's back to being just 2x slower than on Chrome, same as Fable 2. It's great when issues magically fix themselves over time :)