> 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.
xyzzy_plugh 1 days ago [-]
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 incredibly abysmal.
What's worse is that we should all be running our untrustworthy AI tools and their outputs in precisely such a sandbox, and companies are selling the reverse: hosted sandboxes, hosted JS-based VMs.
I guess that was always the problem: there was never any money in a client-side sandbox.
nl 11 hours ago [-]
I've been using the FileSystems API a lot lately.
It gives a sandboxed directory on the local computer you can read and write to (user decides what rights you get). It's what the web version of VS Code uses to edit local files.
It's wonderful. Suddenly you can blend local and remote systems together the way they should operate, without having to have local apps with god-knows-what rights.
It's not implemented in Firefox. I understand it is a risky API, but wow it makes a huge difference to what is possible.
It runs Gemma E4B in the browser, and Python (Pyodide) and SQL (DuckDB) in WASM.
You can give it a directory with some CSVs, tell it to load them and then it can run analysis on them.
The whole Web platform is great - I just wish I could say it runs in Firefox too.
projektfu 23 hours ago [-]
I wish we had another alternate timeline.
"Our submission is in TALx86, a strongly typed functional language that encourages an explicit continuation-passing style and supports mutually recursive modules. We were encouraged to use this language when we learned that the competition would allow us to run our program on an interpreter implemented in hardware. We are grateful to the Intel Corporation for developing this interpreter."
Typed Assembly Language—fascinating. But since the software is "All rights reserved," I don't know if it can be used beyond personal use.
projektfu 16 hours ago [-]
True, it was a dead end perhaps.
nextaccountic 15 hours ago [-]
Isn't this approximately just wasm?
projektfu 5 hours ago [-]
Is there hardware that executes WASM directly?
burntcaramel 18 hours ago [-]
I’ve found canvas + WebAssembly works great together!
Here’s an example of Sudoku running in WebAssembly (it was vibe coded in Zig) and then rendered to canvas. The interface between the wasm module and the browser is function calls for keyboard and mouse events, and then another that renders to a pixel buffer to copy to the canvas.
And this approach also works for simple forms, such as a URL input that gets turned into a QR code. Again the interface is simple, here converted a URL into SVG markup. As you type in the input we call the WebAssembly render function again.
The sudoku example has something massively wrong with it's performance. Latency is over a second per click and it halts after a few clicks.
The QR example works fine though
dmazzoni 17 hours ago [-]
Do you really think this "works great"?
I'm using a brand-new MacBook Pro with a high-end M5 processor, and this site is extremely unresponsive for me. Huge latency between clicking and getting feedback.
It also breaks accessibility.
The QR code use case seems far more reasonable to me, you're generating a static image.
I do understand why NaCL and PNaCL are undesirable and why wasm is much better, but as a student the NaCL ssh app had saved my computer science homeworks more than once, and this is something that still doesn't have an alternative although I rarely would need it nowadays.
WASM standalone runtimes are mostly fine, but WASM in the browser is not great. No direct access to any web APIs (this often really hurts when shuffling data to/from WebGPU). Multithreading via WebWorkers is a complete pain to setup. No zero-copy APIs for streaming data in/out. Little paper cuts, but they all add up...
po1nt 21 hours ago [-]
Memory management is pain. If you want to optimize, you're forced to 4k pages. Runtimes are fragmented. Wasi is a mess. Async and threading is awkward. Whenever you need to integrate with hardware you need platform specific adapters.
In practice, whenever you need more than a singlethreaded app with http/serial port, the "run everywhere" breaks.
Don't get me wrong I love WASM but we're not there yet
jauntywundrkind 22 hours ago [-]
Not the previous poster, but immatures: Needing to compile down to one enormous program, with no possible code sharing. The async story is not good.
Probably an unpopular opinion, but IMHO the WASM Component Model is an entirely overengineered boondoggle that has no place in browsers.
It's trivial to create small statically linked WASM programs in the "a few dozen kilobytes" range with the right programming language (like C).
"Code sharing" via dynamic linking also works, but it has the same downsides as dynamic linking on native platforms (basically that DLL interfaces represent an optimization barrier): https://emscripten.org/docs/compiling/Dynamic-Linking.html
mmastrac 19 hours ago [-]
PNaCl was a terrible idea. It was as bad of an idea as shipping the raw sqlite interface in the browser.
I feel like some of the Google-sourced standards are the laziest, least-webby ones out there. There are some good ones that come from the Chrome team, but man the real stinkers are _always_ a lazy Google engineer trying to ship a half-baked clone of something native in the browser because they need it for something or other internally.
hoppp 1 days ago [-]
Its like natural selection, maybe not the best traits win overall but one that is the most popular choice because everyone is a webdev.
tardedmeme 1 days ago [-]
What are the key differences between PNaCl and WASM?
mccr8 21 hours ago [-]
One of the big issues with NaCl is that the API it used wasn't standardized at all and there was only a single implementation. You could pick a random function and ask "hey, what happens if you pass in some slightly weird arguments?" and there was no answer beyond "whatever Chrome does". With enough work, maybe that could have been overcome while preserving backwards compatibility, but there were lots of random functions in there because somebody or other had found it useful. WASM was built from the ground up with a standards process and multiple implementations.
flohofwoe 1 days ago [-]
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 with this step NaCl lost most of its advantages. Startup time was atrocious because it was basically the second half of the LLVM compilation pipeline (from LLVM-IR to machine code). LLVM-IR also isn't actually great as CPU-agnostic bytecode.
WASM was designed from the ground up as CPU agnostic bytecode that's also much easier and faster to validate.
The only major advantage of PNaCl vs early WASM was that PNaCl supported shared-memory threading right from the start (this is still knee-capped in WASM because of the COOP/COEP response header requirement).
...apart from Emscripten => asm.js => WASM, and Google's NaCl/PNaCl there was also a system by Adobe (Flascc/Alchemy(?) I forgot all the names this went through) to compile C and C++ code into Adobe Flash bytecode.
I have an ancient blogpost from 2012 which compares the three (and where I have been flabbergasted by how well Emscripten actually worked - and this was even before asm.js - the linked demo is unfortunately no longer up):
Yep, that's the name. There was a brief period in late 2000s when Adobe was pushing hard to make Flash embedded into web ecosystem. They made Air as a way to package Web or Flash code into a desktop app. Essentially it was Electron-before-Electron. Alchemy was a part of this grand plan to be able to integrate existing native libraries with Flash code. The plan was like you said to compile to Flash bytecode, and AFAIK it never went further than a tech demo.
This whole ecosystem turned into a slow train-wreck over approximately 5-year period. Adobe really saw themselves as future stewards of web technology. They donated their ActionScript VM and a JIT to Mozilla and hoped that Firefox would become the first browser with fast JavaScript engine. Google developed Chrome and V8 in secret and managed to release their fast browser early. Microsoft and Yahoo sabotaged adoption of ActionScript dialect as at the next JavaScript. And at the same time Apple went fully anti-plugins, and with the rise of iPhone both Flash and silverlight died off.
Years later Java folks tried to build their own version of Alchemy as part of GraalVM. The project was called Sulong and was using Graal to execute and JIT LLMV bitcode. TruffleRuby was supposed to be a primary early beneficiary to be able to compile and run Ruby native extensions. This was during the period of a race between several JIT solutions in hopes to become "the next Ruby", and Truffle team (along with IBM's OMR) lost the race first to MJIT and then to YJIT. Graal itself seems to loosing steam, because their multi-language VM never got enough adoption among Java, Node, or Ruby people, and the VM itself tended to use too much RAM in era when RAM became premium in the cloud.
pjmlp 7 hours ago [-]
Graal was never designed as OpenJDK replacement, it is the evolution of MaximeVM, and their main customers, meaning who pays the team salaries are the Oracle database and cloud teams.
In that regard they are doing pretty well.
Plus all the folks that never paid for ExcelsiorJET, JRockit, PTC, Aicas, and many others of which only PTC and Aicas survive, now have in Graal their gratis AOT compiler.
Alongside OpenJ9 (which is more like what Leyden is trying to be), and the one on the box shipped alongside ART.
Ruby on top of JVM has a few interwined stories since the days Sun embraced it on Netbeans, and it suffers from the same issues as PyPy regarding adoption, it suffices not to be 100% compatible with whatever crazy extensions written in C exist out there.
Microsoft was probably more clever giving up on IronPython and IronRuby, and keeping the DLR infrastructure.
p_l 1 minutes ago [-]
In my experience JRuby is way more viable than Jython ever was, one because Ruby native modules were more often thin wrappers, two because Ruby has sorta-standard in form of test suite (which AFAIK evolved from one that was necessary for ISO Ruby effort), and established somewhat case of using different implementations..
And C extensions never got as crazy as in python, and some major ones either made Java backends or switched from MRI embedding to FFI
Randomno 24 hours ago [-]
> (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.
Pepper was a pun on Native Client (since NaCl = salt). Pepper Plugin API (PPAPI) was Google's more secure version of NPAPI (Netscape Plugin API). Flash Player was essentially the only thing using NPAPI/PPAPI by the end of its life.
jcranmer 23 hours ago [-]
The most common plugins were Flash, Silverlight, Adobe Reader, and the Java applet plugin, and I think all of those were in mildly common use when plugins were on their last legs.
pjmlp 20 hours ago [-]
Now you can have all of them running on top of WebAssembly, companies even pay for support.
bawolff 1 days ago [-]
> The only major advantage of PNaCl vs early WASM was that PNaCl supported shared-memory threading right from the start (this is still knee-capped in WASM because of the COOP/COEP response header requirement).
Presumably that is because PNaCl predated spectre (?)
flohofwoe 1 days ago [-]
Indeed, NaCl and PNaCl would have been hit by Meltdown/Spectre at least as badly as SharedArrayBuffer.
kg 22 hours ago [-]
I remember early during the Wasm design process we were openly speculating whether people would eventually figure out how to do stuff like Rowhammer from raw Javascript. My bet was on Yes, but I don't remember if any of my teammates said No. I think we all knew the writing was on the wall by then.
xg15 22 hours ago [-]
> 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).
Out of curiosity, does that mean that NaCL (without P) only ran on x86? Or were there different subsets for different architectures?
wffurr 21 hours ago [-]
You could compile NaCL code for x86_64, aarch64, and aarch32 as well. Chrome apps has a system similar to mobile apps where you would upload an app with all binaries and users would get the one for their system architecture.
xg15 18 hours ago [-]
Ah, that makes sense. So users were effectively cross-compiling the NaCL binaries for multiple architectures.
wmf 21 hours ago [-]
I think the plan was to JIT x86 to other architectures.
jorvi 20 hours ago [-]
Heh, emscripten. I remember running the Unreal engine in the browser with that. Quite impressive indeed.
doctorpangloss 22 hours ago [-]
> we should all be running our untrustworthy AI tools and their outputs in precisely such a sandbox
The DevOps infrastructure Kubernetes runbook AI inference router API people (DIK-AROUnders for short) always want an abstract technical solution that increases both their budget and their distance from the end user's actual application. Like the more money they get to dick around with meaningless technical cathedrals, the better. They're only bent out of shape that they couldn't parlay that into a sweet crypto scheme. In the real world, the line between what users actually want and what DIK-AROUnders call inauthentic activity is quite blurred.
To me, the fact that AI agents can browse websites and make payments and read my email and pretend to be me or other people is a huge part of their value proposition. People want to get out of the sandbox! There are many meanings to the words security and privacy.
lmkg 1 days ago [-]
I mean that's still basically what they tried to do at the time. They were trying to get them through web standards committees and everything.
IIRC a big reason it didn't end up working was because NaCl was such a "big" technology and asm.js such a "small" one that asm.js was able to reach production-ready first despite starting work several years later.
mccr8 21 hours ago [-]
The cute thing about asm.js is that it was fully backwards compatible with the web: it was just a lot slower without dedicated support. So Epic or whomever could put out a demo that would run just fine in Chrome, but the performance was a lot worse than Firefox which had a dedicated compilation pipeline, so it made Chrome look bad.
JoshTriplett 19 hours ago [-]
Exactly. "You can't not support it; you can only be slow."
pjmlp 1 days ago [-]
The big difference was that they lacked the market share they enjoy nowadays, with their forks and Electron crap.
indolering 15 hours ago [-]
That's not how I remember it: it was an experiment that was useful at the time but didn't work out. It was useful internally to sandbox Flash player, but the limitations of the LLVM based approach were soon evident to everyone involved.
benced 24 hours ago [-]
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)
lern_too_spel 16 hours ago [-]
People complain when there are no highly compatible alternatives to something that would be useful to have on the web platform. Asm.js and then Wasm were those alternatives. That's why they didn't complain then but do complain now about things that Safari won't do because it would hurt the App Store. Happily, the EU is now at least trying to whip Apple into shape.
rudi-c 1 days ago [-]
That's sad but sensical. Fun fact, Figma originally started as a fully C++ codebase, and Asm.js was key in proving that it would be possible to run a design tool in the browser. The switch to WebAssembly didn't happen until after there were paying customers, and provided nice improvements to load time (Asm.js is still JS which the bundle size is bigger and requires the code to be parsed into an AST, unlike WASM).
0x457 23 hours ago [-]
What's so sad about it? It was just a compilation target that made sense at one point in time. Its like being sad about i386-unknown-freebsd1 being dropped.
rudi-c 22 hours ago [-]
Yes, I don't mean that it affects the present. Only sad in a nostalgia sense.
frumplestlatz 23 hours ago [-]
What’s sad about that is we could have had a clean, native, desktop Figma application.
rudi-c 22 hours ago [-]
This is a lazy statement based on extremely vague handwaving about desktop v.s. web. It's not the 2010s anymore. Time to drop these generalities.
Users were migrating to us _from_ desktop applications. Collaboration was the key differentiator, but a less well known reason was that improved performance, including but not limited to the support of large design systems, was also a commonly cited reason among paying customers for migrating to Figma.
MBCook 21 hours ago [-]
Users still care.
Desktop or collaborative is a false dichotomy. Desktop or performance is too.
I get why you did what you did. It makes sense. But don’t think there aren’t people out here who HATE everything being shoved on the web with no desktop option.
No, electron and PWA don’t count.
braden-lk 21 hours ago [-]
How dare you make a performant, accessible app that's easy to distribute, instead of spinning up a different eng. team to maintain a different codebase on a different deployment pipeline so 1% of your userbase can say it's a "real" desktop app instead of a silly "fake" desktop app. :P
Jokes aside, Figma's stack is super inspiring, and y'all's articles on sync engines heavily inspired my work on LegendKeeper. I appreciate the work you do!
11 hours ago [-]
latexr 8 hours ago [-]
I’m just one data point, but when I tried Figma (admittedly many many years ago), I didn’t find it particularly performant. I remember being intrigued by the concept of vector networks (was that the name?) but being in the browser made it such an awful experience to use and so unreliable to shortcuts that I promptly abandoned it and never looked back.
I never communicated this to the team, but I doubt I was alone. All that is not to knock you down, I just wanted to share that being a proper native desktop app does matter to some people for practical reasons other than performance, even if you’re not aware of it.
Me1000 19 hours ago [-]
A native application that further locks users into some single platform? Or accept all the maintenance and development costs and burdens that keep the application one step behind Photoshop if they wanted to support multiple platforms?
shepherdjerred 19 hours ago [-]
They explicitly had the goal of being a web application. It was a product choice, not a technical choice.
futune 1 days ago [-]
So the death of asm.js is upon us?
We are drifting away from the timeline of the prophecy:
(And to those who haven't encountered this before, I strongly recommend a watch. It may be the greatest tech talk of all time, for certain values of greatest.)
muvlon 1 days ago [-]
With this technology's death, the thread of prophecy is severed. Restore a saved game to restore the weave of fate, or persist in the doomed world you have created.
tadfisher 1 days ago [-]
Yagrum Bagarn has something for you.
mikece 1 days ago [-]
Not really: ASM.js became WASM. What killed the possibility of WASM being The One Way to run everything is AI... the one wildcard that Gard Bernhardt didn't predict.
DarkUranium 18 hours ago [-]
To be honest, with how bad a target WASM is for any existing compiler, I feel like what killed that possibility was WASM itself.
Its IR design is horrendeous.
nextaccountic 15 hours ago [-]
Can you talk more? I've seen people say only good things about wasm
avadodin 7 hours ago [-]
Not op, but I only know it as the 32-bit single-threaded binary replacement for JavaScript that can't interact with anything naturally yet people get all excited about when they manage to turn their LLVM slop output into it.
Maybe we've been reading different HN submissions.
mikece 1 days ago [-]
I re-watch that presentation two or three times a year because it's a great example of how to give a presentation, how to structure your slide deck to complement your presentation, and a surprisingly educational tour of the permission rings architecture of operating systems.
And at some point we're going to have a period or war and our psychological attachments to old programming paradigms will be released so that we can move on to a more advanced way of doing things (but that won't stop your bank from running YavaScript for at least another 85 years).
phoe-krk 1 days ago [-]
Just substitute asm.js with WASM and you're still on the right track.
bvisness 1 days ago [-]
Don't worry, YavaScript will live forever.
egeozcan 1 days ago [-]
In Germany, it's still not uncommon to hear Yava and YavaScript.
bonesss 1 days ago [-]
I understand that Jawohl is still quite popular there, but JawohlScript adoption is sadly lagging.
22 hours ago [-]
dagurp 20 hours ago [-]
It's the only pronunciation you'll hear in Iceland
mikece 1 days ago [-]
I still refer to it as YavaScript much to the confusion of junior devs. I just tell the new kids: "you had to be there..."
ksec 1 days ago [-]
If we substituted war with COVID we aren't that far off as both happened in 2020. We still have to wait till 2035 to see if true.
veltas 8 hours ago [-]
> If you maintain a site that uses asm.js, nothing will break. asm.js is just a subset of plain JavaScript, so the code keeps running through our regular JIT just like any other script.
And this is still a killer feature of asm.js, even if it's not 'supported' it's still implicitly supported.
EDIT: And also seriously just thanks to the people who invented asm.js, it was a brilliant idea, but it makes sense that it's not worth optimizing anymore.
metmac 1 days ago [-]
I’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.
The bit about "thick apps" always stuck with me. Partly because the name is funny, partly because it hit close to home. The first time I saw his talk, I was an intern working for a company that had built an entire compiler, IDE, and debugger in-house for their little industrial IO boxes. The compiler was written in C, and we used Emscripten to turn it into some JS that then got "compiled" (see: concatenated) into a giant HTML file with the IDE and debugger bits. Code uploads and debugging happened over ethernet, so all of that just got shoved through Ajax.
This sounds cursed, but customers loved it. Since it wasn't an EXE, it didn't get caught up in their employers' overzealous corporate IT filters. That's why we never switched to Electron. In a sense, we had some of the primeval elements of the thick app.
mikece 1 days ago [-]
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.
chamomeal 1 days ago [-]
wait how did AI impede wasm?
xscott 23 hours ago [-]
I believe the idea is that you don't care what language is being used if you aren't going to look at it anyway. Given that premise, the AI can write JavaScript instead of something you need to compile separately.
esperent 6 hours ago [-]
WASM is hard enough to use that I would say the number of people using it just because they don't like JS/TS is fairly small.
At least that's always been my impression. If you're willing to go through the effort to use it, it's probably because you need the performance gains, and AI hasn't changed that.
ndesaulniers 23 hours ago [-]
A long time ago, I wrote a small chapter in a WebGL book on asm.js.
It was fun to see the rise of asm.js, which was a precursor to Web Assembly. Some of the early demos were so cool to see; Unreal Engine running in the browser. :) Bitter sweet to see the sun set here, but it did lead to much better things.
sehugg 1 days ago [-]
Hmmm, need a asm.js -> WASM transpiler maybe.
(compiling legacy code with legacy versions of Emscripten is quite frustrating, almost as bad as updating your JS code to be compatible with accumulated changes in the Emscripten ABI)
eqrion 1 days ago [-]
Binaryen used to have an asm2wasm tool, but I believe it has been deprecated. I couldn't find any other equivalent. At least the asm.js code will keep working even with asm.js opts disabled, but it would be nice to have a translator.
Kaxo 10 hours ago [-]
In chrome at least asm.js is(/was?) handled by the wasm engine anyway. They essentially did that transpiling at load time.
To be fair, I thought asm.js was deprecated a few years ago with emergence of wasm.
1 days ago [-]
andrewl-hn 21 hours ago [-]
I remember when Mozilla released OdinMonkey that was hyper-specialized for asm.js code, the Chrome / V8 team instead worked on general-purpose optimizations in their JIT that would run normal JavaScript faster but also would help asm.js. The difference in speed was 2-4x in favor of Firefox, and they hyped it a lot :D
Nowadays most browser JavaScript VMs converged to very similar designs and optimizations, so even without Odin asm.js code would run pretty fast anyway.
looneysquash 1 days ago [-]
I 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 zero copy buffers from js to wasm.
Everything is a trade off. The isolation is a good thing, but also a bad thing.
eqrion 1 days ago [-]
> 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 buffers from js to wasm
This isn't a fair comparison. Wasm was severely limited when it was first implemented and it had the advantage of a decade of improvements. Asm.js has had zero improvements in that same time frame.
Had WASM not been adopted we would have SIMD in JS ( probably via asm.js) by now. Because we didn't, JS just cannot compete with WASM in many computationally heavy workflows. We'd also have general purpose JS to Asm.js compilation, with few API restrictions, making writing it much easier.
flohofwoe 1 days ago [-]
> Asm.js has had zero improvements in that same time frame.
WASM is that evolution of (strict mode) asm.js. The two really aren't all that different from what they can and can't do.
1 days ago [-]
looneysquash 24 hours ago [-]
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.
stusmall 1 days ago [-]
Oh my God. That's so exciting. I did a prototype a while back for writing UDFs in WASM for a query engine. The fact that everything needed to be copied in and out of the environment killed it. Excited to try it again if/when this lands
flohofwoe 1 days ago [-]
IIRC Emscripten has removed asm.js support around 2020, and that was probably the most important toolchain that ever supported asm.js (maybe followed by Rust, don't know if they still support it though)
> You can't call most web apis from wasm.
You can't from strict asm.js either, since it only supports numbers (no JS strings or objects) and manages the C heap in an ArrayBuffer object just like WASM.
> But more important for what i was trying to do, you can't zero copy buffers from js to wasm.
Same problem as above, you need to call out into "real" Javascript from asm.js and you can't map other ArrayBuffers directly into the 'asm.js heap' either, a copy is needed. The "Javascript FFI" really isn't much different between asm.js and WASM.
chilmers 1 days ago [-]
Perhaps I'm misunderstanding, but doesn't asm.js have the same restrictions? I.e. you can't call web APIs directly from asm.js code, you still need special handling for "foreign" functions.
Rohansi 1 days ago [-]
Depends how you want to look at it. On one side asm.js is just JavaScript with special JIT handling, so you should be able to mix them. On the other side you have C/C++/Rust/whatever compiled to asm.js which needs to go through hoops to call normal JavaScript code
flohofwoe 1 days ago [-]
> so you should be able to mix them
AFAIK as soon as you'd start mixing idiomatic JS and asm.js, you lose the "special sauce", you only got the special asm.js treatment in browsers when putting a "use asm" at the top of a source file, and that would prevent using regular JS features in the same file.
chilmers 23 hours ago [-]
I don't think that is true though. The spec make it clear that it only has access to a limited subset of the JS standard libraries and specially registered foreign functions:
> An asm.js module can take up to three optional parameters, providing access to external JavaScript code and data:
> - a standard library object, providing access to a limited subset of the JavaScript standard libraries;
> - a foreign function interface (FFI), providing access to custom external JavaScript functions; and
> - a heap buffer, providing a single ArrayBuffer to act as the asm.js heap.
Just try the asm.js subset and see how it performs for you, I remember that even without the special asm.js support in browsers Emscripten output performance was surprisingly good
cogman10 1 days ago [-]
In fact, I think it was only firefox that made a special JIT route. Chrome moved optimizations into the regular JIT.
It will still work. asm.js is just regular JavaScript code, after all. It just won't parse/run as fast as custom pipeline for asm.js. My guess is that you will not notice much difference unless you have a really huge application.
koolala 1 days ago [-]
There are some WAT compilers that are small and fast for running in the browser.
hollowturtle 24 hours ago [-]
Isn't Asm.js better just for the fact that I can call web apis directly without shims? Or moving data in and out? I'd love to commit totally to webassembly but still seems very limited, am I wrong?
0x457 23 hours ago [-]
Depends on what do you mean about by web apis. Fetch API for example is not part of asm.js subset of JavaScript. You going to need a javascript shim on both cases. However, like the siblings comment says: overhead comes from conversion between big structures.
aabhay 23 hours ago [-]
Wasm can also call web apis directly. The overhead you hear about is in translating complex types like nested dicts etc between formats. But wasm runs inside the js runtime
nextaccountic 14 hours ago [-]
There's a real overhead in that wasm can't inline those calls, but Javascript can
trgn 21 hours ago [-]
:(
this was such a crazy project. remember when we compiled our c++ to wasm over 10 years ago, wait, this works?! web seemed to move so fast then.
EdwardDiego 1 days ago [-]
We'll drink again in Valhalla (not the JDK project, the one with much carousing).
karel-3d 21 hours ago [-]
What I liked about asm.js is that it's "just" javascript and you don't need any special way to load them, while with wasm you have the wasm file which you need to load on the side, which is a bit clunkier. But eh it's a tiny thing
claytongulick 1 days ago [-]
It would have been nice if they had mentioned Luke Wagner, who's idea it all was and who created the first implementation, as well as one of the main driving forces behind wasm.
unconed 1 days ago [-]
Asm.js was never needed as a legacy mechanism, as it was just a compilation target for native code. There was nothing that it needed to remain backwards compatible with, all asm.js code was new code.
OTOH asm.js can be retired now thanks to being backwards compatible with plain JS.
It allowed it to be an experiment that could have been quickly rolled out without a risk of forever lingering as a back-compat requirement for browsers.
theultdev 1 days ago [-]
Sad day. I have a sha256 hasher in asm.js that's faster than any wasm solution.
bvisness 1 days ago [-]
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?
Furthermore, if you use wasm, you'll have fewer bounds checks (because of better memory allocation strategies[1]), access to SIMD, bulk memory operations, and a host of other niceties that have been added to wasm over the years. If your asm.js code is outperforming someone else's wasm code, that probably just means their wasm code is worse.
asmjs is about the same speed in chrome and firefox (with asm optimizations still enabled) but wasm is slow as hell in chrome, asm still better.
side note: someone mentioned native crypto.subtle, but that doesn't have incremental hashing so can't use it for large files. however I do use it in practice for smaller files.
Requires a secure origin. If you serve a local (but non-localhost) SPA over HTTP then you're blocked from using crypto.subtle.digest. At least, that is one reason I have seen a hand-rolled SHA-256 deployed.
Edit: oh, and it forces async.
theultdev 24 hours ago [-]
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.
danborn26 21 hours ago [-]
[dead]
css_apologist 1 days ago [-]
o7
oneshtein 1 days ago [-]
asm.js is faster than WASM, and it can do everything that JS can do.
flohofwoe 1 days ago [-]
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 1 days ago [-]
Faster in what browser, by what measure, for what modules? "X is faster than Y" without any concretization is usually meaningless.
chilmers 1 days ago [-]
How can a subset of JS do "everything" that JS can do?
bogdan 1 days ago [-]
All you need is a lambda
cogman10 1 days ago [-]
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.
WASM wont improve if no one adopts it. Its a chicken and egg issue
flohofwoe 1 days ago [-]
WASM has been adopted and it has improved massively since 2017 though.
pjmlp 23 hours ago [-]
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 22 hours ago [-]
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.
Rendered at 16:30:09 GMT+0000 (Coordinated Universal Time) with Vercel.
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 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 incredibly abysmal.
What's worse is that we should all be running our untrustworthy AI tools and their outputs in precisely such a sandbox, and companies are selling the reverse: hosted sandboxes, hosted JS-based VMs.
I guess that was always the problem: there was never any money in a client-side sandbox.
It gives a sandboxed directory on the local computer you can read and write to (user decides what rights you get). It's what the web version of VS Code uses to edit local files.
It's wonderful. Suddenly you can blend local and remote systems together the way they should operate, without having to have local apps with god-knows-what rights.
It's not implemented in Firefox. I understand it is a risky API, but wow it makes a huge difference to what is possible.
For example, I did this for a recent Kaggle comp: https://github.com/nlothian/gemma-data-agent
It runs Gemma E4B in the browser, and Python (Pyodide) and SQL (DuckDB) in WASM.
You can give it a directory with some CSVs, tell it to load them and then it can run analysis on them.
The whole Web platform is great - I just wish I could say it runs in Firefox too.
"Our submission is in TALx86, a strongly typed functional language that encourages an explicit continuation-passing style and supports mutually recursive modules. We were encouraged to use this language when we learned that the competition would allow us to run our program on an interpreter implemented in hardware. We are grateful to the Intel Corporation for developing this interpreter."
https://www.cs.cornell.edu/talc/icfp99-contest/solution.htm
Here’s an example of Sudoku running in WebAssembly (it was vibe coded in Zig) and then rendered to canvas. The interface between the wasm module and the browser is function calls for keyboard and mouse events, and then another that renders to a pixel buffer to copy to the canvas.
https://qip.dev/play-sudoku
And this approach also works for simple forms, such as a URL input that gets turned into a QR code. Again the interface is simple, here converted a URL into SVG markup. As you type in the input we call the WebAssembly render function again.
https://qip.dev/qr
The QR example works fine though
I'm using a brand-new MacBook Pro with a high-end M5 processor, and this site is extremely unresponsive for me. Huge latency between clicking and getting feedback.
It also breaks accessibility.
The QR code use case seems far more reasonable to me, you're generating a static image.
The C# toolchain for WebAssembly is pretty good. You can do a lot with Avalonia and Uno:
https://avaloniaui.net/
https://platform.uno/
Here's a C# clone of Visual Basic compiled to WebAssembly:
https://bandysc.github.io/AvaloniaVisualBasic6/
https://www.google.com/search?q=wasm+ssh+client
...the future is here!
it's a lightweight vm because i see sandboxing as a feature of vm's.
WASM is called WEB assembly but it can't access the Web API's without paying tax to the JS tyrant in between.
https://hacks.mozilla.org/2026/02/making-webassembly-a-first...
In practice, whenever you need more than a singlethreaded app with http/serial port, the "run everywhere" breaks.
Don't get me wrong I love WASM but we're not there yet
Wasm components & wasi have a lot of promise here. Until now though browsers have been ignoring all this; Firefox just started taking a more active interest. https://hacks.mozilla.org/2026/02/making-webassembly-a-first...
It's trivial to create small statically linked WASM programs in the "a few dozen kilobytes" range with the right programming language (like C).
"Code sharing" via dynamic linking also works, but it has the same downsides as dynamic linking on native platforms (basically that DLL interfaces represent an optimization barrier): https://emscripten.org/docs/compiling/Dynamic-Linking.html
I feel like some of the Google-sourced standards are the laziest, least-webby ones out there. There are some good ones that come from the Chrome team, but man the real stinkers are _always_ a lazy Google engineer trying to ship a half-baked clone of something native in the browser because they need it for something or other internally.
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 with this step NaCl lost most of its advantages. Startup time was atrocious because it was basically the second half of the LLVM compilation pipeline (from LLVM-IR to machine code). LLVM-IR also isn't actually great as CPU-agnostic bytecode.
WASM was designed from the ground up as CPU agnostic bytecode that's also much easier and faster to validate.
The only major advantage of PNaCl vs early WASM was that PNaCl supported shared-memory threading right from the start (this is still knee-capped in WASM because of the COOP/COEP response header requirement).
...apart from Emscripten => asm.js => WASM, and Google's NaCl/PNaCl there was also a system by Adobe (Flascc/Alchemy(?) I forgot all the names this went through) to compile C and C++ code into Adobe Flash bytecode.
I have an ancient blogpost from 2012 which compares the three (and where I have been flabbergasted by how well Emscripten actually worked - and this was even before asm.js - the linked demo is unfortunately no longer up):
https://floooh.github.io/2012/10/23/mea-culpa.html
Yep, that's the name. There was a brief period in late 2000s when Adobe was pushing hard to make Flash embedded into web ecosystem. They made Air as a way to package Web or Flash code into a desktop app. Essentially it was Electron-before-Electron. Alchemy was a part of this grand plan to be able to integrate existing native libraries with Flash code. The plan was like you said to compile to Flash bytecode, and AFAIK it never went further than a tech demo.
This whole ecosystem turned into a slow train-wreck over approximately 5-year period. Adobe really saw themselves as future stewards of web technology. They donated their ActionScript VM and a JIT to Mozilla and hoped that Firefox would become the first browser with fast JavaScript engine. Google developed Chrome and V8 in secret and managed to release their fast browser early. Microsoft and Yahoo sabotaged adoption of ActionScript dialect as at the next JavaScript. And at the same time Apple went fully anti-plugins, and with the rise of iPhone both Flash and silverlight died off.
Years later Java folks tried to build their own version of Alchemy as part of GraalVM. The project was called Sulong and was using Graal to execute and JIT LLMV bitcode. TruffleRuby was supposed to be a primary early beneficiary to be able to compile and run Ruby native extensions. This was during the period of a race between several JIT solutions in hopes to become "the next Ruby", and Truffle team (along with IBM's OMR) lost the race first to MJIT and then to YJIT. Graal itself seems to loosing steam, because their multi-language VM never got enough adoption among Java, Node, or Ruby people, and the VM itself tended to use too much RAM in era when RAM became premium in the cloud.
In that regard they are doing pretty well.
Plus all the folks that never paid for ExcelsiorJET, JRockit, PTC, Aicas, and many others of which only PTC and Aicas survive, now have in Graal their gratis AOT compiler.
Alongside OpenJ9 (which is more like what Leyden is trying to be), and the one on the box shipped alongside ART.
Ruby on top of JVM has a few interwined stories since the days Sun embraced it on Netbeans, and it suffers from the same issues as PyPy regarding adoption, it suffices not to be 100% compatible with whatever crazy extensions written in C exist out there.
Microsoft was probably more clever giving up on IronPython and IronRuby, and keeping the DLR infrastructure.
And C extensions never got as crazy as in python, and some major ones either made Java backends or switched from MRI embedding to FFI
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/
Pepper was a pun on Native Client (since NaCl = salt). Pepper Plugin API (PPAPI) was Google's more secure version of NPAPI (Netscape Plugin API). Flash Player was essentially the only thing using NPAPI/PPAPI by the end of its life.
Presumably that is because PNaCl predated spectre (?)
Out of curiosity, does that mean that NaCL (without P) only ran on x86? Or were there different subsets for different architectures?
The DevOps infrastructure Kubernetes runbook AI inference router API people (DIK-AROUnders for short) always want an abstract technical solution that increases both their budget and their distance from the end user's actual application. Like the more money they get to dick around with meaningless technical cathedrals, the better. They're only bent out of shape that they couldn't parlay that into a sweet crypto scheme. In the real world, the line between what users actually want and what DIK-AROUnders call inauthentic activity is quite blurred.
To me, the fact that AI agents can browse websites and make payments and read my email and pretend to be me or other people is a huge part of their value proposition. People want to get out of the sandbox! There are many meanings to the words security and privacy.
IIRC a big reason it didn't end up working was because NaCl was such a "big" technology and asm.js such a "small" one that asm.js was able to reach production-ready first despite starting work several years later.
(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)
Users were migrating to us _from_ desktop applications. Collaboration was the key differentiator, but a less well known reason was that improved performance, including but not limited to the support of large design systems, was also a commonly cited reason among paying customers for migrating to Figma.
Desktop or collaborative is a false dichotomy. Desktop or performance is too.
I get why you did what you did. It makes sense. But don’t think there aren’t people out here who HATE everything being shoved on the web with no desktop option.
No, electron and PWA don’t count.
Jokes aside, Figma's stack is super inspiring, and y'all's articles on sync engines heavily inspired my work on LegendKeeper. I appreciate the work you do!
I never communicated this to the team, but I doubt I was alone. All that is not to knock you down, I just wanted to share that being a proper native desktop app does matter to some people for practical reasons other than performance, even if you’re not aware of it.
https://www.destroyallsoftware.com/talks/the-birth-and-death...
(And to those who haven't encountered this before, I strongly recommend a watch. It may be the greatest tech talk of all time, for certain values of greatest.)
Its IR design is horrendeous.
Maybe we've been reading different HN submissions.
And at some point we're going to have a period or war and our psychological attachments to old programming paradigms will be released so that we can move on to a more advanced way of doing things (but that won't stop your bank from running YavaScript for at least another 85 years).
And this is still a killer feature of asm.js, even if it's not 'supported' it's still implicitly supported.
EDIT: And also seriously just thanks to the people who invented asm.js, it was a brilliant idea, but it makes sense that it's not worth optimizing anymore.
12 years on, it’s shocking how much of his fiction became reality.
[0] https://www.destroyallsoftware.com/talks/the-birth-and-death...
This sounds cursed, but customers loved it. Since it wasn't an EXE, it didn't get caught up in their employers' overzealous corporate IT filters. That's why we never switched to Electron. In a sense, we had some of the primeval elements of the thick app.
At least that's always been my impression. If you're willing to go through the effort to use it, it's probably because you need the performance gains, and AI hasn't changed that.
https://webglinsights.github.io/
It was fun to see the rise of asm.js, which was a precursor to Web Assembly. Some of the early demos were so cool to see; Unreal Engine running in the browser. :) Bitter sweet to see the sun set here, but it did lead to much better things.
(compiling legacy code with legacy versions of Emscripten is quite frustrating, almost as bad as updating your JS code to be compatible with accumulated changes in the Emscripten ABI)
Nowadays most browser JavaScript VMs converged to very similar designs and optimizations, so even without Odin asm.js code would run pretty fast anyway.
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 zero copy buffers from js to wasm.
Everything is a trade off. The isolation is a good thing, but also a bad thing.
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 buffers from js to wasm
I'm pretty sure you can't do that with asmjs either. There is a proposal for zero-copy buffers with wasm: https://github.com/WebAssembly/memory-control/blob/main/prop...
Had WASM not been adopted we would have SIMD in JS ( probably via asm.js) by now. Because we didn't, JS just cannot compete with WASM in many computationally heavy workflows. We'd also have general purpose JS to Asm.js compilation, with few API restrictions, making writing it much easier.
WASM is that evolution of (strict mode) asm.js. The two really aren't all that different from what they can and can't do.
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.
> You can't call most web apis from wasm.
You can't from strict asm.js either, since it only supports numbers (no JS strings or objects) and manages the C heap in an ArrayBuffer object just like WASM.
> But more important for what i was trying to do, you can't zero copy buffers from js to wasm.
Same problem as above, you need to call out into "real" Javascript from asm.js and you can't map other ArrayBuffers directly into the 'asm.js heap' either, a copy is needed. The "Javascript FFI" really isn't much different between asm.js and WASM.
AFAIK as soon as you'd start mixing idiomatic JS and asm.js, you lose the "special sauce", you only got the special asm.js treatment in browsers when putting a "use asm" at the top of a source file, and that would prevent using regular JS features in the same file.
> An asm.js module can take up to three optional parameters, providing access to external JavaScript code and data:
> - a standard library object, providing access to a limited subset of the JavaScript standard libraries;
> - a foreign function interface (FFI), providing access to custom external JavaScript functions; and
> - a heap buffer, providing a single ArrayBuffer to act as the asm.js heap.
From http://asmjs.org/spec/latest/#introduction:~:text=External%2...
In asm.js you have to treat JS functions and objects as special extern values, just like in WASM.
asm.js - when validated and optimized - is closer to WASM serialized to a JS-like syntax than actual JS.
https://monkeyink.com/ink/blog/archives/2016/08/_this_is_a_f...
"The image is a collage of antique open source art reflecting the open source code."
https://www.assemblyscript.org/
While in JS you would probably use https://www.npmjs.com/package/binaryen
this was such a crazy project. remember when we compiled our c++ to wasm over 10 years ago, wait, this works?! web seemed to move so fast then.
https://acko.net/blog/on-asmjs/
It allowed it to be an experiment that could have been quickly rolled out without a risk of forever lingering as a back-compat requirement for browsers.
Furthermore, if you use wasm, you'll have fewer bounds checks (because of better memory allocation strategies[1]), access to SIMD, bulk memory operations, and a host of other niceties that have been added to wasm over the years. If your asm.js code is outperforming someone else's wasm code, that probably just means their wasm code is worse.
[1]: https://spidermonkey.dev/blog/2025/01/15/is-memory64-actuall...
wasm hashing in chrome is half the speed of firefox for me.
https://theultdev.github.io/web-sha256-benchmark
I took off the shelf wasm crypto libraries to compare it, but the leading one was 10x slower.
will try to rip it out of the project and put it in a standalone benchmark.
Last time I tried https://github.com/Daninet/hash-wasm
edit: I focus on browsers, that's wasm but not for browser envs.
----
https://theultdev.github.io/web-sha256-benchmark
https://github.com/TheUltDev/web-sha256-benchmark
seems it is chrome wasm that is slow.
asmjs is about the same speed in chrome and firefox (with asm optimizations still enabled) but wasm is slow as hell in chrome, asm still better.
side note: someone mentioned native crypto.subtle, but that doesn't have incremental hashing so can't use it for large files. however I do use it in practice for smaller files.
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).
https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt...
Edit: oh, and it forces async.
I do use it for smaller files though, it's much faster.
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).
I don't think Chrome ever did an asm.js specific optimization.
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.
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.