-
-
-
SurveyJS
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.
-
-
temporal-polyfill
A lightweight polyfill for Temporal, successor to the JavaScript Date object (by fullcalendar)
-
-
quickjs-emscripten
Safely execute untrusted Javascript in your Javascript, and execute synchronous code that uses async functions
-
InfluxDB
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.
-
Graal
GraalVM compiles Java applications into native executables that start instantly, scale fast, and use fewer compute resources 🚀
I have not been able to get excited about WASM due to the poor memory management situation. It’s been years since the MVP and we are still in limbo about freeing memory.
A great issue documenting a lot of the pain points around this is here: https://github.com/WebAssembly/design/issues/1397
Until this is solved WASM is dead in the water for a huge variety of applications. I am rooting for WASM, but it has been discouraging to watch this go unsolved over the years.
Was watching your update in the Khronos Group meetup a few days ago, very impressive work. I'm excited for what this will mean for the web overall, it might finally reach that tipping point where more than .io games become standard to play in the web. That's huge, and will drive demand for more powerful web APIs too.
WebGPU in general is very nice. We're building a game engine[0] that uses Zig to build Dawn (Google Chrome WebGPU implementation) from source for running on desktop / Steamdeck, and working on browser support via WASM now.
The future is bright here.
[0] https://machengine.org
This assumes two things though, and this is another point I just realized about WASM that I like, which is for (most) modern browsers asm.js / WASM doesn't have to be polyfilled, therefore with Temporal we have to consider the following:
1. Browser support - its not there yet. you'd have to polyfill. A production level polyfill is 16 KB, and is still very nasacent, and, on top of that, requires support also for BigInt[0]. The polyfill that tc39 put out is decidedly marked as non-production ready[1].
2. Polyfilling - as mentioned above, we have to deal with polyfilling the API, and that isn't a clear and easy story yet. WASM support goes back farther than this.
3. Size - its entirely possible to get WASM builds under 16 KB, and the support is better, espcially for operations on strings and numbers (dates fit this category well). The only complication I haven't quite solved yet is:
A) Can I validate that a WASM build will be under 16 KB. This is crucial. I'd even accept it at 20 KB because of wider browser support[2]
B) Can I fall back to asm.js if needed (there is a slim range of browsers that support ASM.js but not WASM, mostly pre-chromium Edge[3]
C) Is it performant compared to something like Luxon or date-fns? WASM excels at string / numerical operations so my sneaking suspicion is yes, at least in terms of the WASM operations. The complexity will be serializing the operations to a JS Date instance, Luxon & the Intl API might be most useful here
[0]: https://github.com/fullcalendar/temporal/blob/main/packages/...
[1]: https://github.com/tc39/proposal-temporal#polyfills
[2]: https://caniuse.com/wasm
[3]: https://caniuse.com/asmjs
This assumes two things though, and this is another point I just realized about WASM that I like, which is for (most) modern browsers asm.js / WASM doesn't have to be polyfilled, therefore with Temporal we have to consider the following:
1. Browser support - its not there yet. you'd have to polyfill. A production level polyfill is 16 KB, and is still very nasacent, and, on top of that, requires support also for BigInt[0]. The polyfill that tc39 put out is decidedly marked as non-production ready[1].
2. Polyfilling - as mentioned above, we have to deal with polyfilling the API, and that isn't a clear and easy story yet. WASM support goes back farther than this.
3. Size - its entirely possible to get WASM builds under 16 KB, and the support is better, espcially for operations on strings and numbers (dates fit this category well). The only complication I haven't quite solved yet is:
A) Can I validate that a WASM build will be under 16 KB. This is crucial. I'd even accept it at 20 KB because of wider browser support[2]
B) Can I fall back to asm.js if needed (there is a slim range of browsers that support ASM.js but not WASM, mostly pre-chromium Edge[3]
C) Is it performant compared to something like Luxon or date-fns? WASM excels at string / numerical operations so my sneaking suspicion is yes, at least in terms of the WASM operations. The complexity will be serializing the operations to a JS Date instance, Luxon & the Intl API might be most useful here
[0]: https://github.com/fullcalendar/temporal/blob/main/packages/...
[1]: https://github.com/tc39/proposal-temporal#polyfills
[2]: https://caniuse.com/wasm
[3]: https://caniuse.com/asmjs
4. Speed
I'm hoping to write my thesis for my master's degree on this topic this year. I'm also in the process of writing a game like screeps, where users provide a WASM script to control units for an RTS-style game (without combat though) https://github.com/JMS55/botnet.
It's amazing how simple it is to constrain memory usage, runtime duration, and secure exported functions to a WASM VM. Performance is also great - currently about ~6 microseconds per tick per unit, up to ~200 microseconds when doing expensive pathfinding. All that, while letting you program your units in Rust - the same language as the server is written in, while being able to share code with the server, and not having to use something more script-y like lua.
This seems like a pretty nice, recently enabled way of getting a sandboxed js environment: QuickJS compiled to WASM: https://github.com/justjake/quickjs-emscripten.
For the client I use a simple go -> c++ compiler I wrote and compile to wasm from that actually. It had zero overhead interfacing to / calls to C/C++ (including generics<->templates) since it's just generating that. Example web game made with that: https://github.com/nikki93/raylib-5k
I think I've seen wasmtime before. If I needed to interface to any C/C++ things on the server I would probably just write in C/C++ (or Gx) yeah.