nodejs-polars
| nodejs-polars | proposal-zero-copy-arraybuffer-li | |
|---|---|---|
| 2 | 2 | |
| 313 | - | |
| 7.0% | - | |
| 8.4 | - | |
| 12 days ago | - | |
| TypeScript | ||
| MIT License | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
nodejs-polars
-
Using Deno with Jupyter Notebook to build a data dashboard
Polars: A blazingly fast DataFrame library written in Rust for data manipulation and analysis
- Goodbye, Node.js Buffer
proposal-zero-copy-arraybuffer-li
-
Goodbye, Node.js Buffer
Yeah, in your case I think most of the complexity is actually on the ReadableStream side, not the base64 side.
The thing that I'd actually want for your case is either a TransformStream for byte stream <-> base64 stream (which I expect will come eventually, once the simple case gets done), or something which would let you read the entire stream into Uint8Array or ArrayBuffer, which is a long-standing suggestion [1].
---
> Why does de-chunking a byte array need to be complicated
Keep in mind the concat proposal is _very_ early. If you think it would be useful to be able to concat Uint8Arrays and have that implicitly concatenate the underlying buffers, [2] is the place to open an issue.
---
> You have made me realize I don't even know what the right venue is to vote on stuff. How should I signal to TC39 that e.g. Array.fromAsync is a good idea?
Unfortunately, it's different places for different things. Streams are not TC39 at all; the right place for suggestions there is in the WHATWG streams repo [3]. Usually there's already an existing issue and you can add your use case as a comment in the relevant issue. TC39 proposals all have their own Github repositories, and you can open a new issue with your use case.
Concrete use cases are much more helpful than just "this is a good idea". Though `fromAsync` in particular everyone agrees is good, and it mostly just needs implementations, which are ongoing; see e.g. [4]. If you _really_ want to advance a stage 3 proposal, you can contribute a PR to Chrome or Firefox with an implementation - but for nontrivial proposals that's usually hard. For TC39 in particular, use cases are only really valuable pre-stage-3 proposals.
[1] https://github.com/whatwg/streams/issues/1019
[2] https://github.com/jasnell/proposal-zero-copy-arraybuffer-li...
[3] https://github.com/whatwg/streams
[4] https://bugs.chromium.org/p/v8/issues/detail?id=13321
What are some alternatives?
ibis - the portable Python dataframe library
WebGL-Fluid-Simulation - Play with fluids in your browser (works even on mobile)
arquero - Query processing and transformation of array-backed data tables.
proposal-zero-copy-arraybuffer-list - A proposal for zero-copy ArrayBuffer lists
falcon - Brushing and linking for big data
proposal-async-iterator-helpers - Methods for working with async iterators in ECMAScript
uint8array-extras - Useful utilities for working with Uint8Array (and Buffer)
proposal-array-from-async - Draft specification for a proposed Array.fromAsync method in JavaScript.
proposal-arraybuffer-base64 - TC39 proposal for Uint8Array<->base64/hex