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

141–150 of 287 posts

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

#141

Post by azakai »

eqrion wrote: post #21
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 int…

> DOM performance is a big deal and bottleneck for a lot of applications

What are examples of such applications? Honest question - I'm curious to learn more about issues such applications have in production.

> But we really shouldn't be requiring everyone to become an expert to benefit from wasm.

If the toolchain does it for them, they don't need to be experts, no more than people need to be DWARF experts to debug native applications.

I agree tools could be a lot better here! But as I think you know, my position is that we can move faster and get better results on the tools side.

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

#142

Post by echoangle »

leptons wrote: post #136
strongpigeon wrote: post #93

Earlier quoted context omitted.

That’s not entirely true. Security issues in the JIT of V8 are found every now and then. See https://v8.dev/blog/sandbox

Javascript isn't more insecure than any other language. Any language can have the same or other security issues.

Yeah, but you're not normally going to random websites, downloading an exe and running it. But every website you visit can run JS on your computer (as long as you don't disable JS). So maybe JS should be more secure than any other language.

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

#143

Post by devnotes77 »

eqrion wrote: post #21
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 int…

[flagged]

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

#144

Post by nneonneo »

koenschipper wrote: post #77

This article perfectly captures the frustration of the "WebAssembly wall." Writing and maintaining the JS glue code—or relying on opaque generation tools—feels like a massive step backward when you just want to ship a performant module. The 45% overhead reduction in the Dodrio experiment by skipping the JS glue is massive. But I'm curious about the memory management implications of the WebAssembly Component Model whe…

Your comment - and your last two comments too - all sound very LLM-written. Using an LLM for commenting is explicitly against the site rules (https://news.ycombinator.com/newsguidelines.html#generated).

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

#147

Post by 0x457 »

lich_king wrote: post #88
Retr0id wrote: post #68

Earlier quoted context omitted.

On one hand, yes, new attack surface is new attack surface. But WASM has been in browsers for almost a decade now.

Without the bindings this talks about, so it really couldn't do nearly as much.

WASM has access to everything JS has via JS in the same sandbox that JS runs in.

JS didn't magically become more "secure". Multiple things happened:

- ActiveX and Flash got booted from browsers

- Browsers got much better sandboxes

Essentially limited what untrusted code can run and sandboxed that untrusted code. Before NaCl and PNaCl it was wild west in browsers.

The same sandbox runs WASM. It even goes through the same runtime in every browser. It's no different from compiling language of your choice to subset of JavaScript (see asm.js).

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

#148

Post by jitl »

rishflab wrote: post #139
lich_king wrote: post #51

The web is fascinating: we started with a seemingly insane proposition that we could let anyone run complex programs on your machine without causing profound security issues. And it turned out that this was insane: we endured 20 years of serious browser security bugs caused chiefly by JavaScript. I'm not saying it wasn't worth it, but it was also crazy. And now that we're getting close to have the right design princi…

> The web is fascinating: we started with a seemingly insane proposition that we could let anyone run complex programs on your machine without causing profound security issues. Isnt this what an OS is supposed to do? Mobile operating systems have done a pretty good job of this compared to the desktop OS.

mobile operating systems review all the code that gets installed on every device

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

#149

Post by jitl »

azakai wrote: post #141
eqrion wrote: post #21

Earlier quoted context omitted.

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 int…

> DOM performance is a big deal and bottleneck for a lot of applications What are examples of such applications? Honest question - I'm curious to learn more about issues such applications have in production. > But we really shouldn't be requiring everyone to become an expert to benefit from wasm. If the toolchain does it for them, they don't need to be experts, no more than people need to be DWARF experts to debug na…

> What are examples of such applications? Honest question - I'm curious to learn more about issues such applications have in production.

any application you use today that is written in JavaScript rendering to the DOM, is much harder to write in not-JavaScript

Slack, Teams, Outlook, Word, OpenAI, Anthropic, Github, Twitter, Instagram (web), Notion, Google Docs, ...

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

#150

Post by rishflab »

jitl wrote: post #148
rishflab wrote: post #139

Earlier quoted context omitted.

> The web is fascinating: we started with a seemingly insane proposition that we could let anyone run complex programs on your machine without causing profound security issues. Isnt this what an OS is supposed to do? Mobile operating systems have done a pretty good job of this compared to the desktop OS.

mobile operating systems review all the code that gets installed on every device

Security does not depend on code review. They have stronger sandboxing and have granular permissions that the user must allow. My point is running untrusted code securely should be the operating systems job. It is possible to do this at the operating system level, a browser is not required. The problem is the security model for desktop operating systems is ancient and has not kept up with today's requirements.
Post reply on HN