-
Notifications
You must be signed in to change notification settings - Fork 293
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
Comments
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 It is not much, but it "shows" that they are working side by side without magic. When we run IHMO, it is in all this minor details that we can gain clarity/transparency of how things works/operates. |
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. |
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 👍 |
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?Any opinions? Remember this will only be optional and users will still be able to choose any other bundler as it's now.
The text was updated successfully, but these errors were encountered: