temporal-polyfill VS memory64

There's another, much smaller polyfill: https://github.com/fullcalendar/temporal

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

A completed implementation of memory64 for memory-hungry applications.

Indeed, webassembly is moving extremely slowly. I started a project years ago expecting https://github.com/WebAssembly/memory-control/blob/main/prop... and https://github.com/WebAssembly/memory64 to be fixed at some point. Neither are yet, and the project still suffers from it to this day.

I think wasm is still great without these fixes, but I have lost confidence in the idea that wasm will reach its full potential any time soon.

It's in the works: https://github.com/WebAssembly/memory64

Starting with 32bit had some performance advantages because 64bit runtimes can use virtual memory shenanigans to implement bounds checking with zero overhead. In wasm64 they'll have to do explicit bounds checking instead.

Right - currently, everything runs using WASM (32-bit, with 64-bit coming soon [1,2]), and I plan to add support for WebGPU soon!

(WebGPU is the successor to WebGL, which is coming out in April 2023 [3])

[1] https://github.com/WebAssembly/memory64/issues/36#issuecomme...

It shouldn't be a big surprise that a 64-bit pointer extension is out there and being worked on. The great thing about a VM is you can integrate major changes like this when they are needed and with the benefit of experience and hindsight. If the 4GB limit turns out to be restrictive then it can be lifted.

The goal of this proposal is to increase the amount of memory that canisters can access [eventually] bound only by the actual capacity of the subnet. Since, the Memory64 proposal is not standardized 1 yet and its implementation 1 in Wasmtime is not production ready yet, this proposal enables the increase by introducing a new stable memory API.