Closed Risto-Stevcev closed 2 years ago
@Risto-Stevcev IMO they should completely remove the Node
, Child_process
etc. apis from bucklescript and do the opposite: Put everything in properly curated packages.
In flowtype, the React bindings were included in the flow repo, which made it incredibly hard to fix version problems, since there was only one version that was supported. It caused immense vendoring problems - Irregular releases and no way to override the internals caused huge churn in the community. Using different version of independent packages is way easier. I could use a package which was made for Node v10, or whatever node version I need.
In case of the bs-webapi-incubator
, I often just want to use one simple thing, not a huge abstracted mess, so I copy paste the parts I need and make it as concrete as possible. Imposing this huge abstracted APIs on the common community would be a burden. Nobody on the bucklescript team has time to review this, neither would the documentation team.
I don't see how a few npm install
commands are a problem in that regard? The namespaces for Js
and Belt
are a different story, but even there, Belt is planned to be extracted from BuckleScript so ppl can use BS generated JS without installing bs-platform
as a dependency in their plain JS projects.
I agree wholeheartedly these things should be separate from the platform, but it would be nice if the things @Risto-Stevcev were created as (or moved to become) official projects.
For example, it's not clear what is required for bs-webapi
to graduate from the incubator stage; there's no plan, no apparent changes in progress other than merging PRs.
For bs-webapi
I think @chenglou's plan has been to move individual APIs into bs-platform
when they're mature enough, i.e. unlikely to change much. APIs like Js.Global
, Dom.Storage
and the Dom
types have been moved out of bs-webapi
and into bs-platform
for this reason.
I think Js.Global
belongs in bs-platform
because it's part of the JavaScript platform. It's also very convenient to have a canonical set of Dom
types for interoperation between libraries. But Dom.Storage
probably should have been made a separate library.
As for the future, I'll keep maintaining bs-webapi
and accepting PRs, but don't have any other plans for it, since the direction the BuckleScript ecosystem took a while ago has made me lose interest in working with it.
@ryyppy @glennsl If we'd like to see a push for curating community approved bindings of official APIs right now in Node or web apis, where can we start? Hit up the reason bucklescript channel with a working repo? Ask a community "leader"?
@ryyppy is there any active efford for extracting Belt into separate package? There is a lot of functionality that could be implemented but I’m not sure if its good time when Belt is part of this repo and release process is coupled with bs-platform.
@baransu Afaik there is no active work on that right now. Building the belt files is rather easy with the playground building workflow, but we'd need some more context on how the belt package would be used. Maybe we can open up a new issue discussing this?
actually we are making some major progress in splitting compiler and stdlib, stay tuned
@bobzhang maybe worth adding this to the Roadmap if this is really planned, i think people will be interested.
@BlueHotDog it’s already there, Bob promised it in 2020 quite a while ago https://github.com/BuckleScript/bucklescript/wiki
@glennsl
since the direction the BuckleScript ecosystem took a while ago has made me lose interest in working with it.
Would you elaborate what you're referring to, please? For me, bs-webapi and ReScript go hand-in-hand.
I think he explained it best in this issue response. The Belt API review fiasco probably contributed.
Yeah that's certainly a significant part of it. But I'd like to emphasize that it isn't so much that I disagree with these decisions (I usually don't, at least not to this degree), but that I strongly object to how they are made. I left because I no longer trust the (self-appointed) leadership of the project to take it in a direction that's sustainable long term and doesn't suddenly veer off in some other direction. They've demonstrated many times now that they have little regard for anyone but themselves and a small clique of insiders, and that they'll suddenly and unexpectedly change direction and cause deep splits in the ecosystem and community. Most recently with the new syntax, developed in secret with some controversial decisions that left many users feeling like they've been dumped with no explanation or acknowledgment of the consequences on the users that most rely on them.
Unfortunately it doesn't seem like the situation is improving, or going to improve, and so despite all I've invested in the ecosystem, I still don't regret leaving and think it's very unlikely that I'll return. Fortunately, however, @yawaramin has taken over the reins on bs-webapi
now and seems to be doing a great job with it, so I don't think it matters much what I think in any case :slightly_smiling_face:
That's about where my head is at too. I wasn't as upset as you at the time, but the ReScript changes have made me fairly unhappy.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
What are the plans for the standard library? I had these suggestions/questions in particular:
Node
, ie:Fs
,Buffer
,Process
,Child_process
, andPath
Buffer
as an example.I think It would make the bucklescript/reason story even more convincing. The bucklescript FFI is thankfully incredibly easy to work with and produces idiomatic JS code, but it does slow me down at least if I need to do this a lot when these things aren't available.