CoWasm: An alternative to Emscripten, based on Zig (demo: Python in the browser)

• cowasm

  8 465 3.9 C

  CoWasm: Collaborative WebAssembly for Servers and Browsers. Built using Zig. Supports Python with extension modules, including numpy.

  

I am using the Python ecosystem (with full support for dynamic loading of C extension modules) as an initial motivating project. Also, the Python test suite is extremely useful to root out problems. I certainly hope that this can provide a more complete alternative to Emscripten to the community eventually. That said, Emscripten is huge, and the problems involved in creating a more maintainable modular WASM build tool are subtle. For example, when implementing a custom module loader for Python-wasm last week, I discovered several bugs in the memfs and unionfs Javascript libraries (https://github.com/streamich/memfs/pulls?q=is%3Apr+author%3A... and https://github.com/streamich/unionfs/pulls?q=is%3Apr+author%...). I had to learn the code sufficiently to fix all these bugs, submit PR's, etc. Emscripten has its own analogue of memfs, which is optimized specifically for WebAssembly in the browser, where memfs is a more general widely used library (with 10M+ downloads/week).

CoWasm has no support for asyncify. Where I've run into setjmp/longjmp so far, I've been rewriting the code instead. E.g., the dash shell uses setjmp/longjmp, and I'm rewriting that to use return error codes instead (see, e.g., https://github.com/sagemathinc/dash/commit/7117e1f6496728af0...).

> how would I go about porting a simple C->WASM w/ Typescript library project to CoWasm?

That's a great question, which I'm not sure how to quickly answer, so I've created a discussion item here https://github.com/sagemathinc/cowasm/discussions/40

• JSage

  4 33 0.0 JavaScript

  Something like Sage, but for the WebAssembly and JavaScript world.

  

Yes, porting https://SageMath.org to the browser is part of the plan, and this is a key foundation for that. I ported some of the components of Sage (e.g., https://libntl.org/) already as part of https://github.com/sagemathinc/jsage, and I don't see any fundamental obstruction to porting all of Sage, except time. It would be great if once CoWasm is more stable, I can get some help porting some components to WASM.

• SurveyJS

  surveyjs.io featured

  Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.

  

• memfs

  3 1,618 9.4 TypeScript

  JavaScript file system utilities

I am using the Python ecosystem (with full support for dynamic loading of C extension modules) as an initial motivating project. Also, the Python test suite is extremely useful to root out problems. I certainly hope that this can provide a more complete alternative to Emscripten to the community eventually. That said, Emscripten is huge, and the problems involved in creating a more maintainable modular WASM build tool are subtle. For example, when implementing a custom module loader for Python-wasm last week, I discovered several bugs in the memfs and unionfs Javascript libraries (https://github.com/streamich/memfs/pulls?q=is%3Apr+author%3A... and https://github.com/streamich/unionfs/pulls?q=is%3Apr+author%...). I had to learn the code sufficiently to fix all these bugs, submit PR's, etc. Emscripten has its own analogue of memfs, which is optimized specifically for WebAssembly in the browser, where memfs is a more general widely used library (with 10M+ downloads/week).

CoWasm has no support for asyncify. Where I've run into setjmp/longjmp so far, I've been rewriting the code instead. E.g., the dash shell uses setjmp/longjmp, and I'm rewriting that to use return error codes instead (see, e.g., https://github.com/sagemathinc/dash/commit/7117e1f6496728af0...).

> how would I go about porting a simple C->WASM w/ Typescript library project to CoWasm?

That's a great question, which I'm not sure how to quickly answer, so I've created a discussion item here https://github.com/sagemathinc/cowasm/discussions/40

• unionfs

  1 200 6.8 TypeScript

  Use multiple fs modules at once

I am using the Python ecosystem (with full support for dynamic loading of C extension modules) as an initial motivating project. Also, the Python test suite is extremely useful to root out problems. I certainly hope that this can provide a more complete alternative to Emscripten to the community eventually. That said, Emscripten is huge, and the problems involved in creating a more maintainable modular WASM build tool are subtle. For example, when implementing a custom module loader for Python-wasm last week, I discovered several bugs in the memfs and unionfs Javascript libraries (https://github.com/streamich/memfs/pulls?q=is%3Apr+author%3A... and https://github.com/streamich/unionfs/pulls?q=is%3Apr+author%...). I had to learn the code sufficiently to fix all these bugs, submit PR's, etc. Emscripten has its own analogue of memfs, which is optimized specifically for WebAssembly in the browser, where memfs is a more general widely used library (with 10M+ downloads/week).

CoWasm has no support for asyncify. Where I've run into setjmp/longjmp so far, I've been rewriting the code instead. E.g., the dash shell uses setjmp/longjmp, and I'm rewriting that to use return error codes instead (see, e.g., https://github.com/sagemathinc/dash/commit/7117e1f6496728af0...).

> how would I go about porting a simple C->WASM w/ Typescript library project to CoWasm?

That's a great question, which I'm not sure how to quickly answer, so I've created a discussion item here https://github.com/sagemathinc/cowasm/discussions/40

• dash

  1 2 10.0 C

  Mirror of Debian Almquist shell https://git.kernel.org/pub/scm/utils/dash/dash.git without the autotools dependency (by sagemathinc)

  

I am using the Python ecosystem (with full support for dynamic loading of C extension modules) as an initial motivating project. Also, the Python test suite is extremely useful to root out problems. I certainly hope that this can provide a more complete alternative to Emscripten to the community eventually. That said, Emscripten is huge, and the problems involved in creating a more maintainable modular WASM build tool are subtle. For example, when implementing a custom module loader for Python-wasm last week, I discovered several bugs in the memfs and unionfs Javascript libraries (https://github.com/streamich/memfs/pulls?q=is%3Apr+author%3A... and https://github.com/streamich/unionfs/pulls?q=is%3Apr+author%...). I had to learn the code sufficiently to fix all these bugs, submit PR's, etc. Emscripten has its own analogue of memfs, which is optimized specifically for WebAssembly in the browser, where memfs is a more general widely used library (with 10M+ downloads/week).

CoWasm has no support for asyncify. Where I've run into setjmp/longjmp so far, I've been rewriting the code instead. E.g., the dash shell uses setjmp/longjmp, and I'm rewriting that to use return error codes instead (see, e.g., https://github.com/sagemathinc/dash/commit/7117e1f6496728af0...).

> how would I go about porting a simple C->WASM w/ Typescript library project to CoWasm?

That's a great question, which I'm not sure how to quickly answer, so I've created a discussion item here https://github.com/sagemathinc/cowasm/discussions/40

• graaljs

  17 1,625 9.9 C++

  A ECMAScript 2023 compliant JavaScript implementation built on GraalVM. With polyglot language interoperability support. Running Node.js applications!

  

That's just incredibly cool, my congratulations!

Foremost, my apologies if this is a nonsensical question. I haven't been soaking in the WASM ecosystem enough to know how much WASM is "just" JS versus ... something else.

Caveat aside, I saw one of the commits mention jython, which notoriously has ancient (and probably incredibly incomplete) python 2.x support; do you know if python-wasm would run on top of GraalJS (https://github.com/oracle/graaljs#nodejs-support)?

Separately, do you want issues related to zython.org in the cowasm issue tracker? It returns 405 (method not allowed) over and over on POST https://zython.org/python-wasm-sw/read-signal for me

• wajic

  6 181 0.0 JavaScript

  WebAssembly JavaScript Interface Creator

This is a slim alternative to Emscripten which focuses only on the C/C++ <=> JS interoperability part:

https://github.com/schellingb/wajic

• InfluxDB

  www.influxdata.com featured

  Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  

Suggest a related project