Live data from Hacker News

Making WebAssembly a first-class language on the Web

hacks.mozilla.org

111–120 of 287 posts

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

#112

Earlier quoted context omitted.

Novelty - JS has had more time and effort spent in hardening it, across the browsers, WASM isn't as thoroughly battle-tested, so there will be novel attacks and exploits.

> Novelty - JS has had more time and effort spent in hardening it Taking this argument to its extreme, does this mean that introducing new technology always decreases technology? Because even if the technology would be more secure, just the fact that it's new makes it less secure in your mind, so then the only favorable move is to never adopt anything new? Supposedly you have to be aware of some inherent weakness in…

> Taking this argument to its extreme, does this mean that introducing new technology always decreases technology?

I assume you mean "decreases security" by context. And in that case - purely from a security standpoint - generally speaking the answer is yes. This is why security can often be a PITA when you're trying to adopt new things and innovate, meanwhile by default security wants things that have been demonstrated to work well. It's a known catch-22.

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

#115

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…

I’m wondering if the recent improvements in sending objects through sendMessage in v8 and Bun change the math here enough to be good enough.

SendMessage itself is frustratingly dumb. You have excessively bit fiddly or obnoxiously slow as your options. I think for data you absolutely know you’re sending over a port there should be an arena allocator so you can do single copy sends, versus whatever we have now (3 copy? Four?). It’s enough to frustrate use of worker threads for offloading things from the event loop. It’s an IPC wall, not a WASM wall.

Instead of sending bytes you should transfer a page of memory, or several.

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

#116

Earlier quoted context omitted.

That's an orthogonal problem. First it needs to be possible and straightforward to write GCed languages in the sandbox. Second, GCed languages need to be willing to fit with the web/WASM GC model, which may not exactly match their own GC and which won't use their own GC. And after that, languages with runtimes could start trying to figure out how they might reduce the overhead of having a runtime.

> Second, GCed languages need to be willing to fit with the web/WASM GC model I think most languages could pretty easily use WASM GC. The main issue comes around FFI. That's where things get nasty.

WasmGC doesn't support interior pointers, and is quite primitive in available set of operations, this is quite relevant if you care about performance, as it would be a regression in many languages, hence why it has largely been ignored, other than the runtimes that were part of the announcement.

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

#117

I'd really like to be able to run _any_ language in the browser. WASM is a great first step.

Internet Explorer used to support any language that Windows Script Host could run. By default, that was JScript and VBScript, but there were third-party engines for Python, Perl, Ruby, Lua, and many others. Possibly disabled now as they announced VBScript would be disabled in 2019.

Yes, we used the plugins from ActiveState on Tcl.

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

#118

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…

With Google now pushing developer certification, Android and iOS practically being mandatory for certain basic functions like accessing your bank or certain government services, Webassembly would make web apps first class citizens that aren't subject to mobile operating system lockdown. Being able to complete on efficiency with native apps is an incredible example of purposeful vision driving a significant standard,…

Except that the Web is basically ChromeOS Platform nowadays, thanks to all those folks targeting only Chrome, complaining about Safari, and shipping Elecron crap.

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

#119

This (appears as though it) all could have happened half a decade ago had the interface-types people not abandoned[1,2] their initial problem statement of WebIDL support in WebAssembly in favour of building Yet Another IDL while declaring[3] the lack of DOM access a non-issue. (I understand the market realities that led to this, I think. This wasn’t a whim or pure NIH. Yet I still cannot help but lament the lost time…

I really want stringref to make a comeback.

My god yes.

I'm building a new Wasm GC-based language and I'm trying to make as small as binaries as possible to target use cases like a module-per-UI-component, and strings are the biggest hinderance to that. Both for the code size and the slow JS interop.

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

#120

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…

agreed. no one needs the component model, and it's just a attempt for people to create work for themselves.

especially now with coding agents, the DX they think they are bringing to the table is completely irrelevant.

Post reply on HN