Plans for the standard library

[Risto-Stevcev]

What are the plans for the standard library? I had these suggestions/questions in particular:

• Completing existing libraries for Node, ie: Fs, Buffer, Process, Child_process, and Path
• Adding the other native node modules
• Adding the browser web apis. I know about bs-webapi-incubator. It's great and I use it all the time and I know it's not set in stone yet (incubating) -- I think the API is better suited to use poly variants because they unify nicely. But it would be nice to integrate this library into the stdlib. If it undergoes major changes then it can be part of a bucklescript major version bump. There's a lot in that library but a lot of web APIs are still missing, like websockets
• How can we contribute to the standard library? It seems like it's kind of a black box right now. I know the idea of keeping it inside bucklescript is to ensure that it's correct, but there's no guides or anything on how us devs can help complete the "batteries included". Some of these are very low hanging fruit, like adding more methods for 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.

[ryyppy]

@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.

[TheSpyder]

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.

[glennsl]

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.

[dangdennis]

@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"?

[baransu]

@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.

[ryyppy]

@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?

[bobzhang]

actually we are making some major progress in splitting compiler and stdlib, stay tuned

[BlueHotDog]

@bobzhang maybe worth adding this to the Roadmap if this is really planned, i think people will be interested.

[TheSpyder]

@BlueHotDog it’s already there, Bob promised it in 2020 quite a while ago
https://github.com/BuckleScript/bucklescript/wiki

[mweichert]

@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.

[TheSpyder]

I think he explained it best in this issue response. The Belt API review fiasco probably contributed.

[glennsl]

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 🙂

[TheSpyder]

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.

[stale]

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.