| 00:31 | <Justin Ridgewell> | How feasible would it be to embed binary strings inside JS? Something like const binary = 17'...binary data...', denoting 17 bytes of non-utf data. |
| 00:33 | <Justin Ridgewell> | I think the spec could be easy enough, but the challenge is making sure browsers don’t run a UTF8 step before letting JS parse. |
| 01:09 | <bakkot> | I don't think engines would go for that, no |
| 01:09 | <bakkot> | or other tools, for that matter |
| 01:10 | <bakkot> | just do Uint8Array.fromBase64(/*data*/); after gzip this should be basically the same size anyway |
| 03:33 | <Justin Ridgewell> | I’m trying to avoid Base64’s byte increase and the time needed to decode it (10ms+ for each of several stings) |
| 12:09 | <bakkot> | I would expect Uint8Array.fromBase64 to be a great deal faster than that. |
| 12:12 | <bakkot> | If you have a mac with macOS14+, you can download the latest Safari Tech Preview and try it out there |
| 14:44 | <Justin Ridgewell> | The decode is being done in Chrome’s data: URI parser, not JS. Search embeds large images as data URIs for… reasons, and is looking to improve both response size and time to image ready. |
| 14:45 | <Justin Ridgewell> | If we can skip Base64, we get both. |
| 14:51 | <bakkot> | afaict, the base64 parser for data: URIs is called https://source.chromium.org/chromium/chromium/src/+/main:net/base/data_url.cc;l=150;drc=f522344e45882da4c7f7cb1b3a0a7bd747d654bb which means it's https://source.chromium.org/chromium/chromium/src/+/main:third_party/modp_b64/modp_b64.cc;drc=f522344e45882da4c7f7cb1b3a0a7bd747d654bb;l=118 which is not at all optimized |
| 14:52 | <bakkot> | I am hoping Chrome will do what Safari did for fromBase64, which is to use https://github.com/simdutf/simdutf, which uses SIMD and should be able to decode at ~ the speed of memory |
| 14:53 | <bakkot> | base64 should only very barely affect response size after gzip so I don't think that should matter |
| 14:57 | <bakkot> | for loading images you'd need to turn that into a blob and then make a blob url, but I would expect that to be cheap too |
| 15:01 | <bakkot> | also you'd need to do that either way since data: URIs can't contain arbitrary bytes anyway |
| 18:30 | <Justin Ridgewell> | which uses SIMD and should be able to decode at ~ the speed of memoryI’ll see if this is a possibility. base64 should only very barely affect response size after gzip so I don't think that should matterThe network bytes themselves look fine (7.4kb brotli q3 vs 7.3kb raw bytes), but they’re literally worring about the decompressed size and how it affects the resource prescanner and JS parser. also you'd need to do that either way since data: URIs can't contain arbitrary bytes anyway data: URIs are feed straight to img.src = '…’, but if we can get raw bytes literal we would create a blob object, get and object id, and feed that to the src. |
| 19:30 | <Aki> | Greetings from TPAC. Y'all let me know if you're here or if you want me dropping in on any meetings on behalf of TC39 |
| 22:33 | <Aki> | why do people keep asking me if we're introducing typescript types did i miss a headline |
| 22:35 | <shu> | are they misunderstanding what the types-as-comments proposal does? |
| 22:40 | <ljharb> | virtually everyone who talks about the proposal on social media or on the github repo seems to |
| 22:49 | <Aki> | ohhhh that would make sense. because when i oversimplify and tell people we're sorta committed to staying out of the way, they seem to get it |
| 22:49 | <Aki> | though i always add a big "i can't predict the future" caveat |