asm.js is faster than WASM, and it can do everything that JS can do.

flohofwoe 4 hours ago | parent | 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).

▲

mbrock 5 hours ago | parent | prev | next [-]

Faster in what browser, by what measure, for what modules? "X is faster than Y" without any concretization is usually meaningless.

▲

chilmers 5 hours ago | parent | prev | next [-]

How can a subset of JS do "everything" that JS can do?

	▲	bogdan 5 hours ago \| parent [-]
		All you need is a lambda

▲

cogman10 5 hours ago | parent | 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.

	▲	nightpool 5 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...

▲

ramon156 5 hours ago | parent | prev [-]

WASM wont improve if no one adopts it. Its a chicken and egg issue

▲

flohofwoe 4 hours ago | parent [-]

WASM has been adopted and it has improved massively since 2017 though.

▲

pjmlp 2 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.

	▲	titzer an hour 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.