Skip to content
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

Automatic bundling/dev server? #2423

Closed
alfonsogarciacaro opened this issue Apr 1, 2021 · 3 comments
Closed

Automatic bundling/dev server? #2423

alfonsogarciacaro opened this issue Apr 1, 2021 · 3 comments

Comments

@alfonsogarciacaro
Copy link
Member

alfonsogarciacaro commented Apr 1, 2021

So far, Fable has tried to be a bridge between F# and JS ecosystems. And as such, it didn't try to do too much and instead let the user pick their JS tools to bundle, debug the frontend, etc... However, since Fable 3 moved to a be a "pure" dotnet tool and with the appearance of libraries that don't require npm dependencies like Sutil or Elmish.Snabbdom (or even React if you use it from a CDN) it may be helpful particularly for newcomers if Fable could do (or at least invoke) the basic operations to write the frontend of a web app: bundling and dev server. For that we would include new CLI args like --serve and/or --bundle.

Writing our own bundler is out of hand. At first I thought we could embed a bundler in the Fable package, but probably it's easier to just create a hidden .fable-tools dir, install there the needed tools with npm and invoke them as necessary. The ideal would be to rely on a bundler with good defaults but that can be customized if necessary. The question is, what bundler to use?

  • Webpack: the most extended and probably the preferred option when user needs to customize. Defaults won't likely be enough but we could generate an automatic webpack.config and if necessary let the user customize it. If I'm not mistaken that's how create-react-app works.
  • Parcel: this would be a very good candidate, as it has many good defaults, but they seem to be stuck in the v2 upgrade forever.
  • Rollup: we've used it sometimes in Fable for its ease of use, but recently I find it lacking and difficult to customize, particularly the dev server.
  • Other? I've lost track of the new bundlers like Snowpack or whatever they are called now 😅

Any opinions? Remember this will only be optional and users will still be able to choose any other bundler as it's now.

@MangelMaxime
Copy link
Member

I don't think this is a good idea. It will made the boundary between F# and JavaScript world blur again. Similar to how it was in Fable 2 where people had a hard time understanding what was responsible for what.

Fable 3 is awesome because once you have called Fable to generate the JavaScript files then you are in JavaScript world directly. So you can find all the documentation you want on the subject made by the JavaScript community.

I would largely prefer a well made documentation explaining how Fable 3 work start and stop (compiling F# to JS) and then explain to the people from here you can use the tool you prefer. And have documentation simple documentation explaining how to do it and then to delegate the explanation to the chosen tool documentation.

IHMO, people need to understand the ecosystem they are working in/with. Yes, for really simple showcase you can ignore how JavaScript works and so on. But, soon enough you will need to understand the big picture in order to be able to write your application.

If we were in a similar position as languages that control 100% of their pipeline and ecosystem like Elm I would think differently.


For the same reason, I prefer to use concurrently to invoke Fable and the JavaScript bundler side by side. Instead of making Fable invoke the JavaScript bundler.

It is not much, but it "shows" that they are working side by side without magic. When we run dotnet fable --run XXX it is not clear that the command will only be executed once even if you are in watch mode.

IHMO, it is in all this minor details that we can gain clarity/transparency of how things works/operates.

@ncave
Copy link
Collaborator

ncave commented Apr 1, 2021

My personal opinion, as expressed in past discussions on the topic, is that it makes a lot of sense to adopt and stay within the design goals that other transpilers like TypeScript also have, especially the "non-goals" section (i.e. the "we don't want to do that" section), and on this particular topic, the closest "non-goal" is number 4.

@alfonsogarciacaro
Copy link
Member Author

You're right. This is probably one of the things I get excited about and regret afterwards 😅 Ok, let's close this. Now that things are becoming more stable, the way to make things simpler for newcomers is to improve the templates 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants