5 ms·

I think one the big things with web assembly is it's shear potential is huge. In theory, WASM could be a single cross platform compile target, which is kind of

I think one the big things with web assembly is it's shear potential is huge. In theory, WASM could be a single cross platform compile target, which is kind of a CS holy grail. It's easy to let your mind spin up a world where everything is web assembly, a desktop enivornment, a server, day to day software applications. After I've imagined all of that, being told web assembly helps some parts of Figma run faster feels like a big let down. Of course that isn't fair, almost nothing could live up to the expectations we have for WASM. Its development is also by committee, which is maybe the best option for our current landscape, but isn't famous for getting things going quickly.

vbezhenar 9mo ago
You can use javascript as a single cross platform compile target. What's the difference?
- merlindru 9mo ago
  WASM works with any language and can be much faster than javascript
  - vbezhenar 9mo ago
    You can compile any language to JavaScript. jslinux compiled x86 machine code to JavaScript. So basically wasm is some optimisation. That's fine but it's not something groundbreaking. And if we remove web from the platform list, there were many portables bytecodes. P-code from Pascal era, JVM bytecode from modern era and plenty of others.
    - IshKebab 9mo ago
      > some optimisation That's underselling it a bit IMO. There's a reason asm.js was abandoned.
      - gf000 9mo ago
        Both undersell and oversell. There are still cases where vanilla JS will be faster. And AFAIK asm.js is the precursor to WASM, like the early implementations just built on top of asm.js's primitives.
      - creata 9mo ago
        Wikipedia mentions that Wasm is faster to parse than asm.js, and I'm guessing Wasm might be smaller, but is there any other reason? I don't think there's any reason for asm.js to have resulted in slower execution than Wasm.
        IshKebab 9mo ago
        > I don't think there's any reason for asm.js to have resulted in slower execution than Wasm The perfect article: https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-than-asm-js/ https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-... Honestly the differences are less than I would have expected, but that article is also nearly a decade old so I would imagine WASM engines have improved a lot since then. Fundamentally I think asm.js was a fragile hack and WASM is a well-engineered solution.
        gr4vityWall 9mo ago
        After reading the, I don't feel convinced abtout the runtime performance advantages of WASM over asm.js. he CPU features mentioned could be added to JS runtimes. Toolchain improvements could go both ways, and I expect asm.js would benefit from JIT improvements over the years. I agree 100% with the startup time arguments made by the article, though. No way around it if you're going through the typical JS pipeline in the browser. The argument for better load/store addressing on WASM is solid, and I expect this to have higher impact today than in 2017, due to the huge caches modern CPUs have. But it's hard to know without measuring it, and I don't know how hard it would be to isolate that in a benchmark. Thank you for linking it. It was a fun read. I hope my post didn't sound adversarial to any arguments you made. I wonder what asm.js could have been if it was formally specified, extended and optimized for, rather than abandoned in favor of WASM.
- hnb2137 9mo ago
  WASM allows you to run some parts of the application a bit faster. ;)
- lxgr 9mo ago
  Javascript comes with mandatory garbage collection. I suppose you could compile any language to an allocation-free semantic subset of Javascript, but it's probably going to be even less pretty than transpiling to Javascript already is.
  - creata 9mo ago
    > it's probably going to be even less pretty than transpiling to Javascript already is. I don't see how it'd be much different to compiling to JavaScript otherwise. Isn't it usually pretty clear where allocations are happening and how to avoid them?
    - lxgr 9mo ago
      “Pretty clear” is good, “guaranteed by language specifications” is better. Why reverse-engineer each JS implementation if you can just target a non-GC runtime instead?
- yencabulator 9mo ago
  WASM, and asm.js before it, roughly exist because Javascript is such a bad compile target.
x3haloed 9mo ago
There’s no reason we shouldn’t be replacing our containers with WASI. Containers are absolutely miserable things that should just be VMs (in the WASM sense, not in the “run Linux in a virtual X86” sense) The tooling is just not there yet. Everyone is just stuck on supporting Docker still.
- IshKebab 9mo ago
  Yeah the real answer is that all of this stuff is still a work in progress. Last I checked WASI doesn't have a concept of "current directory" for example, so porting software is not trivial. Also WASI is a way of running a single process. If your app needs to run subprocesses you'll need to do more work.
- torginus 9mo ago
  Imo stuff like Flatpak has the right idea - provide a rich but controllable set of features, API/ABI compatibility, while providing zero overhead isolation (same as docker since it relies on the same APIs). I also rather like the idea of deploying programs rather than virtual machines. Docker's cardinal sin imo is that it was designed as a monetizable SaaS product, and suffers from inner platform effect, reinventing stuff (package management, lifecycle management etc) that didn't need to be invented.
- hosh 9mo ago
  You mean like this? https://docs.krustlet.dev/howto/wasm/ https://docs.krustlet.dev/howto/wasm/ Or this? https://podman-desktop.io/blog/wasm-workloads-on-macos-and-windows-with-podman https://podman-desktop.io/blog/wasm-workloads-on-macos-and-w...
- creata 9mo ago
  But what's the benefit of replacing containers with WASI? The performance would be worse, and it would be harder to integrate with everything else. It might be more secure, I guess.
- HendrikHensen 9mo ago
  It helps if you actually qualify statements such as "Containers are absolutely miserable things". I'm in a world where were using containers extensively, and I don't experience any issues whatsoever about which one might thing "WASI would be the solution to this".
shevy-java 9mo ago
Well - the problem is... the "in theory" means that nobody will bet on WASM if it is not really going to be useful. People use HTML, CSS, JavaScript - that has been shown to be very useful. WASM is not useless but how can people relate to it? It is like an alien stack for most people.
- frez1 9mo ago
  The way things usually gain traction is when a big tech company has success experimenting with it. it happened with node way back and happening with rust now. the fact we haven't heard much about was use is probably because it isnt as valuable as we think, or no one has played around with it yet to find out
  - matt_kantor 9mo ago
    > when a big tech company has success experimenting with it TFA has many examples of big tech companies using Wasm in production. It's not exhaustive either, e.g. the article doesn't mention: - Google using it as a backend for Flutter and to implement parts of Google Maps, Earth, Meet, Sheets, Keep, YouTube, etc - Microsoft using it in Copilot Studio - eBay using it in their mobile app - MongoDB using it for Compass - Amazon supporting it in EKS - 1Password using it in their browser extension - Unity having it as a build target (And this was just what I found with some quick web searches; I'm sure there are many other examples.) --- > the fact we haven't heard much about was use is probably because it isnt as valuable as we think One of the conclusions of the article is that it's mostly used in ways that aren't very visible.
- azakai 9mo ago
  It is totally fine if most people don't relate to wasm - it's good for some things, but not most things. As another example, most web devs don't use the video or audio tag, I'd bet, and that's fine too. Media, and wasm, are really important when you need them, but usually you don't.
daef 9mo ago
I recommend you watch [0] if you haven't seen it yet, it describes the history of javascript, iirc until 2035. [0] https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- afandian 9mo ago
  Thanks! There's a video I've been looking for, for years. It's about web technologies and recusion ("I put a VM in side a VM"), and it's satire / comedy. It might be this one I'm thinking of, as it closely fits the bill. But something is telling me it's not, and that it was published earlier. Any ideas?
torginus 9mo ago
Like the gifted kid who lives with his mom at 30, at some point in time, we have to stop talking about potential and start talking about results. Theory and practice doesn't match in this case, and many people have remarked that companies that sit on the WhatWG board have vested interest in making sure their lucrative app stores are not threatened by a platform that can run any app just as well. I remember when Native Client came to the scene and allowed people to compile complex native apps to the web that run at like 95% of native speed. While it was in many ways an inelegant solution, it worked better than WebAssembly does today. Another one of WebAssembly's killer features was supposed to be native web integration. How JS engines work is that you have an IDL that describes the interface of JS classes which is then used to generate code to bind to underlying C++ implementations. You could probably bind those to Webassembly just as well. I don't think a cross-platform as in cross CPU arch matters that much, if you meant 'runs on everything' then I concur. Also the dirty secret of WebAssembly is that it's not really faster than JS.
- PunchyHamster 9mo ago
  I start to think that's why there is still no DOM for the WASM and we have to pingping over JS > Also the dirty secret of WebAssembly is that it's not really faster than JS. That is near purely due to amount of work it took to make that shitty language run fast. Naive webassembly implementation will beat interpreted JS many times over but modern JIT implementations are wonder.
  - moralestapia 9mo ago
    I don't dislike JS but the reason why it's fast is because billions were poured into making that happen. V8 is a modern engineering marvel.
    - rob74 9mo ago
      Yeah, and like many engineering marvels, it was instantly misused for purposes its creators didn't intend and became a scourge on humanity (looking at you NodeJS & co).
    - 9mo ago
jiggawatts 9mo ago
> WASM could be a single cross platform compile target, which is kind of a CS holy grail. The JVM says "Hello!" from 1995.
- benrutter 9mo ago
  Hello back! The JVM is a great parallel example. Anyone listening to the hype in the early days based around what the JVM could be would surely be disappointed now. It isn't faster than C, it doesn't see use everywhere due to practical constraints, etc. But you'd be hard pushed to say the JVM is a total failure. It's used by lots all round the world, and solves real problems, just not the ones we were hoping it would solve. I suspect the future of WASM looks something like that.
  - DonHopkins 9mo ago
    Now JVM's sole purpose is to solve Larry Ellison's problems, so if you're not Larry Ellison and you don't have the same problems he does, then it's a total failure caging you, but a predatory trap serving him. None of the technical arguments for JVM matter any more. It's just bait to trick you into sticking your hand under the lawnmower and helping Larry Ellison solve his problems.
    - pjmlp 9mo ago
      Except JetBrains, Red-Hat, SAP, Azul, Oracle, Google, Microsoft, PTC, Aicas, Cisco, Ricoh, microEJ, Bluejay,... are also part of the Java party.
      - jiggawatts 9mo ago
        Microsoft largely cloned the Java Runtime to create the .NET Runtime and similarly cloned Java to create C#. The two are so similar that Java bytecode to .NET bytecode translators exist. With some, it is possible to take a class defined in Java, subclass it with C#, call it from Java, etc...
whywhywhywhy 9mo ago
> being told web assembly helps some parts of Figma run faster feels like a big let down. Not really when tools like Figma were not really possible before it
- creata 9mo ago
  What was preventing the development of Figma before Wasm? For developing brand new code, I don't think there's anything fundamentally impossible without Wasm, except SIMD.
  - azakai 9mo ago
    Performance. JS can be as fast as wasm, but generally isn't on huge, complex applications. Wasm was designed for things like Unity games, Adobe Photoshop, and Figma - that is why they all use it. Benchmarks on such applications usually show a 2x speedup for wasm, and much faster startup (by avoiding JS tiering). Also, the ability to recompile existing code to wasm is often important. Unity or Photoshop could, in theory, write a new codebase for the Web, but recompiling their existing applications is much more appealing, and it also reuses all their existing performance work there.
- pjmlp 9mo ago
  Yet Figma like tools do exist without Wasm.
xnx 9mo ago
*sheer shear potential = likely to break apart
- benrutter 9mo ago
  Haha, shear potential seems like a great accidental pun. I'll have to find an excuse to use it deliberately over the next week.
deleted 9mo ago
[deleted]
lionkor 9mo ago
Java and JVM all over again

vbezhenar 9mo ago

You can use javascript as a single cross platform compile target. What's the difference?

merlindru 9mo ago
WASM works with any language and can be much faster than javascript
- vbezhenar 9mo ago
  You can compile any language to JavaScript. jslinux compiled x86 machine code to JavaScript. So basically wasm is some optimisation. That's fine but it's not something groundbreaking. And if we remove web from the platform list, there were many portables bytecodes. P-code from Pascal era, JVM bytecode from modern era and plenty of others.
  - IshKebab 9mo ago
    > some optimisation That's underselling it a bit IMO. There's a reason asm.js was abandoned.
    - gf000 9mo ago
      Both undersell and oversell. There are still cases where vanilla JS will be faster. And AFAIK asm.js is the precursor to WASM, like the early implementations just built on top of asm.js's primitives.
    - creata 9mo ago
      Wikipedia mentions that Wasm is faster to parse than asm.js, and I'm guessing Wasm might be smaller, but is there any other reason? I don't think there's any reason for asm.js to have resulted in slower execution than Wasm.
      - IshKebab 9mo ago
        > I don't think there's any reason for asm.js to have resulted in slower execution than Wasm The perfect article: https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-than-asm-js/ https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-... Honestly the differences are less than I would have expected, but that article is also nearly a decade old so I would imagine WASM engines have improved a lot since then. Fundamentally I think asm.js was a fragile hack and WASM is a well-engineered solution.
        gr4vityWall 9mo ago
        After reading the, I don't feel convinced abtout the runtime performance advantages of WASM over asm.js. he CPU features mentioned could be added to JS runtimes. Toolchain improvements could go both ways, and I expect asm.js would benefit from JIT improvements over the years. I agree 100% with the startup time arguments made by the article, though. No way around it if you're going through the typical JS pipeline in the browser. The argument for better load/store addressing on WASM is solid, and I expect this to have higher impact today than in 2017, due to the huge caches modern CPUs have. But it's hard to know without measuring it, and I don't know how hard it would be to isolate that in a benchmark. Thank you for linking it. It was a fun read. I hope my post didn't sound adversarial to any arguments you made. I wonder what asm.js could have been if it was formally specified, extended and optimized for, rather than abandoned in favor of WASM.
hnb2137 9mo ago
WASM allows you to run some parts of the application a bit faster. ;)
lxgr 9mo ago
Javascript comes with mandatory garbage collection. I suppose you could compile any language to an allocation-free semantic subset of Javascript, but it's probably going to be even less pretty than transpiling to Javascript already is.
- creata 9mo ago
  > it's probably going to be even less pretty than transpiling to Javascript already is. I don't see how it'd be much different to compiling to JavaScript otherwise. Isn't it usually pretty clear where allocations are happening and how to avoid them?
  - lxgr 9mo ago
    “Pretty clear” is good, “guaranteed by language specifications” is better. Why reverse-engineer each JS implementation if you can just target a non-GC runtime instead?
yencabulator 9mo ago
WASM, and asm.js before it, roughly exist because Javascript is such a bad compile target.

x3haloed 9mo ago

There’s no reason we shouldn’t be replacing our containers with WASI. Containers are absolutely miserable things that should just be VMs (in the WASM sense, not in the “run Linux in a virtual X86” sense) The tooling is just not there yet. Everyone is just stuck on supporting Docker still.

IshKebab 9mo ago
Yeah the real answer is that all of this stuff is still a work in progress. Last I checked WASI doesn't have a concept of "current directory" for example, so porting software is not trivial. Also WASI is a way of running a single process. If your app needs to run subprocesses you'll need to do more work.
torginus 9mo ago
Imo stuff like Flatpak has the right idea - provide a rich but controllable set of features, API/ABI compatibility, while providing zero overhead isolation (same as docker since it relies on the same APIs). I also rather like the idea of deploying programs rather than virtual machines. Docker's cardinal sin imo is that it was designed as a monetizable SaaS product, and suffers from inner platform effect, reinventing stuff (package management, lifecycle management etc) that didn't need to be invented.
hosh 9mo ago
You mean like this? https://docs.krustlet.dev/howto/wasm/ https://docs.krustlet.dev/howto/wasm/ Or this? https://podman-desktop.io/blog/wasm-workloads-on-macos-and-windows-with-podman https://podman-desktop.io/blog/wasm-workloads-on-macos-and-w...
creata 9mo ago
But what's the benefit of replacing containers with WASI? The performance would be worse, and it would be harder to integrate with everything else. It might be more secure, I guess.
HendrikHensen 9mo ago
It helps if you actually qualify statements such as "Containers are absolutely miserable things". I'm in a world where were using containers extensively, and I don't experience any issues whatsoever about which one might thing "WASI would be the solution to this".

shevy-java 9mo ago

Well - the problem is... the "in theory" means that nobody will bet on WASM if it is not really going to be useful. People use HTML, CSS, JavaScript - that has been shown to be very useful. WASM is not useless but how can people relate to it? It is like an alien stack for most people.

frez1 9mo ago
The way things usually gain traction is when a big tech company has success experimenting with it. it happened with node way back and happening with rust now. the fact we haven't heard much about was use is probably because it isnt as valuable as we think, or no one has played around with it yet to find out
- matt_kantor 9mo ago
  > when a big tech company has success experimenting with it TFA has many examples of big tech companies using Wasm in production. It's not exhaustive either, e.g. the article doesn't mention: - Google using it as a backend for Flutter and to implement parts of Google Maps, Earth, Meet, Sheets, Keep, YouTube, etc - Microsoft using it in Copilot Studio - eBay using it in their mobile app - MongoDB using it for Compass - Amazon supporting it in EKS - 1Password using it in their browser extension - Unity having it as a build target (And this was just what I found with some quick web searches; I'm sure there are many other examples.) --- > the fact we haven't heard much about was use is probably because it isnt as valuable as we think One of the conclusions of the article is that it's mostly used in ways that aren't very visible.
azakai 9mo ago
It is totally fine if most people don't relate to wasm - it's good for some things, but not most things. As another example, most web devs don't use the video or audio tag, I'd bet, and that's fine too. Media, and wasm, are really important when you need them, but usually you don't.

daef 9mo ago

I recommend you watch [0] if you haven't seen it yet, it describes the history of javascript, iirc until 2035. [0] https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

afandian 9mo ago
Thanks! There's a video I've been looking for, for years. It's about web technologies and recusion ("I put a VM in side a VM"), and it's satire / comedy. It might be this one I'm thinking of, as it closely fits the bill. But something is telling me it's not, and that it was published earlier. Any ideas?

torginus 9mo ago

Like the gifted kid who lives with his mom at 30, at some point in time, we have to stop talking about potential and start talking about results. Theory and practice doesn't match in this case, and many people have remarked that companies that sit on the WhatWG board have vested interest in making sure their lucrative app stores are not threatened by a platform that can run any app just as well. I remember when Native Client came to the scene and allowed people to compile complex native apps to the web that run at like 95% of native speed. While it was in many ways an inelegant solution, it worked better than WebAssembly does today. Another one of WebAssembly's killer features was supposed to be native web integration. How JS engines work is that you have an IDL that describes the interface of JS classes which is then used to generate code to bind to underlying C++ implementations. You could probably bind those to Webassembly just as well. I don't think a cross-platform as in cross CPU arch matters that much, if you meant 'runs on everything' then I concur. Also the dirty secret of WebAssembly is that it's not really faster than JS.

PunchyHamster 9mo ago
I start to think that's why there is still no DOM for the WASM and we have to pingping over JS > Also the dirty secret of WebAssembly is that it's not really faster than JS. That is near purely due to amount of work it took to make that shitty language run fast. Naive webassembly implementation will beat interpreted JS many times over but modern JIT implementations are wonder.
- moralestapia 9mo ago
  I don't dislike JS but the reason why it's fast is because billions were poured into making that happen. V8 is a modern engineering marvel.
  - rob74 9mo ago
    Yeah, and like many engineering marvels, it was instantly misused for purposes its creators didn't intend and became a scourge on humanity (looking at you NodeJS & co).
  - 9mo ago

jiggawatts 9mo ago

> WASM could be a single cross platform compile target, which is kind of a CS holy grail. The JVM says "Hello!" from 1995.

benrutter 9mo ago
Hello back! The JVM is a great parallel example. Anyone listening to the hype in the early days based around what the JVM could be would surely be disappointed now. It isn't faster than C, it doesn't see use everywhere due to practical constraints, etc. But you'd be hard pushed to say the JVM is a total failure. It's used by lots all round the world, and solves real problems, just not the ones we were hoping it would solve. I suspect the future of WASM looks something like that.
- DonHopkins 9mo ago
  Now JVM's sole purpose is to solve Larry Ellison's problems, so if you're not Larry Ellison and you don't have the same problems he does, then it's a total failure caging you, but a predatory trap serving him. None of the technical arguments for JVM matter any more. It's just bait to trick you into sticking your hand under the lawnmower and helping Larry Ellison solve his problems.
  - pjmlp 9mo ago
    Except JetBrains, Red-Hat, SAP, Azul, Oracle, Google, Microsoft, PTC, Aicas, Cisco, Ricoh, microEJ, Bluejay,... are also part of the Java party.
    - jiggawatts 9mo ago
      Microsoft largely cloned the Java Runtime to create the .NET Runtime and similarly cloned Java to create C#. The two are so similar that Java bytecode to .NET bytecode translators exist. With some, it is possible to take a class defined in Java, subclass it with C#, call it from Java, etc...

whywhywhywhy 9mo ago

> being told web assembly helps some parts of Figma run faster feels like a big let down. Not really when tools like Figma were not really possible before it

creata 9mo ago
What was preventing the development of Figma before Wasm? For developing brand new code, I don't think there's anything fundamentally impossible without Wasm, except SIMD.
- azakai 9mo ago
  Performance. JS can be as fast as wasm, but generally isn't on huge, complex applications. Wasm was designed for things like Unity games, Adobe Photoshop, and Figma - that is why they all use it. Benchmarks on such applications usually show a 2x speedup for wasm, and much faster startup (by avoiding JS tiering). Also, the ability to recompile existing code to wasm is often important. Unity or Photoshop could, in theory, write a new codebase for the Web, but recompiling their existing applications is much more appealing, and it also reuses all their existing performance work there.
pjmlp 9mo ago
Yet Figma like tools do exist without Wasm.

xnx 9mo ago

*sheer shear potential = likely to break apart

benrutter 9mo ago
Haha, shear potential seems like a great accidental pun. I'll have to find an excuse to use it deliberately over the next week.

deleted 9mo ago

[deleted]

lionkor 9mo ago

Java and JVM all over again