parquet-wasm
proposal-array-from-async
| parquet-wasm | proposal-array-from-async | |
|---|---|---|
| 6 | 7 | |
| 464 | 172 | |
| - | 2.3% | |
| 9.0 | 6.6 | |
| 3 days ago | 4 months ago | |
| Rust | HTML | |
| Apache License 2.0 | BSD 3-clause "New" or "Revised" 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.
parquet-wasm
- FLaNK AI Weekly for 29 April 2024
- Parquet-WASM: Rust-based WebAssembly bindings to read and write Parquet data
-
Goodbye, Node.js Buffer
nodejs-polars is node-specific and uses native FFI. polars can be compiled to Wasm but doesn't yet have a js API out of the box.
As for the fastest way to serialize data to Pandas data to the browser, you should use Parquet; it's the fastest to write on the Python side and read on the JS side, while also being compressed. See https://github.com/kylebarron/parquet-wasm (full disclosure, I wrote this)
-
Rust 1.63.0
I'm building WebAssembly bindings to existing Rust libraries [0] and lower-dependency geospatial tools [1]. Rust makes it very easy to bind rust code to both WebAssembly and Python. And by avoiding some large C geospatial dependencies we can get reliable performance in both wasm and Python using the exact same codebase.
[0]: https://github.com/kylebarron/parquet-wasm
[1]: https://github.com/kylebarron/geopolars
- Why isn’t there a decent file format for tabular data?
-
Recommendations when publishing a WASM library
Looks to be a great resource. I've been working on a WASM implementation of reading and writing Apache Parquet [0] and it's been difficult being new to WASM to find the best way of distributing the WASM that works on Node and through bundlers like Webpack.
[0]: https://github.com/kylebarron/parquet-wasm
proposal-array-from-async
- Goodbye, Node.js Buffer
-
How async/await runs inside forEach, and why it probably doesn't do what you expect
Others have mentioned for await, which probably isn't ideal in the case of getting users by id since it'll only do one request at a time, which is less efficient. There's a proposal for Array.fromAsync() that'll essentially do the same thing...
-
Updates from the 92nd TC39 meeting
Array.fromAsync: Array.fromAsync is to for await as Array.from is to for.
-
New ECMAScript 23 array features
The proposal is described here.
-
Getting async data using map arrow method
It's only a stage 2 spec, but Array.fromAsync() would handle exactly what you want. Polyfill exists too.
-
Updates from the 87th meeting of TC39
Array.fromAsync: Like Array.from but it converts an async iterable (or a sync iterable of promises) to a promise that will resolve to an array.
-
Updates from the 85th meeting of TC39
Array.fromAsync Like Array.from but for async iterators.
What are some alternatives?
datasette-stripe - A web SQL interface to your Stripe account using Datasette.
proposal-class-static-block - ECMAScript class static initialization blocks
quickjs-emscripten - Safely execute untrusted Javascript in your Javascript, and execute synchronous code that uses async functions
proposal-relative-indexing-method - A TC39 proposal to add an .at() method to all the basic indexable classes (Array, String, TypedArray)
transmitic - Encrypted, peer to peer, file transfer program :: https://discord.gg/tRT3J6T :: https://www.reddit.com/r/transmitic/ :: https://twitter.com/transmitic
streams - Streams Standard
geopolars - Geospatial extensions for Polars
nodejs-polars - nodejs front-end of polars
odiff - The fastest pixel-by-pixel image visual difference tool in the world.
proposal-extractors - Extractors for ECMAScript
rson - Rust Object Notation
proposal-arraybuffer-base64 - TC39 proposal for Uint8Array<->base64/hex