Repository navigation
Fable 3: Remove Babel dependency? #2109
Description
Not sure if we should go down this rabbit hole, but I've been thinking several times to remove the Babel dependency and the release of Fable 3 could be an opportunity for it.
Motivation
When Fable was born, it used modern JS features (particularly the module system) that weren't supported by most browsers. thanks to Babel we could output different code depending on the environment. However, now JS modules are very extended and the JS features we use are supported for most JS engines. In principle, it "shouldn't" be too difficult to create our own JS printer and remove the Babel dependency.
Benefits
- More control.
- Pure netcore app (it seems MSFT finally fixed tool installation with dotnet SDK so we could use Nuget again for distribution).
- Less overhead. Babel is quite fast, but removing the JSON serialization, the interop, etc, should speed up things. Also, it would make the REPL less fat and maybe make it easier to embed it in other webs.
Drawbacks
- We will still need JS interaction for bundling with Webpack (hopefully it won't require much work because the TCP server is still in place).
- Users may still need Babel when targeting older browsers like IE.
- Even when compiling for Node, if we want commonjs modules we need either to add an extra Babel step or enable commonjs output in Fable (or rely in Node experimental ES module support).
- Source maps. This will likely be the biggest hurdle as Babel is generating the source maps for us right now. See below.
Alternatives to source map generation
- Disable them. It's difficult to get them right anyways (especially with computation expressions) so we may better focus the efforts in outputting more readable JS (and fulfill the original promise) that it's easier to debug.
- The best library for source map generation seems to be this one which is in JS, so we could spawn a node process to call it. But this will likely brings us to the same situation we have with Babel.
- Translate the parts we need from https://github.com/mozilla/source-map to F# (it doesn't seem to be a lot of code).
The only library I've found to produce source maps in .net is this one but it's quite old and maybe not reliable.
Yay or not yay? @ncave @MangelMaxime @Zaid-Ajaj @forki
Activity
ncave commentedon Jun 26, 2020
@alfonsogarciacaro I'm on the yay side.
forki commentedon Jun 26, 2020
MangelMaxime commentedon Jun 26, 2020
I think it is a good idea personally I never use the source-maps. I always disabled them because at the time it was making compilation slower.
I prefer to debug the JavaScript in general if I have a problem and if the readability it will be even easier.
SCullman commentedon Jun 26, 2020
The need for source maps depends on whether the generated javascript code will be readable and still easy to map with the F# source using our brains.
alfonsogarciacaro commentedon Jun 26, 2020
I do debug with source maps quite often, but it's true I have a deeper understanding of what transformations are being done. Well, let's disable the source maps temporarily (but keep the location info to add them later if necessary) and work on #2087 and the printers to get readable JS 👍
ncave commentedon Jun 27, 2020
+1
Shmew commentedon Jul 21, 2020
How would this work if a library wants to use an es6+ feature after this change? Like @Zaid-Ajaj mentioned here, there are cases where we may still want to use more advanced JS features.
alfonsogarciacaro commentedon Jul 22, 2020
Do you mean if users want to emit or reference JS with advanced features from F#? In that case, they can keep Babel in the pipeline to translate JS to something that's compatible with more browser as it's now: https://github.com/fable-compiler/webpack-config-template/blob/44ca14c1959d4474a23d7ec49958c06494c4f984/webpack.config.js#L140-L147
Shmew commentedon Jul 22, 2020
Yeah, but if it's a library that wants to do this, how would that be handled? Would they need to ensure that the user runs it through Babel?
alfonsogarciacaro commentedon Jul 22, 2020
Well, yes. But this is what is already happening. Note that Fable only uses Babel to translate the AST into JS code but it doesn't set any plugin (except for a couple of custom ones) or set any target by itself. It will spit out JS as it finds it. Right now, if users want to translate modern JS to more widely supported code they need to config that themselves: https://github.com/fable-compiler/webpack-config-template/blob/44ca14c1959d4474a23d7ec49958c06494c4f984/webpack.config.js#L28-L41
Shmew commentedon Jul 22, 2020
Okay I think I understand. Sounds like it's all good then.
OnurGumus commentedon Sep 14, 2020
We develop commercial apps with Fable and I do use source maps for debugging. It's essential to me.
alfonsogarciacaro commentedon Sep 15, 2020
It's likely that Fable 3 will ship initially without F# source map support (we're trying to compensate that with more readable JS output) but the infrastructure to generate them is still in place. As Fable 3 is a "pure" dotnet app, we need a dotnet library to generate the source maps but we couldn't find any that meets our needs. The easiest way it's probably to translate the low-level API of this JS library to dotnet (either F# or C#). It'd be great if the community could help with that.
alfonsogarciacaro commentedon Sep 15, 2020
BTW, this issue should be resolved after removing the Babel dependency in nagareyama, so let's close it. I will write a new one to bring source maps 👍