Making WebAssembly a first-class language on the Web
111–120 of 287 posts
Re: Making WebAssembly a first-class language on the Web
#112Earlier 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…
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
#113Re: Making WebAssembly a first-class language on the Web
#114Do programmers actually write in wasm or automatic tools port/compile other languages to wasm?
Re: Making WebAssembly a first-class language on the Web
#115This 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…
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
#116Earlier 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.
Re: Making WebAssembly a first-class language on the Web
#117I'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.
Re: Making WebAssembly a first-class language on the Web
#118It'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,…
Re: Making WebAssembly a first-class language on the Web
#119This (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.
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
#120It'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…
especially now with coding agents, the DX they think they are bringing to the table is completely irrelevant.