psarm VS Fable: F# |> BABEL

Thanks for the thoughtful response! Many of these are totally legitimate: in particular, we're making steady progress to centralize module design, release, documentation, and modernization, or at least to bring many teams closer together. In many cases, we're at a transition point between moving from traditional PS remoting modules and filling out PS coverage for newer OAuth / REST API flows.

I don't know how recently you've tried PS7, but the back-compat (particularly on Windows) is much, much better[1]. And for those places where compatibility isn't there yet, if you're running on Windows, you can just `Import-Module -UseWindowsPowerShell FooModule` and it'll secretly load out-of-proc in Windows PS.

Unfortunately, the .NET problems are outside my area. I'm definitely not the expert, but I believe many of the decisions around the default assembly load context are integral to the refactoring of .NET Core/5+. We are looking into building a generalized assembly load context that allows for "module isolation", and I'd love to get a sense in the issue tracking that[2] whether or not fixing that would help solve some of the difficulties you're having in building modules.

For Azure, you should check out the PSArm[3] module that we just started shipping experimentally. It's basically a PS DSL around ARM templates, as someone who uses PS and writes the Azure JSON, you sound like the ideal target for it.

As for the help content, that's a very funny story for another time :D

[1]: https://aka.ms/psmodulecompat

[2]: https://github.com/PowerShell/PowerShell/issues/2083

[3]: https://github.com/powershell/psarm

This conversation could be referring to https://fable.io/

Other than that, the question is indeed strange and I agree with your statements.

NOTE: For larger codebases with more history it is likely that the Program.fs file will have a lot of orchestration and logic as well. given that it is often where everything clashes and starts, for example the Fable Entrypoint is in Entry.fs and it contains a lot of code. The best you can do always is to start at the bottom of the file and work your way up. Remember: Everything at the bottom uses what has already been defined at the top so there are no circular dependencies or random functions/types at the bottom that can trip you off, everything comes from the top!

I am a big fan of going with web components + plain (build-less) javascript whenever possible, so it is not surprising that I often favor things like the Fable Compiler, where I can target my F# code directly to javascript and be as close to the native JS experience as possible, both for interop concerns and for ecosystem integration.

Fable compiler - https://fable.io/

The F# community is very friendly (these sub-communities as well), and they have plenty of good issues/opportunities to contribute OSS work to across any skill level.

Phosphor isn't hiring right now, but we expect to begin a search for FE/interface engineers over the next few month. Email [email protected] for anyone interested.

Naturally I’d recommend using a better language such as ReScript or Elm or PureScript or F#‘s Fable + Elmish, but “React” is the king right now and people perceive TypeScript as “less risky” for jobs/hiring, so here we are.

Stuff like this: https://github.com/fable-compiler/Fable/issues/1822

It just seems like an incredibly ambitious project that appears to have very little equal but is mainly worked on by a handful of people but no corporate backing. I get the feeling that if you want to use it, you'll either be the only one doing what you're doing or among just a few people. I already use F# and feel this way about the core language itself.

F# is also part of the OCaml family, has a great to-JS transpiler (https://fable.io/) and F# code can also be used in .NET projects.

I have heard many good things about https://fable.io/ Fable converts F# code to JavaScript. There are currently 407 packages available for interacting with existing JavaScript packages and frameworks.