Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making WebAssembly a first-class language on the Web

hacks.mozilla.org

Post reply on HN
Print view View original

21–30 of 287 posts

Re: Making WebAssembly a first-class language on the Web

#21

Post by eqrion »

flohofwoe wrote: post #6

It's still not a great idea IMHO ;) (there was also some more recent discussion in here: https://news.ycombinator.com/item?id=47295837 ) E.g. it feels like a lot of over-engineering just to get 2x faster string marshalling, and this is only important for exactly one use case: for creating a 1:1 mapping of the DOM API to WASM. Most other web APIs are by far not as 'granular' and string heavy as the DOM. E.g. if I main…

I agree there are some cases that won't see a huge boost, but also DOM performance is a big deal and bottleneck for a lot of applications.

And besides performance, I think there are developer experience improvements we could get with native wasm component support (problems 1-3). TBH, I think developer experience is one of the most important things to improve for wasm right now. It's just so hard to get started or integrate with existing code. Once you've learned the tricks, you're fine. But we really shouldn't be requiring everyone to become an expert to benefit from wasm.

Re: Making WebAssembly a first-class language on the Web

#22

Post by swiftcoder »

pizlonator wrote: post #12
eqrion wrote: post #10

Earlier quoted context omitted.

I'm not sure I follow this. > WebAssembly is the wrong abstraction for running untrusted apps in a browser WebAssembly is a better fit for a platform running untrusted apps than JS. WebAssembly has a sandbox and was designed for untrusted code. It's almost impossible to statically reason about JS code, and so browsers need a ton of error prone dynamic security infrastructure to protect themselves from guest JS code.…

> WebAssembly has a sandbox and was designed for untrusted code. So does JavaScript. > It's almost impossible to statically reason about JS code, and so browsers need a ton of error prone dynamic security infrastructure to protect themselves from guest JS code. They have that infrastructure because JS has access to the browser's API. If you tried to redesign all of the web APIs in a way that exposes them to WebAssemb…

> Then what's your excuse for why wasm, despite years of investment, is a dud on the web?

It's not really a dud on the web. It sees a ton of use in bringing heavier experiences to the browser (i.e Figma, the Unity player, and so on).

Where it is currently fairly painful is in writing traditional websites, given all the glue code required to interact with the DOM - exactly what these folks are trying to solve.

Re: Making WebAssembly a first-class language on the Web

#23

Post by skybrian »

flohofwoe wrote: post #13
pizlonator wrote: post #8

Earlier quoted context omitted.

Then give me a counterargument instead of just saying that I'm wrong. My points are validated by the reality that most of the web is JavaScript, to the point that you'd have a hard time observing degradation of experience if you disabled the wasm engine.

I created and maintain a couple of WASM projects and have not experienced the problems you describe: - https://floooh.github.io/tiny8bit/ - https://floooh.github.io/sokol-webgpu/ - https://floooh.github.io/visualz80remix/ - https://floooh.github.io/doom-sokol/ All those projects also compile into native Windows/Linux/macOS/Android/iOS executables without any code changes, but compiling to WASM and running in web brow…

What toolchain do you use to build your apps?

Re: Making WebAssembly a first-class language on the Web

#24

Post by koolala »

Every new standard today doesn't care about being clean and simple to use. They all maximize the JS boilerplate needed to make a basic example work. Everything is designed today for 'engineers' and not 'authors' without any friendly default workflow. I'm glad they still care about this.

Re: Making WebAssembly a first-class language on the Web

#25

Post by pizlonator »

flohofwoe wrote: post #19
pizlonator wrote: post #16

Earlier quoted context omitted.

The fact that you made some webassembly things isn't an answer to the question of why webassembly is not used by the overwhelming majority of websites.

> why webassembly is not used by the overwhelming majority of websites This is such a bizarre take that I don't know whether it's just a trolling attempt or serious... Why should web-devs switch to WASM unless they have a specific problem to solve where WASM is the better alternative to JS? The two technologies live side by side, each with specific advantages and disadvantages, they are not competing with each other.

> This is such a bizarre take that I don't know whether it's just a trolling attempt or serious...

I'm being serious.

> Why should web-devs switch to WASM unless they have a specific problem to solve where WASM is the better alternative to JS?

They mostly shouldn't. There are very few problems where wasm is better.

If you want to understand why wasm is not better, see my other posts in this thread.

Re: Making WebAssembly a first-class language on the Web

#27

Post by pizlonator »

swiftcoder wrote: post #22
pizlonator wrote: post #12

Earlier quoted context omitted.

> WebAssembly has a sandbox and was designed for untrusted code. So does JavaScript. > It's almost impossible to statically reason about JS code, and so browsers need a ton of error prone dynamic security infrastructure to protect themselves from guest JS code. They have that infrastructure because JS has access to the browser's API. If you tried to redesign all of the web APIs in a way that exposes them to WebAssemb…

> Then what's your excuse for why wasm, despite years of investment, is a dud on the web? It's not really a dud on the web. It sees a ton of use in bringing heavier experiences to the browser (i.e Figma, the Unity player, and so on). Where it is currently fairly painful is in writing traditional websites, given all the glue code required to interact with the DOM - exactly what these folks are trying to solve.

Figma is one site. There are also a handful of other sites that use wasm. But most of the web does not use wasm.

> Where it is currently fairly painful is in writing traditional websites, given all the glue code required to interact with the DOM - exactly what these folks are trying to solve.

I don't think they will succeed at solving the pain, for the reasons I have enumerated in this thread.

Re: Making WebAssembly a first-class language on the Web

#28

Post by csmantle »

Another important aspect is that, without an external library like `wabt`, I can't just open Notepad, write some inline WASM/WAT in HTML and preview it in a browser, in the same way that HTML+CSS+JS works. Having to obtain a full working toolchain is not very friendly for quick prototyping and demonstrative needs.

Re: Making WebAssembly a first-class language on the Web

#29

Post by flohofwoe »

skybrian wrote: post #23
flohofwoe wrote: post #13

Earlier quoted context omitted.

I created and maintain a couple of WASM projects and have not experienced the problems you describe: - https://floooh.github.io/tiny8bit/ - https://floooh.github.io/sokol-webgpu/ - https://floooh.github.io/visualz80remix/ - https://floooh.github.io/doom-sokol/ All those projects also compile into native Windows/Linux/macOS/Android/iOS executables without any code changes, but compiling to WASM and running in web brow…

What toolchain do you use to build your apps?

Vanilla Emscripten. Most of the higher level platform abstraction (e.g. window system glue, 3D APIs or audio APIs) happens via the sokol headers though:

https://github.com/floooh/sokol

Re: Making WebAssembly a first-class language on the Web

#30

Post by swiftcoder »

pizlonator wrote: post #27
swiftcoder wrote: post #22

Earlier quoted context omitted.

> Then what's your excuse for why wasm, despite years of investment, is a dud on the web? It's not really a dud on the web. It sees a ton of use in bringing heavier experiences to the browser (i.e Figma, the Unity player, and so on). Where it is currently fairly painful is in writing traditional websites, given all the glue code required to interact with the DOM - exactly what these folks are trying to solve.

Figma is one site. There are also a handful of other sites that use wasm. But most of the web does not use wasm. > Where it is currently fairly painful is in writing traditional websites, given all the glue code required to interact with the DOM - exactly what these folks are trying to solve. I don't think they will succeed at solving the pain, for the reasons I have enumerated in this thread.

I mean, you are obviously entitely to your opinion, but folks have been solving this stuff the hard, glue-based way for ages now, and are using WASM wherever there is an advantage to do so. Getting rid of the glue layer and the associated performance problems can only accelerate those efforts
Post reply on HN