rust-ul

1. Valid point. 2. ? 3. Chrome (or more specifically CEF -- Chromium Embedded Framework, the one used by Spotify et al.) is significantly more heavy than UL. Memory use is massive. Google doesn't care about API stability and ABI breakage is so common you'll have to keep up with all API changes (the ones published and documented anyway...) to get anything done. Good luck embedding Servo! 4. ARM support is coming. --- > the others are 'community maintained'. Whatever that means. I maintain the Rust binding to Ultralight [0] via the CAPI to provide an ergonomic way for people to work with it. Adam is busy improving Ultralight itself, so I find it worthwhile to maintain it. That's what it means. [0] https://github.com/psychonautwiki/rust-ul

Wow this is great. > https://forum.ultralig.ht/t/community-language-bindings/20 ``` Several awesome members of our community have created bindings for other languages! Check them out below: C# – https://github.com/ImpromptuNinjas/UltralightSharp 104 Rust (High Level) – https://github.com/psychonautwiki/rust-ul 21 Rust (Low Level) – https://github.com/psychonautwiki/rust-ul-sys 7 Java – https://github.com/Janrupf/ultralight-java 10 Go (High Level, Framework) – https://github.com/ImVexed/muon 22 Go (Low Level)-- https://github.com/raff/ultralight-go 19 Let me know if I’m missing any and I’ll add it to this sticky!```

Interestingly this is very similar to how I implemented passing closures into JavaScriptCore as hooks for JS class invocations ("function calls"). [0] Essentially it's taking advantage of the fact that closures are static methods with "implicit" data pointers. It should be fairly obvious that this is a massive violation of safety and undefined behavior, and most likely to break when debugging symbols etc. are inserted. The safest way to do this until Rust has figured out a stable-enough-ABI for closure passing would be a thread-local trampoline, I guess. Not very nice.. [0] https://github.com/psychonautwiki/rust-ul/blob/master/src/he...