7 ms·

Www which WASM works

185 points by 2bluesc 3y ago

schemescape 3y ago
Are the missing imports only needed for WASI? When I ran into that situation in the past, the imports had reasonable names (e.g. "fd_write"). Which WebAssembly toolchain is just using letters of the alphabet? Is that common practice now?
- brabel 3y ago
  It seems libjxl does not compile for WASI, but for emscripten. Hence that minified JS is likely the emscripten glue code that's required at runtime, but which the libjxl documentation fails to mention clearly (as it just tells users to run some python script and get a magic file included at runtime). To run that outside the browser, the author will need to generate a emcripten runtime that works with WASI, which as far as I know is not possible.
  - schemescape 3y ago
    Thanks! That makes sense. I’m a little surprised that the author didn’t mention Emscripten, if that’s the case.
dwattttt 3y ago
It's normal for JS tooling to minify symbol names in order to shrink the amount of JS being pushed to user agents; those a... symbols might actually have sensible names somewhere along the compilation pipeline.
- capitainenemo 3y ago
  I do wish this was less common. It's kinda hostile to any users who might want to fire up a debugger for learning or solving a problem with your site, and as we can see can mess with developers too. And while it does speed up load time a bit in JS engines, this was never a measurable amount in any JS library I used. Bytes pushed out from the site were only slightly lower than the non-minified, since both were compressed in transit anyway.
  - strbean 3y ago
    That's what source maps are for (assuming they work). Still leads to strangeness when the minified code doesn't have statements that corresponds 1:1 with the original code.
    - capitainenemo 3y ago
      Assuming they are working and were created yeah. It just seems like another hack layer on top of something that really doesn't seem to add much in the first place. I mean, if you're wanting every last bit of performance, maybe just use WASM or something? Bonus, always obfuscated.
  - capitainenemo 3y ago
    Hm... I guess the user hostile could be a feature not a bug. Obfuscation.
  - aragonite 3y ago
    Examining this kind of (unintentionally) obfuscated code can be a learning opportunity as well. Forgetting the intuitive meaning of symbols is often helpful in doing mathematical proofs (I think Weyl has a famous quote about that). Who knows, maybe the same is true of programming! I've been trying to train myself to to read code purely based on their form, replacing variables names by purely unsuggestive random letters and training myself to visually pattern match first elementary, then increasingly complicated patterns. Still too early to tell whether this will lead anywhere. But in some cases it definitely saved me time by removing the temptation to wonder what the original author's "thinking" was behind this or that choice of variable/function name.
  - gitgud 3y ago
    > It's kinda hostile to any users who might want to fire up a debugger for learning or solving a problem with your site It’s intentional, as commercial sites don’t want you to know how it actually works, as you could steal it. Business cannot exist without secrecy…
airstrike 3y ago
> Ah, I see now why they didn’t feel the need to document these imports. They’re so simple and obvious, it probably never occurred to anybody that this would benefit from documentation. I like that the list starts with “b” and ends with “a”. LMAO absolutely hilarious thanks for sharing this
- deleted 3y ago
  [deleted]
- earthboundkid 3y ago
  ESBuild will try to use variables so that they have better gzip compression, so it’s plausible the imports would receive minified names out of order.
  - airstrike 3y ago
    I understand that. It's still a funny read
Conlectus 3y ago
From what I can tell the issue here is that the author has produced a WASM module with minified dynamic dependencies. This is not an issue with the runtimes but with the earlier compilation toolchain. In another thread it was suggested that Emscripten was used, but its runtime wasn’t provided.
AgentME 3y ago
Anything built with emscripten expects the emscripten runtime to be provided for those imports. The default output of emscripten isn't a WASM file that's meant to be used on its own, but a WASM file plus a JS file that sets up the runtime. It looks like they're trying to use the WASM file on its own and running into the problems that come from that. Standards like WASI are meant to define a common runtime for WASM modules. A WASM module built for WASI would fit the author's expectations better (as they could possibly find an all-in-one WASM+WASI library or attach a WASI implementation to a WASM library to run the WASM file), though I don't know anything about emscripten and WASI compatibility. Edit: You can use the STANDALONE_WASM emscripten option to make it not depend on the emscripten runtime and use WASI instead. This is what the author should use.
- brabel 3y ago
  The problem is that the instructions for actually running the WASM file are not that clear... the docs the author mentions shows how to compile to WASM, which is easy enough, but then here's the instructions to make that actually work in the browser: https://github.com/libjxl/libjxl/blob/main/tools/wasm_demo/README.md https://github.com/libjxl/libjxl/blob/main/tools/wasm_demo/R... Yeah, you need some mysterious Python script, a JS service worker at runtime, choose whether you want the WASM or WASM_SIMD target, use a browser that supports Threads and SIMD if you chose that, make sure to serve everything with the appropriate custom HTTP headers... just reading that, I can see that to get this stuff working on non-browser WASM targets would likely require expertise in WASM, which is the point of the OP. WASM's UX is just not there yet.
  - meheleventyone 3y ago
    Most of the stuff there has nothing to do with WASM itself though. Loading an running a WASM module is very simple. In this case it’s mostly web craziness like bundling and the hoops you have to jump through to enable some features post-spectre mitigations. Then seemingly that the go runtimes suck.
- flohofwoe 3y ago
  It's straightforward to create a WASI executable with Emscripten: emcc hello.c -o hello.wasm This generates a single self-contained .wasm file that's runnable as 'WASI executable': wasmtime hello Hello World! Some advice for C/C++ library design to make life easier for users in such 'esoteric environments': - distribute as source code, ideally as a small number of .h and .c files - ideally don't distribute any build system files, instead make the library configurable via a handful of preprocessor defines, list those defines in the readme - don't have builtin IO calls such as fopen/fread/fclose, instead let the library user provide any data to be processed in memory - don't have built-in multithreading calls, instead provide functions which allow processing data in slices, so that the library user can easily call those 'slice functions' from multiple threads (or a similar solution to prevent multithreading from being baked into the library) - ideally let the user also override memory allocation functions
evmar 3y ago
This is a disappointing post -- they picked up a complex thing that they didn't fully understand, pushed some buttons, and then complained when it didn't work as they expected. I expect more from this blogger, whose content I think of as usually good.
- klysm 3y ago
  Well why not write about it? I don’t see this as “bad” content
  - deleted 3y ago
    [deleted]
- refulgentis 3y ago
  Being perfectly frank: this really resonated with me. I fought through all this about 18 months ago and it was worth it. Tried again 3 months ago and it was impossible, gave it a solid 3-5 days before I pulled back and just did FFI on native and JS on web. WASM has an extremely high learning curve and this post did a great job representing it. Even the "oh you just need X Y and Z" post is indecipherable to me and I learned the acronyms, again, just 3 months ago. EDIT: this comment https://news.ycombinator.com/item?id=37629619 https://news.ycombinator.com/item?id=37629619
  - djur 3y ago
    The post carefully avoids making any more expansive claims than "I tried to use WASM in the most obvious way apparent to me and ran into a lot of difficulties". What this implies for the grandiose claims of some WASM boosters is left to the reader to determine. (And I'd describe myself as fairly pro-WASM myself.) In that sense it's a great counterbalance to the hundreds of "here's how I used WASM to accomplish some trivial or meaningless task" pieces you see out there.
- Grimburger 3y ago
  I had a good laugh at it, it was relatable. They are right about the DX with wasm, it's simply not there. Those error messages are all too common and there's a lot of vague things going on when you compile it down. The whole ecosystem is quite fragmented and a bit of a mess.
SCSIfloppy 3y ago
I just turn this stuff off for now, the only use I can see for it is unskippable / unblockable ads no matter what neat things are theoretically possible. Soon we'll have "booter" sites which suck their data from who knows where, without the browser being able to intercept and block the baddies.
- ygouzerh 3y ago
  [dead]
- incrudible 3y ago
  There is nothing that WASM can do to interfere with adblocking that Javascript can not already do. The reason ads remain blockable is logistics. You want to serve the ads from a different server, if for no other reason than billing.
lucgagan 3y ago
This title makes little sense
- airstrike 3y ago
  I think that's the point
artdigital 3y ago
The native Golang wasm support isn’t bad actually. It gives you a js file with the bindings to import, then load the wasm binary that got built with the normal ‘go build’ command Not the smallest binary, but I had good success with it. Needs a bit of glue for making it run nicely in both browser and node environment at the same time because of different imports and runtime, but outside of publishing npm packages you don’t really need that anyway
jwilk 3y ago
The page doesn't load for me. Archived copy: https://web.archive.org/web/20230922182842/https://flak.tedunangst.com/post/www-which-wasm-works https://web.archive.org/web/20230922182842/https://flak.tedu...
thecupisblue 3y ago
As someone who's been toying with wasm runtimes for the last year or two in bursts, I feel this pain so much. Just yesterday I was like "hey let's try this thing I tried last year but was too messy, WASM had advanced". And oh man, what a ride it was. The WASM ecosystem DX is in a terrible state. First, the "choose a runtime" part is a timesink in itself. Which one is WASI compliant, what are the supported features, is it active, is it stable, how are the docs (mostly terrible), what are the issues? And invariably you get into the Wasmer debate on the way and using other engines with WASI or their engine and WASIX. If I depend on a VC funded runtime, will the company survive, will it be free? After choosing a runtime, installing it, setting the host and guest project up, you can finally.. wait, what? do I need to use wit-bindgen first to generate bindings? No, wait the compiler uses `wasi_snapshot_preview1` for which I need to use adapters to use with `wit-bindgen`? Another rabbit hole to dive into. Then finally, you start working and try to do it by the docs - you get some minimal cases covered and are left to sift through the code, comments and github issues to actually understand what the authors meant and how we should use the API. Instead of showing `guest language` code you compile and embed, they show minified WAT that exports a function returning a hardcoded number. "Oh sorry, you want to try anything else? Good luck and grab your towel while you navigate the WASM universe with it's insane amount of WASM 101 tutorials." I understand it's early, I understand it's in progress, but man there is a ton to improve on the DX side alone. It feels like the race went to "enable every language ever and make the fastest runtime around" vs "actually support people to properly adopt and build upon the ecosystem". And if it feels like that for someone who understands what's going on and has patience to sift through the docs and the code, I can't imagine how it is for somebody just hearing about it or starting to work on it. In the end, I managed to implement what I wanted, but it took me a ton of glue and deep dives and searches just to get it running in it's primitive state relying on API's that will break in a month or two. And while I'm okay with sniffing that much glue for a weekend project, a lot of developers won't be, reducing the reach and adoption by a large margin. Don't get the rant wrong tho - I absolutely love WASM and find it super fun. Hell, I even enjoy reading WASM code itself and figuring out what it does. But damn, the DX side _needs_ some serious improvements.
- NohatCoder 3y ago
  It has been almost 6 years since all major browsers first supported WASM. Can you really call that early?
jedisct1 3y ago
When targeting Emscripten, why not use a regular web engine like V8? Wazero and Wasmer have some support for the Emscripten API, but it's unlikely to be as mature as the real thing backed by Javascript.
NohatCoder 3y ago
I really don't get the WebAssembly design. It is not Assembly, it doesn't offer any of the benefits of Assembly. The only thing that makes it assembly-like is that it is completely unreadable and mostly unwritable to humans. For those who don't know, WebAssembly implements a stack machine VM, the only appreciable effect of this design decision is that all code becomes spaghetti code. We could have made a simple AOT-compileable Basic/C/Java-like language, called it a web standard and let people decide for themselves how many layers of compilers they would like to stick in front. But no, that would make everything too easy to debug. We gotta have an incomprehensible binary file, because that looks fast the same way a red car does.
- hmry 3y ago
  WASM doesn't require a VM, you can compile it AOT just fine. There is really no difference between a C-like language that every browser engine would have to parse and compile, and WASM. Except that parsing WASM is easier and faster, and it uses less bandwidth to send over the wire.
  - __MatrixMan__ 3y ago
    Is a browser not a VM? I'm interested in WASM because it appears to do JVM things, but without getting you sued or making you write Java.
    - hmry 3y ago
      When I said WASM doesn't require a VM, I meant it doesn't need fallback byte-code interpreters, multi-tier instrumented tracing compilers, invasive managed memory, deoptimization checks, etc. Just compiling it once and running that compiled code is fine.
  - NohatCoder 3y ago
    It is a virtual machine by the normal definition of the word, doesn't mean it can't be AOT compiled. The part of parsing that can be skipped is a minuscule part of compilation, won't do much for performance. I guess that the binary representation could theoretically be a bit smaller. However the current status is that compilers need to ship a fair amount runtime stuff, like an allocator and basic string handling, so the resulting binary isn't necessarily smaller than the source code of a fully featured language. That of course weighs down compilation as well.
yebyen 3y ago
I'm guessing (it appears to be true) that every single one of the people writing about their issues here (1) didn't try Spin, because (2) they're intent on targeting a web browser as a runtime environment, and (3) Spin does not run there. The DX in Wasm is pretty complicated, but it gets a lot better IMO through Spin. But that was a marketing name and a campaign that worked apparently too well. I try to think of it as a naming failure, and tell everyone I can that Wasm isn't for web browsers. I mean, it can run in a web browser, sure, but if what you're building is a server, the chances that you're going to want to run it in a web browser in the end are practically nil, aren't they? (I guess for the author, that wasn't exactly true.) And everyone I know is building servers, or something like a component that should sit behind a server, or libraries for command line. Nobody I know is building flash games, or planning on extracting compute out of their users who arrive via web-browser, none of our code needs to run in the browser sandbox, and nobody I know would pick up Wasm for that reason (unless by some fluke they really needed to do that, and it was the thing they had been told that Wasm was supposed to do. Which many people apparently have been told by now!) It is for sure a thing that has been promised (Wasm is for web browsers) and must be delivered, but I don't think it's where the implementation of Wasm is going to take off right now. I think people need to take their server-side apps and achieve those 1000x performance gains that have been promised, reshape their runtime profiles to be serverless-capable as it's done with the Spin runtime, and then I really do think things will start to improve for the rest of us as the tooling matures. If you spend a lot of money on servers and you can spend less money on servers by making them start up very quickly, and shutting them down when they're not actively serving requests, then you can save a lot of money. That's the story that Spin is telling, and that's where I expect to see the movement happening at first, especially if we are heading into a recession as has been predicted by almost everybody. If you are spending money on waste, now is a great time to try and cut it out. Web Assembly has great potential to help with this.
- josteink 3y ago
  > I mean, it can run in a web browser, sure, but if what you're building is a server, the chances that you're going to want to run it in a web browser in the end are practically nil, aren't they? We’ve been able to compile almost any language to native code runnable on a server for several decades. That problem is solved. We don’t need any new tech here. The big thing about WebAssembly was that it promised us the ability to do that in the browser too, where we until recently were cursed with JavaScript as our only option to run code. So yes. People intend to use WebAssembly in the browser. For many people that is its primary and only use-case.
nilslice 3y ago
I see this kind of problem hit people all the time -- the space is still early and teams are figuring it out. Sometimes its just that there is nuanced differences in some of these tools that make it hard to understand "why something doesn't work here since it works there".. like jQuery abstracted browser APIs and unified them into a single one. We built Extism[0] to help ease much of this complexity, and if OP would try this instead of the lower level runtimes directly, they'd see Wasm can actually "just work" the way they want it to. [0]: https://github.com/extism/extism https://github.com/extism/extism

185 points by 2bluesc 3y ago

Are the missing imports only needed for WASI? When I ran into that situation in the past, the imports had reasonable names (e.g. "fd_write"). Which WebAssembly toolchain is just using letters of the alphabet? Is that common practice now?

brabel 3y ago
It seems libjxl does not compile for WASI, but for emscripten. Hence that minified JS is likely the emscripten glue code that's required at runtime, but which the libjxl documentation fails to mention clearly (as it just tells users to run some python script and get a magic file included at runtime). To run that outside the browser, the author will need to generate a emcripten runtime that works with WASI, which as far as I know is not possible.
- schemescape 3y ago
  Thanks! That makes sense. I’m a little surprised that the author didn’t mention Emscripten, if that’s the case.

dwattttt 3y ago

It's normal for JS tooling to minify symbol names in order to shrink the amount of JS being pushed to user agents; those a... symbols might actually have sensible names somewhere along the compilation pipeline.

capitainenemo 3y ago
I do wish this was less common. It's kinda hostile to any users who might want to fire up a debugger for learning or solving a problem with your site, and as we can see can mess with developers too. And while it does speed up load time a bit in JS engines, this was never a measurable amount in any JS library I used. Bytes pushed out from the site were only slightly lower than the non-minified, since both were compressed in transit anyway.
- strbean 3y ago
  That's what source maps are for (assuming they work). Still leads to strangeness when the minified code doesn't have statements that corresponds 1:1 with the original code.
  - capitainenemo 3y ago
    Assuming they are working and were created yeah. It just seems like another hack layer on top of something that really doesn't seem to add much in the first place. I mean, if you're wanting every last bit of performance, maybe just use WASM or something? Bonus, always obfuscated.
- capitainenemo 3y ago
  Hm... I guess the user hostile could be a feature not a bug. Obfuscation.
- aragonite 3y ago
  Examining this kind of (unintentionally) obfuscated code can be a learning opportunity as well. Forgetting the intuitive meaning of symbols is often helpful in doing mathematical proofs (I think Weyl has a famous quote about that). Who knows, maybe the same is true of programming! I've been trying to train myself to to read code purely based on their form, replacing variables names by purely unsuggestive random letters and training myself to visually pattern match first elementary, then increasingly complicated patterns. Still too early to tell whether this will lead anywhere. But in some cases it definitely saved me time by removing the temptation to wonder what the original author's "thinking" was behind this or that choice of variable/function name.
- gitgud 3y ago
  > It's kinda hostile to any users who might want to fire up a debugger for learning or solving a problem with your site It’s intentional, as commercial sites don’t want you to know how it actually works, as you could steal it. Business cannot exist without secrecy…

airstrike 3y ago

> Ah, I see now why they didn’t feel the need to document these imports. They’re so simple and obvious, it probably never occurred to anybody that this would benefit from documentation. I like that the list starts with “b” and ends with “a”. LMAO absolutely hilarious thanks for sharing this

deleted 3y ago
[deleted]
earthboundkid 3y ago
ESBuild will try to use variables so that they have better gzip compression, so it’s plausible the imports would receive minified names out of order.
- airstrike 3y ago
  I understand that. It's still a funny read

Conlectus 3y ago

From what I can tell the issue here is that the author has produced a WASM module with minified dynamic dependencies. This is not an issue with the runtimes but with the earlier compilation toolchain. In another thread it was suggested that Emscripten was used, but its runtime wasn’t provided.

AgentME 3y ago

Anything built with emscripten expects the emscripten runtime to be provided for those imports. The default output of emscripten isn't a WASM file that's meant to be used on its own, but a WASM file plus a JS file that sets up the runtime. It looks like they're trying to use the WASM file on its own and running into the problems that come from that. Standards like WASI are meant to define a common runtime for WASM modules. A WASM module built for WASI would fit the author's expectations better (as they could possibly find an all-in-one WASM+WASI library or attach a WASI implementation to a WASM library to run the WASM file), though I don't know anything about emscripten and WASI compatibility. Edit: You can use the STANDALONE_WASM emscripten option to make it not depend on the emscripten runtime and use WASI instead. This is what the author should use.

brabel 3y ago
The problem is that the instructions for actually running the WASM file are not that clear... the docs the author mentions shows how to compile to WASM, which is easy enough, but then here's the instructions to make that actually work in the browser: https://github.com/libjxl/libjxl/blob/main/tools/wasm_demo/README.md https://github.com/libjxl/libjxl/blob/main/tools/wasm_demo/R... Yeah, you need some mysterious Python script, a JS service worker at runtime, choose whether you want the WASM or WASM_SIMD target, use a browser that supports Threads and SIMD if you chose that, make sure to serve everything with the appropriate custom HTTP headers... just reading that, I can see that to get this stuff working on non-browser WASM targets would likely require expertise in WASM, which is the point of the OP. WASM's UX is just not there yet.
- meheleventyone 3y ago
  Most of the stuff there has nothing to do with WASM itself though. Loading an running a WASM module is very simple. In this case it’s mostly web craziness like bundling and the hoops you have to jump through to enable some features post-spectre mitigations. Then seemingly that the go runtimes suck.
flohofwoe 3y ago
It's straightforward to create a WASI executable with Emscripten: emcc hello.c -o hello.wasm This generates a single self-contained .wasm file that's runnable as 'WASI executable': wasmtime hello Hello World! Some advice for C/C++ library design to make life easier for users in such 'esoteric environments': - distribute as source code, ideally as a small number of .h and .c files - ideally don't distribute any build system files, instead make the library configurable via a handful of preprocessor defines, list those defines in the readme - don't have builtin IO calls such as fopen/fread/fclose, instead let the library user provide any data to be processed in memory - don't have built-in multithreading calls, instead provide functions which allow processing data in slices, so that the library user can easily call those 'slice functions' from multiple threads (or a similar solution to prevent multithreading from being baked into the library) - ideally let the user also override memory allocation functions

evmar 3y ago

This is a disappointing post -- they picked up a complex thing that they didn't fully understand, pushed some buttons, and then complained when it didn't work as they expected. I expect more from this blogger, whose content I think of as usually good.

klysm 3y ago
Well why not write about it? I don’t see this as “bad” content
- deleted 3y ago
  [deleted]
refulgentis 3y ago
Being perfectly frank: this really resonated with me. I fought through all this about 18 months ago and it was worth it. Tried again 3 months ago and it was impossible, gave it a solid 3-5 days before I pulled back and just did FFI on native and JS on web. WASM has an extremely high learning curve and this post did a great job representing it. Even the "oh you just need X Y and Z" post is indecipherable to me and I learned the acronyms, again, just 3 months ago. EDIT: this comment https://news.ycombinator.com/item?id=37629619 https://news.ycombinator.com/item?id=37629619
- djur 3y ago
  The post carefully avoids making any more expansive claims than "I tried to use WASM in the most obvious way apparent to me and ran into a lot of difficulties". What this implies for the grandiose claims of some WASM boosters is left to the reader to determine. (And I'd describe myself as fairly pro-WASM myself.) In that sense it's a great counterbalance to the hundreds of "here's how I used WASM to accomplish some trivial or meaningless task" pieces you see out there.
Grimburger 3y ago
I had a good laugh at it, it was relatable. They are right about the DX with wasm, it's simply not there. Those error messages are all too common and there's a lot of vague things going on when you compile it down. The whole ecosystem is quite fragmented and a bit of a mess.

SCSIfloppy 3y ago

I just turn this stuff off for now, the only use I can see for it is unskippable / unblockable ads no matter what neat things are theoretically possible. Soon we'll have "booter" sites which suck their data from who knows where, without the browser being able to intercept and block the baddies.

ygouzerh 3y ago
[dead]
incrudible 3y ago
There is nothing that WASM can do to interfere with adblocking that Javascript can not already do. The reason ads remain blockable is logistics. You want to serve the ads from a different server, if for no other reason than billing.

lucgagan 3y ago

This title makes little sense

airstrike 3y ago
I think that's the point

artdigital 3y ago

The native Golang wasm support isn’t bad actually. It gives you a js file with the bindings to import, then load the wasm binary that got built with the normal ‘go build’ command Not the smallest binary, but I had good success with it. Needs a bit of glue for making it run nicely in both browser and node environment at the same time because of different imports and runtime, but outside of publishing npm packages you don’t really need that anyway

jwilk 3y ago

The page doesn't load for me. Archived copy: https://web.archive.org/web/20230922182842/https://flak.tedunangst.com/post/www-which-wasm-works https://web.archive.org/web/20230922182842/https://flak.tedu...

thecupisblue 3y ago

As someone who's been toying with wasm runtimes for the last year or two in bursts, I feel this pain so much. Just yesterday I was like "hey let's try this thing I tried last year but was too messy, WASM had advanced". And oh man, what a ride it was. The WASM ecosystem DX is in a terrible state. First, the "choose a runtime" part is a timesink in itself. Which one is WASI compliant, what are the supported features, is it active, is it stable, how are the docs (mostly terrible), what are the issues? And invariably you get into the Wasmer debate on the way and using other engines with WASI or their engine and WASIX. If I depend on a VC funded runtime, will the company survive, will it be free? After choosing a runtime, installing it, setting the host and guest project up, you can finally.. wait, what? do I need to use wit-bindgen first to generate bindings? No, wait the compiler uses `wasi_snapshot_preview1` for which I need to use adapters to use with `wit-bindgen`? Another rabbit hole to dive into. Then finally, you start working and try to do it by the docs - you get some minimal cases covered and are left to sift through the code, comments and github issues to actually understand what the authors meant and how we should use the API. Instead of showing `guest language` code you compile and embed, they show minified WAT that exports a function returning a hardcoded number. "Oh sorry, you want to try anything else? Good luck and grab your towel while you navigate the WASM universe with it's insane amount of WASM 101 tutorials." I understand it's early, I understand it's in progress, but man there is a ton to improve on the DX side alone. It feels like the race went to "enable every language ever and make the fastest runtime around" vs "actually support people to properly adopt and build upon the ecosystem". And if it feels like that for someone who understands what's going on and has patience to sift through the docs and the code, I can't imagine how it is for somebody just hearing about it or starting to work on it. In the end, I managed to implement what I wanted, but it took me a ton of glue and deep dives and searches just to get it running in it's primitive state relying on API's that will break in a month or two. And while I'm okay with sniffing that much glue for a weekend project, a lot of developers won't be, reducing the reach and adoption by a large margin. Don't get the rant wrong tho - I absolutely love WASM and find it super fun. Hell, I even enjoy reading WASM code itself and figuring out what it does. But damn, the DX side _needs_ some serious improvements.

NohatCoder 3y ago
It has been almost 6 years since all major browsers first supported WASM. Can you really call that early?

jedisct1 3y ago

When targeting Emscripten, why not use a regular web engine like V8? Wazero and Wasmer have some support for the Emscripten API, but it's unlikely to be as mature as the real thing backed by Javascript.

NohatCoder 3y ago

I really don't get the WebAssembly design. It is not Assembly, it doesn't offer any of the benefits of Assembly. The only thing that makes it assembly-like is that it is completely unreadable and mostly unwritable to humans. For those who don't know, WebAssembly implements a stack machine VM, the only appreciable effect of this design decision is that all code becomes spaghetti code. We could have made a simple AOT-compileable Basic/C/Java-like language, called it a web standard and let people decide for themselves how many layers of compilers they would like to stick in front. But no, that would make everything too easy to debug. We gotta have an incomprehensible binary file, because that looks fast the same way a red car does.

hmry 3y ago
WASM doesn't require a VM, you can compile it AOT just fine. There is really no difference between a C-like language that every browser engine would have to parse and compile, and WASM. Except that parsing WASM is easier and faster, and it uses less bandwidth to send over the wire.
- __MatrixMan__ 3y ago
  Is a browser not a VM? I'm interested in WASM because it appears to do JVM things, but without getting you sued or making you write Java.
  - hmry 3y ago
    When I said WASM doesn't require a VM, I meant it doesn't need fallback byte-code interpreters, multi-tier instrumented tracing compilers, invasive managed memory, deoptimization checks, etc. Just compiling it once and running that compiled code is fine.
- NohatCoder 3y ago
  It is a virtual machine by the normal definition of the word, doesn't mean it can't be AOT compiled. The part of parsing that can be skipped is a minuscule part of compilation, won't do much for performance. I guess that the binary representation could theoretically be a bit smaller. However the current status is that compilers need to ship a fair amount runtime stuff, like an allocator and basic string handling, so the resulting binary isn't necessarily smaller than the source code of a fully featured language. That of course weighs down compilation as well.

yebyen 3y ago

I'm guessing (it appears to be true) that every single one of the people writing about their issues here (1) didn't try Spin, because (2) they're intent on targeting a web browser as a runtime environment, and (3) Spin does not run there. The DX in Wasm is pretty complicated, but it gets a lot better IMO through Spin. But that was a marketing name and a campaign that worked apparently too well. I try to think of it as a naming failure, and tell everyone I can that Wasm isn't for web browsers. I mean, it can run in a web browser, sure, but if what you're building is a server, the chances that you're going to want to run it in a web browser in the end are practically nil, aren't they? (I guess for the author, that wasn't exactly true.) And everyone I know is building servers, or something like a component that should sit behind a server, or libraries for command line. Nobody I know is building flash games, or planning on extracting compute out of their users who arrive via web-browser, none of our code needs to run in the browser sandbox, and nobody I know would pick up Wasm for that reason (unless by some fluke they really needed to do that, and it was the thing they had been told that Wasm was supposed to do. Which many people apparently have been told by now!) It is for sure a thing that has been promised (Wasm is for web browsers) and must be delivered, but I don't think it's where the implementation of Wasm is going to take off right now. I think people need to take their server-side apps and achieve those 1000x performance gains that have been promised, reshape their runtime profiles to be serverless-capable as it's done with the Spin runtime, and then I really do think things will start to improve for the rest of us as the tooling matures. If you spend a lot of money on servers and you can spend less money on servers by making them start up very quickly, and shutting them down when they're not actively serving requests, then you can save a lot of money. That's the story that Spin is telling, and that's where I expect to see the movement happening at first, especially if we are heading into a recession as has been predicted by almost everybody. If you are spending money on waste, now is a great time to try and cut it out. Web Assembly has great potential to help with this.

josteink 3y ago
> I mean, it can run in a web browser, sure, but if what you're building is a server, the chances that you're going to want to run it in a web browser in the end are practically nil, aren't they? We’ve been able to compile almost any language to native code runnable on a server for several decades. That problem is solved. We don’t need any new tech here. The big thing about WebAssembly was that it promised us the ability to do that in the browser too, where we until recently were cursed with JavaScript as our only option to run code. So yes. People intend to use WebAssembly in the browser. For many people that is its primary and only use-case.

nilslice 3y ago

I see this kind of problem hit people all the time -- the space is still early and teams are figuring it out. Sometimes its just that there is nuanced differences in some of these tools that make it hard to understand "why something doesn't work here since it works there".. like jQuery abstracted browser APIs and unified them into a single one. We built Extism[0] to help ease much of this complexity, and if OP would try this instead of the lower level runtimes directly, they'd see Wasm can actually "just work" the way they want it to. [0]: https://github.com/extism/extism https://github.com/extism/extism