Earlier quoted context omitted.
Don't worry, YavaScript will live forever.
In Germany, it's still not uncommon to hear Yava and YavaScript.
I understand that Jawohl is still quite popular there, but JawohlScript adoption is sadly lagging.
Saying goodbye to asm.js
71–80 of 164 posts
Re: Saying goodbye to asm.js
#72I’ll never forget watching Gary Bernhardt give his talk on JavaScript.[0] Was my introduction to asm.js, and the rabbithole associated with compiling code to run in the browser. 12 years on, it’s shocking how much of his fiction became reality. [0] https://www.destroyallsoftware.com/talks/the-birth-and-death...
And if not for the rise of AI it's possible that WASM as a machine-level compilation target for all languages might have happened. As much as Gary predicted he didn't see AI coming.
wait how did AI impede wasm?
Re: Saying goodbye to asm.js
#73> asm.js was Mozilla’s response to the question posed by NaCl and PNaCl: how can the web run code at native speeds? Had it been today, Chrome would have just pushed NaCl and PNaCl no matter what, and then everyone would complain why Safari and Firefox aren't keeping up with "Web" standards.
I still maintain the notion we're in the wrong timeline, one where PNaCl died and instead of a worthy, timely successor we end up being boiled alive in a soup of Electron apps. I really thought, for a time, that we'd be doing everything in the browser . And in a way that's increasingly true, but it all just feels worse than ever. I like WASM and I want to like WASM but the rate of maturity within the ecosystem is inc…
Its like natural selection, maybe not the best traits win overall but one that is the most popular choice because everyone is a webdev.
Re: Saying goodbye to asm.js
#74I personally think this is a mistake. But I'm not sure how much it matters. It's not like a lot of people were using asm.js still AFAIK. But wasm is too isolated from javascript. From my limited use of it, I was considering trying to compile to asmjs instead. But I wasn't sure that emscripten still fully supported it. You can't call most web apis from wasm. But more important for what i was trying to do, you can't ze…
> But wasm is too isolated from javascript. From my limited use of it, I was considering trying to compile to asmjs instead asmjs is going to be strictly more limited in interacting with JS than wasm. You're basically limited to simple number values and array buffers. Whereas wasm now a days has GC types and can hold onto JS value using externref. > But more important for what i was trying to do, you can't zero copy…
Well, I haven't actually tried the asm.js approach for this, so maybe I'm missing something.
But since asm.js is just (a subset of) javascript, I assumed I could just pass ArrayBuffers around.
With wasm, I could pass a Uint8Array out of it. If I wanted to pass it in, I had to call malloc from the javascript side to allocate in the wasm heap. But since I already had an arraybuffer (from a file upload), that meant an extra copy.
Re: Saying goodbye to asm.js
#75> asm.js was Mozilla’s response to the question posed by NaCl and PNaCl: how can the web run code at native speeds? Had it been today, Chrome would have just pushed NaCl and PNaCl no matter what, and then everyone would complain why Safari and Firefox aren't keeping up with "Web" standards.
You mean Chrome would have pushed it, Apple would have filibustered it by refusing to comment (via lack of investment in the WebKit team), and then gullible folks on the internet would defer to them.
(I will note that Apple seems to have upped WebKit investment this decade since their regulatory problems started in earnest - so it's possible this would end differently today)
Re: Saying goodbye to asm.js
#76Earlier quoted context omitted.
What are the key differences between PNaCl and WASM?
There were 3 systems, all with interesting differences. The original NaCl was a 'validated subset' of native CPU machine code (e.g. actual x86 machine code with some instructions and instruction sequences disallowed which would allow to escape the sandbox). The next iteration was P(ortable)-NaCl which replaced the native machine code with a subset of LLVM bitcode, which was then compiled at load time. Unfortunately w…
> (Flascc/Alchemy(?) I forgot all the names this went through)
Crossbridge was its third and most recent name.
Pepper.js is another interesting project from around this time that didn't pan out.
Re: Saying goodbye to asm.js
#77Earlier quoted context omitted.
There were 3 systems, all with interesting differences. The original NaCl was a 'validated subset' of native CPU machine code (e.g. actual x86 machine code with some instructions and instruction sequences disallowed which would allow to escape the sandbox). The next iteration was P(ortable)-NaCl which replaced the native machine code with a subset of LLVM bitcode, which was then compiled at load time. Unfortunately w…
> (Flascc/Alchemy(?) I forgot all the names this went through) Crossbridge was its third and most recent name. Pepper.js is another interesting project from around this time that didn't pan out. https://github.com/google/pepper.js/
Wasn't pepper the P in PNaCl?
Re: Saying goodbye to asm.js
#78Sad day. I have a sha256 hasher in asm.js that's faster than any wasm solution.
what's wrong with the built in one? https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt...
no incremental hashing, so you can't hash files too large for ram.
I do use it for smaller files though, it's much faster.
Re: Saying goodbye to asm.js
#79Sad day. I have a sha256 hasher in asm.js that's faster than any wasm solution.
In SpiderMonkey, asm.js code has been compiled by exactly the same pipeline as wasm since at least 2019. In fact, the way we compile it is literally to construct a pseudo-wasm module and run it through our wasm compiler (with a few flags to tweak the behavior to fit the asm.js semantics). In other words, if you're running asm.js in Firefox, you're literally just running wasm anyway, so how could it possibly be faster…
yeah turns out it was chrome that was slow, not firefox.
wasm hashing in chrome is half the speed of firefox for me.
Re: Saying goodbye to asm.js
#80Sad day. I have a sha256 hasher in asm.js that's faster than any wasm solution.
Made the requested benchmark:
https://theultdev.github.io/web-sha256-benchmark
https://github.com/TheUltDev/web-sha256-benchmark
It's Chrome wasm (windows) that is slow for me, 2x slower than asmjs.
FF with asmjs optimizations are 2x slower than wasm on FF.
Wasm in FF is 2x faster than wasm in Chrome for this hashing solution (for me).