fable-compiler
Add Brower.Minimal
I noticed that a lot of the time spent loading the REPL was dedicated to read assemblies and Fable.Import.Browser was the biggest one by large (probably due to the amount of types included and the numerous Emit attributes). For the latest release of REPL I've compiled a special version of the Browser bindings (this PR) by removing many types and overloads. And this seems to have reduced the load time by half!
However for the near future I'd like to be able to reference the source of any library from the REPL, because the current way requires severals and has limitations. For this, we'd have to align the Browser bindings in the REPL with the version used in the libraries. Maybe the best way is to split the library in different Browser APIs (SVG, CSS, Web Audio, Intl, Canvas 2D, Canvas WebGL) so libraries only need to reference the parts that they actually use.
What do you think? Can it be useful or would complicated maintenance too much (the Typescript declaration is just a single file)? Or maybe it can encourage contributors to take care of smaller packages (as discussed in #69)?
@ncave @et1975 @MangelMaxime @Zaid-Ajaj @Nhowka @nojaf
Yes, multiple packages for Fable.Browser please!!! Incrementally adding and supporting API's in other packages that reference Fable.Browser with idiomatic F# code (not just ts2fable output because of poor experience, think int vs. float)
So do you still intend on mapping .d.ts files to F# using ts2fable?
If this is the case, would you split it up manually after execution? Each file then lives its own life? We fix things manually and never look back to ts2fable?
I'm in favor of multiple packages but we will need some documentation then I believe. Now there is no documentation and I use 'Ctrl + F' on the Github source page.
Not having that, it is hard to tell where to find what type.
Where is localStorage for example? Seriously, not in Fable.Import nor in Fable.Core.
I like the idea, I also like the naming that makes it obvious what it contains. Svg, WebGL, etc are great and self-explanatory, I'm not sold on "minimal", can this be scoped better somehow?
You're right @Zaid-Ajaj. My original idea of "pure" import bindings (only .dll) vs helpers is not working very well ;) so having smaller files where maintainers/users have more freedom to add idiomatic code is probably the way to go.
@nojaf I guess it will be a mix of ts2fable and manual tweaking. We can use the MDN WebApi classification as a guide. Unfortunately we'll have to manually extract the interfaces from dom.d.ts, convert them and then do the manual tweaks. But hopefully it's not too much work.
Interesting, I thought localStorage was in Fable.Import.Browser 😅 But you have a very good point, this is something to take into account when tackling https://github.com/fable-compiler/fable-compiler.github.io/issues/32
@et1975 Yes, this PR was just to generate the latest REPL library and to start the discussion. We can have better naming and probably drop the "Import" part. Should we create a new repo for all WebApi related bindings (and maybe prefix them like Fable.WebApi.WebGL)? Or just create a different repo for each API?
Fable.WebApi.WebGL does remind me a lot of that other web api thing. Might be a confusing name for newcomers. I do like the breakdown on mdn.
Having them split could even help maintenance because parsing the big file is a lot. I had plans to work on some PWA specific things and couldn't because the editor became unbearably slow.
Maybe having a meta package depending on all subset packages to keep the experience as it is could be nice to have.
