emsdk | WASI | |
---|---|---|
39 | 45 | |
2,850 | 4,604 | |
1.3% | 1.7% | |
7.9 | 6.9 | |
4 days ago | 10 days ago | |
Python | Rust | |
GNU General Public License v3.0 or later | GNU General Public License v3.0 or later |
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.
emsdk
- Software Applications Incorporated
-
How does one get started with unit testing?
One place that I’ve found some real, open source unit tests to look at for an example is in the emsdk for emscripten: https://emscripten.org
-
godot 4.2 apksigner returned with error #2
Your default path was set by emsdk, given where the path is pointing. Your modified path is the path the installer linked in the Godot docs sets, just typically that kind of stuff doesn't override existing variables. This is a good thing to keep in mind in general as if you end up having to use a different version for something else in the future and just install it expecting the installer to update it for you, you will likely run into the same issue.
-
WebAssembly: Building GUI for C++ libraries with Embind
Emscipten C/C++ to WebAssembly compiler.
-
Playing with low-level memory in WebAssembly
I am playing around with Emscipten which wraps around clang to compile C/C++ code in WASM binary and provide some glue-code API to embed WASM binary into JavaScript. Look into MDN Docs and Emscripten SDK to get started.
-
Is there any alternative other than JavaScript to deal with web frontend?
Elm is a different approach that compiles into JavaScript. In the extreme case, you have Emscripten which will compile many language into JavaScript but will feel really clumsy compared to using JavaScript in a lot of cases.
-
What's the "modern" way of creating a native addon for Node.js?
https://emscripten.org/ ?
-
SQLite builds for WASI since 3.41.0
SQLite is a pretty popular database and it's a critical dependency for many different applications. By compiling it to Wasm32-wasi, you can add it to any WebAssembly module.
This enables a new set of possibilities for Wasm and SQLite. For example, now you can run a full WordPress application in the browser [1][2] / server [3] using the same Wasm module. Note that for the browser these projects use Emscripten [4], but in the future the same Wasm32-wasi module will work.
In general, any environment that includes a wasm runtime can potentially run applications that uses SQLite under the hood. Before, it wasn't possible.
- [1] https://wordpress.wasmlabs.dev/
- [2] https://developer.wordpress.org/playground/demo/
- [3] https://wasmlabs.dev/articles/running-wordpress-with-mod-was...
- [4] https://emscripten.org/
-
Noob question: Between WebGL, OpenGL ES and emscripten, what is the recommended usage and relationship between them for creating an interactive browser based graphics app?
The emscripten interface for the assimp library. It runs entirely in the browser, and allows you to import 40+ 3D file formats and access the result in JSON or glTF format. This is not a full port of assimp, but an easy to use interface to access it's functionality.
-
Website with Godot?
Three.js is written in JS and loads like a JS library on a modern website. Godot is a binary application transpiled to WASM (with the help of emscripten), resulting in a pretty large initial payload. Godot provides JS integration, but it feels less "native" with its layers of abstraction.
WASI
-
WASI 0.2.0 and Why It Matters
WASI Co-chair here. Nothing in WASI is "somehow blocked by Google", or indeed blocked by anyone at all. Graphics support in WASI hasn't been developed simply because nobody has put energy into developing graphics support in WASI.
At the end of 2023 we counted around 40 contributors who have been working on WASI specifications and implementations: https://github.com/WebAssembly/meetings/blob/main/wasi/2023/... . That is a great growth for our project from a few years ago when that issue was filed, but as you can see from what people are working on, its all much more foundational pieces than a graphics interface. Also, if you look at who is employing those contributors, its largely vendors who are interested in WASI in the context of serverless. That doesn't mean WASI is limited to only serverless, but that has been the focus from contributors so far.
By rolling out WASI on top of the WASM Component Model we have built a sound foundation for creating WASI proposals that support more problem domains, such as embedded systems (@mc_woods and his colleagues are helping with this), or graphics if someone is interested in putting in the work. Our guide to how to create proposals is found here: https://github.com/WebAssembly/WASI/blob/main/Contributing.m... .
- WASI Launching Preview 2
-
Missing the Point of WebAssembly
> As I understand it, it's not even really possible today to make WebAssembly do anything meaningful in the browser without trampolining back out to JavaScript anyway, which seems like a remarkable missed opportunity.
That's the underlying messy API it's built on. There are specs to make the API more standardized like https://github.com/WebAssembly/WASI
But overall, yeah, it feels like a shiny new toy everyone is excited about and wants to use. Some toys can be fun to play with, but it doesn't mean we have to rewrite production systems in it. Sometimes, or most of the time, toys don't become useful tools.
-
Running WASI binaries from your HTML using Web Components
Snapshot Preview 1 is the standard all tools are building to right now. The specification is available here: https://github.com/WebAssembly/WASI/blob/main/legacy/preview...
It's pretty unreadable though!
Preview 2 looks like it will be a big change, and is just being finalised at the moment. I'd expect that when preview 2 is available there will be an improvement in the quality of documentation. I'm not sure how long it will take after release for tools to start switching to it. I'd expect Preview 1 will still be the main target at least for the rest of this year.
-
WASI: WebAssembly System Interface
> Like WTF does this mean? The repo tells me nothing
Directly above the sentence you quoted:
"Interposition in the context of WASI interfaces is the ability for a Webassembly instance to implement a given WASI interface, and for a consumer WebAssembly instance to be able to use this implementation transparently. This can be used to adapt or attenuate the functionality of a WASI API without changing the code using it."
> and I've still yet to see a clear write-up about what WASI is.
In the same document: [0]
> WTF is wit?
The first link in that document ("Starting in Preview2, WASI APIs are defined using the Wit IDL.") is [1].
> I click on "legacy" and I see preview0 and preview1, which are basically unreadable proto-specs.
The README for the legacy directory [2] clearly explains what they are.
> Where's a single well-written WASI spec?
"Development of each API happens in its own repo, which you can access from the proposals list." [3]
> Whatever WASI is doing, I don't like it.
Clearly not - you've gone out of your way to ignore all of the documentation that answers your questions.
> And neither does AssemblyScript team apparently
The AssemblyScript team have a bone to pick with WASI based on their misunderstanding of what WASI is for (it is not intended for use on the web) and WASI's disinterest in supporting UTF-16 strings. You can see for yourself in [4].
[0]: https://github.com/WebAssembly/WASI/tree/main#wasi-high-leve...
-
A Gentle Introduction to WebAssembly
The Bytecode Alliance initiated a sub-project called the WebAssembly System Interface (WASI). WASI is an API that allows WebAssembly access to system features such as files, filesystems, Berkeley sockets, clocks, and random numbers. WASI acts as a system-level interface for WebAssembly, so incorporating a runtime into a host environment and building a platform is easier.
-
Spin 1.0 — The Developer Tool for Serverless WebAssembly
We are excited to contribute back to Wasmtime and the component model, as well as to new projects and proposals emerging in this space (such as new Wasm proposals, like WASI Preview 2, wasi-keyvalue, wasi-sql or wasi-cloud).
-
The Tug-of-War over Server-Side WebAssembly
I've been reading the following repositories.
https://github.com/WebAssembly/WASI/blob/main/Proposals.md
What are some alternatives?
pyscript - Try PyScript: https://pyscript.com Examples: https://tinyurl.com/pyscript-examples Community: https://discord.gg/HxvBtukrg2
.NET Runtime - .NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
itk-wasm - High performance spatial analysis in a web browser, Node.js, and across programming languages and hardware architectures
webgpu-wgsl-hello-triangle - An example of how to render a triangle with WebGPU using WebGPU Shading Language - the "Hello world!" of computer graphics.
website - WebAssembly website
threads - Threads and Atomics in WebAssembly
webaudio-examples - Code examples that accompany the MDN Web Docs pages relating to Web Audio.
wasi-libc - WASI libc implementation for WebAssembly
tictactoe-game-wasm - This is a simple example for creating your first game in web assembly. The logic for this tic-tac-toe game is written in C++.
node-sqlite3 - SQLite3 bindings for Node.js
CLI11 - CLI11 is a command line parser for C++11 and beyond that provides a rich feature set with a simple and intuitive interface.
gpuweb - Where the GPU for the Web work happens!