3 ms·

I agree with this. One string use case I’ve seen is number crunching. Doing complex math via WASM is fast and predictable and supports a wider variety of float

I agree with this. One string use case I’ve seen is number crunching. Doing complex math via WASM is fast and predictable and supports a wider variety of float / integer types. Another use case I’ve toyed with is date time. Specifically trying to figure out if something like the rust Chronos crate is a better fit for crunching and calculating dates than something like date-fns or Luxon. Not sure about this one yet.

zamadatix 4y ago
With Temporal on the horizon I wouldn't bother. Even if Temporal doesn't do what you want wrapper libraries that do will be very lightweight in the crunching regard https://tc39.es/proposal-temporal/docs/cookbook.html#arithmetic https://tc39.es/proposal-temporal/docs/cookbook.html#arithme...
- no_wizard 4y ago
  This assumes two things though, and this is another point I just realized about WASM that I like, which is for (most) modern browsers have asm.js / WASM support, and it goes back much farther than Temporal. 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/temporal-polyfill/README.md https://github.com/fullcalendar/temporal/blob/main/packages/... [1]: https://github.com/tc39/proposal-temporal#polyfills https://github.com/tc39/proposal-temporal#polyfills [2]: https://caniuse.com/wasm https://caniuse.com/wasm [3]: https://caniuse.com/asmjs https://caniuse.com/asmjs
  - zamadatix 4y ago
    Yeah if you need something ready for prod by a literal next month or something Temporal definitely isn't it as the API isn't locked yet. Don't forget WASM doesn't provide direct access to any OS time APIs (timezone info, current time, regional time change modifications) so the solution will still basically boil down to "call Date() and polyfill a better library" except now you have extra code to ferry the data back and forth to do a few string and math ops. Unless the use case is processing very large datetime datasets in one call the JS<->WASM function call overhead for all of this will probably take the majority of the execution time. Not to mention after you get all of this solved, tested, and deployed you know as soon as Chrome starts shipping Temporal the cool custom solution becomes 50% slower for the average user despite all the effort because you didn't just use something like a Luxon which automatically updated to use Temporal on release. This may just be me being lazy though :p.
    - no_wizard 4y ago
      Even if Temporal ships tomorrow, its minimum 5 years for most applications to take advantage of it, so you're either polyfilling with feature detection or waiting it out using libraries like `date-fns` or `luxon` to fill the gap. strings & numbers are WASMs strong point, so if you can pack the locale information tightly in a binary format, you might actually win out in the medium term. This shouldn't be a years long project by any means. And frankly, with the way enterprises move, you'll always have some client (at least in my business) where I need to support some modernish browser that may not have Temporal, so if this is more performant (we do alot of date time datasets, so yes, thats part why I'm looking at this) why not? It could also be the wrong solution. I'll found out one way or another.
      - zamadatix 4y ago
        Just the IANA timezone database is ~400 KB gzipped for the data only and it's really quite the project to actually parse correctly. With that you'll still need to ferry Date(), Intl(), and friends for getting the current info about the user into the WASM module. Only then can you actually start talking about the code which competes with the 20 KB JS polyfill which started with all of the above as precompiled native code and data. WASMs strong point isn't necessarily "strings and numbers" it's running large amounts of compiled code on large amounts of data. Video processing, PDF readers, video games. As an example even computing a large image the Mandelbrot fractal (pure math workload) then passing back an arraybuffer of the pixels was faster in JavaScript until WASM SIMD+Threads finally landed and JavaScripts poor parallelism finally factored in. Doing it with a functional call per pixel JavaScript is still ahead of even WASM with SIMD due to the functional call overhead. But all that said I think it's a really cool project to try and I hope you're able to build what you're seeking. If you do be sure to post it to HN so I can check out how you managed to pull it off :).

zamadatix 4y ago

With Temporal on the horizon I wouldn't bother. Even if Temporal doesn't do what you want wrapper libraries that do will be very lightweight in the crunching regard https://tc39.es/proposal-temporal/docs/cookbook.html#arithmetic https://tc39.es/proposal-temporal/docs/cookbook.html#arithme...

no_wizard 4y ago
This assumes two things though, and this is another point I just realized about WASM that I like, which is for (most) modern browsers have asm.js / WASM support, and it goes back much farther than Temporal. 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/temporal-polyfill/README.md https://github.com/fullcalendar/temporal/blob/main/packages/... [1]: https://github.com/tc39/proposal-temporal#polyfills https://github.com/tc39/proposal-temporal#polyfills [2]: https://caniuse.com/wasm https://caniuse.com/wasm [3]: https://caniuse.com/asmjs https://caniuse.com/asmjs
- zamadatix 4y ago
  Yeah if you need something ready for prod by a literal next month or something Temporal definitely isn't it as the API isn't locked yet. Don't forget WASM doesn't provide direct access to any OS time APIs (timezone info, current time, regional time change modifications) so the solution will still basically boil down to "call Date() and polyfill a better library" except now you have extra code to ferry the data back and forth to do a few string and math ops. Unless the use case is processing very large datetime datasets in one call the JS<->WASM function call overhead for all of this will probably take the majority of the execution time. Not to mention after you get all of this solved, tested, and deployed you know as soon as Chrome starts shipping Temporal the cool custom solution becomes 50% slower for the average user despite all the effort because you didn't just use something like a Luxon which automatically updated to use Temporal on release. This may just be me being lazy though :p.
  - no_wizard 4y ago
    Even if Temporal ships tomorrow, its minimum 5 years for most applications to take advantage of it, so you're either polyfilling with feature detection or waiting it out using libraries like `date-fns` or `luxon` to fill the gap. strings & numbers are WASMs strong point, so if you can pack the locale information tightly in a binary format, you might actually win out in the medium term. This shouldn't be a years long project by any means. And frankly, with the way enterprises move, you'll always have some client (at least in my business) where I need to support some modernish browser that may not have Temporal, so if this is more performant (we do alot of date time datasets, so yes, thats part why I'm looking at this) why not? It could also be the wrong solution. I'll found out one way or another.
    - zamadatix 4y ago
      Just the IANA timezone database is ~400 KB gzipped for the data only and it's really quite the project to actually parse correctly. With that you'll still need to ferry Date(), Intl(), and friends for getting the current info about the user into the WASM module. Only then can you actually start talking about the code which competes with the 20 KB JS polyfill which started with all of the above as precompiled native code and data. WASMs strong point isn't necessarily "strings and numbers" it's running large amounts of compiled code on large amounts of data. Video processing, PDF readers, video games. As an example even computing a large image the Mandelbrot fractal (pure math workload) then passing back an arraybuffer of the pixels was faster in JavaScript until WASM SIMD+Threads finally landed and JavaScripts poor parallelism finally factored in. Doing it with a functional call per pixel JavaScript is still ahead of even WASM with SIMD due to the functional call overhead. But all that said I think it's a really cool project to try and I hope you're able to build what you're seeking. If you do be sure to post it to HN so I can check out how you managed to pull it off :).