-
Notifications
You must be signed in to change notification settings - Fork 296
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better support for fable-compiler-js #3794
Comments
In reality, it has been released as stable since a long time. The beta / stable version you see here is because we recently moved all Fable NPM package under
Using Fable without .NET installation is in theory possible in reality you it will mostly never be the case. You need to have .NET installed in order to have your editors/IDE running unless you like using bloc note to edit code.
If your goal is to write documentation about using Fable, I would encourage you to guide your users to use the .NET version of Fable which is the one that we currently actively develop. I will still look into making the CLI tool works again, as it is actually used in the CI so I think it should not be too difficult to fix. |
@MangelMaxime
I understand that, and the below is absolutely not a feature request but for a future reference and my personal interest. Has anyone here compiled Fable to WASM? |
No problems with the issues you opened, we should fix
Not that I know of. But this is something that was discussed in the past, as it could perhaps improve the packaging of Fable via NPM and makes it possible to better structure the REPL etc. But by lack of time, it has not been explored yet. |
Thank you for your prompt contributions.
Exactly. As I mentioned earlier, since Fable compiles to JS, I see F# has huge potential as an AltJS. Currently, people use
Alternatively, we use
Recently, interesting things going on at StackBlitz using WASM. Introducing WebContainers: Run Node.js natively in your browser |
@ken-okabe Thank you for opening this issue, and thank you @MangelMaxime for fixing the build. I agree with @MangelMaxime that most users should be steered towards the .NET tool release of Fable, as it is the most supported and capable version for cross-platform transpiling of F#. That said,
About compiling Fable to WASM, we have not tried yet, but since WASM is only ~30% faster than JS, in theory it will still make it 2x slower than the .NET Fable. To clarify, currently we have several ways to compile to WASM:
To summarize, And lastly, if using Fable without any additional dependencies is a goal, it's possible to go completely the other direction and just build a native binary (.NET AOT to native). Of course, it's not going to be cross-platform, you'll have to build binaries for each platform you target, but is very fast. Anecdotally it used to be as much as 2x faster than managed .NET Fable version, but recent improvements in F# compiler may have shrunk that difference somewhat. Here is the test project again if you want to tinker with it. |
@ncave I really appreciate your elaborate explanation, and the provided information truly helps me out. Yes, I know fable-raytracer. Thank you. Such a versatile, great testing project providing results that we exactly need to know. I've followed the discussion there. Quite interesting! Rust>WASM is the most successful manner and now the eco is huge. It has a superior performance and portability(small footprint), but here, the only problem for me is that I really don't want to code Rust. So I've found your work is extremely valuable. In fact, years ago, I asked you how you manage .net GC into non-GC Rust code, somewhere. In real-time systems like Drone, auto-pilot or space projects, where latency and predictability are critical, code with garbage collection (GC) like .NET can be problematic. Real-time systems require Rust code without GC.
So, I'm happy to hear the progress.
Thanks, that's what I thought. |
I want to clarify why I'm so interested in Fable working on JS/WASM, not on .NET. Recently, I found and studied VanJS: Reactive UI Framework without React/JSX. https://risingstars.js.org/2023/en#section-framework It is such a minimal clean implementation, and here is the live demo. It's just vanillaJS(VanJS named after this), no JSX, no compile. I was impressed by the simple design of VanJS. Then, thanks to Fable(such an astonishing hard work), I thought it easy to develop a thin F# wrapper/bridge for VanJS; that should be named VanFS.
After a few days of work, here is the module CounterApp
open Browser
open Browser.Types
open Fable.Core.JsInterop
open Van.Basic // import tags, add
open Van.MaterialComponents // import materialTags
open Van.Timeline // import Timeline
// use the identical tag names for the standard HTML tags
let h1: Tag = tags?h1
let span: Tag = tags?span
// any tag names can be defined for each material components
let filledButton: Tag = materialTags?``md-filled-button``
let Counter =
fun _ ->
let counter = Timeline 0
counter
|> bindT logT
|> ignore
span [
h1 [ "❤️ "; counter.el; ];
filledButton [{|onclick =
fun _ ->
counter
|> nextT (counter.lastVal + 1)|};
"👍"];
filledButton [{|onclick =
fun _ ->
counter
|> nextT (counter.lastVal - 1)|};
"👎"];
]
add [document.body; Counter()]
|> ignore Upcoming release of VanFS. Currently, people use
Alternatively, we use
The reason people feel more comfortable with JavaScript and TypeScript is its strong and seamless integration to the UI Ecosystem. However, if the Web UI relies on a simple function-based composition like VanJS, and ready-made components are easily imported as custom tags like Material Web Components, the web-developers no longer have to depend on JS/TS because the code becomes just for function calls based on tags(HTML standard/Web Components). The current situation can change. F# as an AltJS. Having said that, TypeScript is seamlessly included in NPM Eco. https://www.npmjs.com/package/typescript
then, I thought Fable was also the same. https://www.npmjs.com/package/@fable-org/fable-compiler-js
If a compiler is available as an NPM package, the setup process is simplified. Thanks to your elaborated answers, I now understand I hope @ncave finds this discussion interesting 😊 |
@ken-okabe I can't open https://github.com/vanjs-org/van right now for some reason, but nice to see another framework used with Fable, thanks for sharing! I see there is also this: https://www.npmjs.com/package/vanjs-component |
Thanks for all the information in this thread. Like @ncave I can't access the van repo right now, Github gives me a 404. 🤷♂️ But reading, through Van description here made me think about F# Sutil which is a pure F# framework to create web application without React, etc. I think it is based on how Svelte works but without needing a compilation phase other that Fable.
True, the main difference ATM is that TypeScript have it's binding on NPM too. While Fable, needs them to be on NuGet ATM. In the past, we had Fable + libraries distributed through NPM but the problem, is that then people are exposed to unusual ways of using F#. For example, instead of referencing a library using Which looked something like that (I don't exactly remember how it was written) <Compile Include="node_modules/my-fable-library/Fle1.fs">
<Compile Include="node_modules/my-fable-library/Fle2.fs">
...
<ProjectReference Include="node_modules/my-fable-library/Project.fsproj"> There are discussions in creating a custom target framework for Fable, which could perhaps changes things a bit. But now, we need to be backward compatible in anything we do IHMO otherwise it will break the ecosystem and I don't think it would be able to move it forward fast enough without loosing too many users etc. |
This is so weird. https://www.npmjs.com/package/vanjs-core |
@MangelMaxime |
https://vanjs.org/ On the top of page:
|
@ken-okabe Just out of curiosity, if VanJS is so small (just 140 lines of JS), do you even need to depend on it for VanFS, can't you directly generate vanilla JavaScript? |
I've released the first version of VanFS! @ncave
You're right. If it were a virtualDOM framework, I could probably build my own. After all, it's written in JavaScript, so instead of reinventing the wheel, I wanted to depend on the project. PS. Thanks a lot for your constant contributions to the Fable Rust! |
@ken-okabe Congratulations on the VanFS release! Yes, on second thought it makes sense to take an existing JS front-end framework as a dependency, to benefit from its ecosystem. |
Correct, and another aspect would be an advertisement/marketing 😉 Being recognized as an extension of a popular and highly trusted project such as VanJS would bring immense benefits in terms of raising awareness among many people about how great F# and Fable are. I personally believe that F# and Fable are truly amazing and would like to contribute in any way to spread. Actually, I contacted the author: Tao Xin and thankfully, had my project listed on the VanJS top page. I hope that as VanJS grows in popularity, the Fable-powered project will gain recognition among a wider audience! |
This should be fixed now |
Description
Fable and fable-compiler-js are astonishing projects/products.
According to the Changelog of fable-compiler-js, recently, the project status has achieved to stable.
I'm happy to see the stable version release and really appreciate your continued development.
I’m writing articles on F# and planning to introduce Fable. Especially, I observe that fable-compiler-js is promising as an AltJS solution with an easy setup using just Node.js, without the need for a .NET installation.
Here, I would like to request better support for fable-compiler-js.
README.md
The information:
looks outdated, and
although the installation succeeded, the
npx fable
command fails:fable-compiler-js package.json dependencies are broken #3793
After manual modification by myself,
npx fable
seems still unusable.$ npx fable --help
Repro code
https://github.com/fable-compiler/Fable/blob/main/src/fable-compiler-js/README.md
https://www.npmjs.com/package/@fable-org/fable-compiler-js
Expected and actual results
Better support for fable-compiler-js
Related information
@fable-org/fable-compiler-js
1.1.0
The text was updated successfully, but these errors were encountered: