upvote

points

by oneshtein11 hours ago |
comments
upvoteby flohofwoe10 hours ago|
next
[-]
Congratulations, two spectacularly wrong 'facts' in one short sentence is quite an achievement ;)

It's true that in the beginning (around 2017), WASM wasn't much faster than asm.js, but meanwhile WASM has seen real performance improvements.

Featurewise, asm.js is much closer to WASM than to regular JS, it definitely cannot do everything that regular JS can do (mainly because asm.js is limited to the Number type, it cannot deal with JS strings or objects).

reply
upvoteby mbrock10 hours ago|
prev|
next
[-]
Faster in what browser, by what measure, for what modules? "X is faster than Y" without any concretization is usually meaningless.
reply
upvoteby chilmers10 hours ago|
prev|
next
[-]
How can a subset of JS do "everything" that JS can do?
reply
upvoteby bogdan10 hours ago|
parent|
[-]
All you need is a lambda
reply
upvoteby cogman1011 hours ago|
prev|
next
[-]
Faster? I'm not sure about that. Maybe if you are doing a lot of talk between the compiled and JS runtime/DOM. But otherwise WASM has been much further developed in both Firefox and Chrome.

I don't think Chrome ever did an asm.js specific optimization.

reply
upvoteby nightpool10 hours ago|
parent|
[-]
It did, V8 added asm.js compilation to WASM in 2017 https://v8.dev/blog/v8-release-61#asm.js-is-now-validated-an...
reply
upvoteby ramon15610 hours ago|
prev|
[-]
WASM wont improve if no one adopts it. Its a chicken and egg issue
reply
upvoteby flohofwoe10 hours ago|
parent|
[-]
WASM has been adopted and it has improved massively since 2017 though.
reply
upvoteby pjmlp8 hours ago|
parent|
[-]
Yes, but GC is still useless for languages with interior pointers, some features require gimmicks with server configuration, and for most languages we aren't any way closer to -march=wasm and that's all.

We still need to download half Internet for emscripten, plus whatever tools are being used on top. Although it is somewhat simpler for those that build on top of binaren.

reply
upvoteby titzer7 hours ago|
parent|
[-]
Wasm evolution happens in fits and starts. There's a lot of nested chicken-and-egg problems. We first started on Wasm GC less than two years after MVP, and then we didn't have any language targeting it, so we had to bootstrap it. Now, Java, Dart, Kotlin, and Scala all target Wasm GC (and Virgil too :-)). The interior pointer is on people's radar.

The next big feature coming is stack switching. It works best with unboxed continuations, which necessitates a fat pointer representation in the engine. Once the engine supports fat pointers, then interior pointers will be an easier sell. It might take several years to get there, but Wasm evolves slowly and deliberately, and IMO hasn't made any massive fatal design errors yet.

reply