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

WASM 3.0 Completed

webassembly.org

Post reply on HN
Print view View original

151–160 of 520 posts

Re: WASM 3.0 Completed

#151

Post by naythaniel »

ricardobeat wrote: post #113
cosmic_cheese wrote: post #101

Earlier quoted context omitted.

Isn’t the whole reason why people want DOM access is so that the JavaScript side doesn’t have any meat to it and they can write their entire web app in Rust/Go/Swift/etc compiled to webasm without performance concerns?

Spoiler: there will be performance concerns. The bottleneck is in the DOM operations themselves, not javascript. This is the reason virtual-dom approaches exist: it is faster to operate on an intermediate representation in JS than the DOM itself, where even reading an attribute might be costly.

This isn't true. DOM access is fast. DOM manipulation is also fast. The issue is many DOM manipulations happening all at once constantly that trigger redraws. Redrawing the DOM can also be fast if the particular DOM being redrawn is relatively small. React was created because Facebook's DOM was enormous. And they wanted to constantly redraw the screen on every single interaction. So manipulating multiple elements simultaneously caused their rendering to be slow. So they basically found a way to package them all into a single redraw, making it seem faster.

Re: WASM 3.0 Completed

#152

Post by kg »

whizzter wrote: post #117
jasonthorsness wrote: post #54

I don't think the GC in this version has the features required to enable a C# runtime on top of it yet: https://github.com/WebAssembly/gc/issues/77 I wonder what language this GC can actually be used for at this stage?

I'm not familiar with all the implementation details of objects in C#, but the list of issues mixes runtime implementation details (object layouts) that should be fairly low effort to work around with actual language/runtime features (references, finalization). In general though most regular C# code written today _doesn't directly_ use many of the features mentioned apart from references. Libraries and bindings howev…

Part of the problem is you would need to fork the base class libraries and many popular nuget packages to remove any uses of ref/in/out, along with any interior references, spans, etc. The .NET type system has allowed 'interior references' (references into the inside of a GC object) for a long time and it's difficult to emulate those on top of WasmGC, especially if your goal is to do it at low cost.

It's definitely true that you could compile some subset of C# applications to WasmGC but the mismatch with the language as it's existed for a long time is painful.

Re: WASM 3.0 Completed

#153

Post by zdandoh »

bborud wrote: post #65

I'm a simple man who has simple needs. I want a better and faster way to pass Go structs in and out of the runtime that doesn't mean I have to do a sword dance on a parquet floor wearing thick knit wool socks and use some fragile grafted on solution. If there can be a solution that works for more languages: great. I mostly want this for Go. If it means there will be some _reasonable_ limitations, that's also fine.

That would be more of a library than a WASM spec thing, no? I wrote a code generator that does this well for some internal use-cases.

Re: WASM 3.0 Completed

#154

Post by naasking »

TUSF wrote: post #45
john01dav wrote: post #29

Earlier quoted context omitted.

I thought that the purpose of GC in WASM was to allow such higher level languages to be placed there without a bulky runtime also in WASM. What's the value proposition of WASM GC if not this?

As I understand it, WASM GC provides a number of low level primitives that are managed by the WASM host runtime, which would theoretically allow languages like Go or Python to slim down how much of their own language runtime needs to be packaged into the WASM module. But how those languages still need to carry around some runtime of their own, and I don't think it's obvious how much a given language will benefit.

Programming languages with type erasure would have no runtime, just raw program code and the WASM GC. Languages that have runtime types still need a runtime for that functionality.

Re: WASM 3.0 Completed

#155

Post by brabel »

jillesvangurp wrote: post #50
preommr wrote: post #22

On gc: > Wasm GC is low-level as well: a compiler targeting Wasm can declare the memory layout of its runtime data structures in terms of struct and array types, plus unboxed tagged integers, whose allocation and lifetime is then handled by Wasm. There's already a lot misunderstandings about wasm, and I fear that people will just go "It supports GC, so we can just export python/java/c#/go etc." This is not a silver b…

The Kotlin wasm compiler was basically engineered on top of wasm's GC support. Works fairly OK. As far as I understand it's essentially the same garbage collector that is also used for regular javascript. > This is not a silver bullet. Cpp, or rust are probably still going to be the way to go. I don't think that's necessarily true anymore. But as you say, it depends on the compiler you use and how well it utilizes wh…

Dart is in a more advanced state in that front.

Re: WASM 3.0 Completed

#156

Post by kg »

titzer wrote: post #136
alabhyajindal wrote: post #123

The WebAssembly community should really focus more the developer experience of using it. I recently completed a project where I wrote a compiler¹ targeting it and found the experience to be rather frustrating. Given that Wasm is designed with formal semantics in mind, why is the DX of using it as a target so bad? I used binaryen.js to emit Wasm in my compiler and didn't get a feeling that I am targeting a well design…

What were your specific pain points? One thing that can be annoying is validation errors. That's one of the reasons that Wizard has a --trace-validation flag that prints a nicely-formatted depiction of the validation algorithm as it works.

Thanks for bringing Wizard to my attention, the next time I need to validate wasm it's going to save me a ton of time.

Re: WASM 3.0 Completed

#157

Post by munificent »

baq wrote: post #125
jsheard wrote: post #104

Earlier quoted context omitted.

The comedy option would be to use the new multi-memory feature to juggle a bunch of 32bit memories instead of a 64bit one, at the cost of your sanity.

didn't we call it 'segmented memory' back in DOS days...?

We call it "pointer compression" now. :)

Re: WASM 3.0 Completed

#158

Post by Existenceblinks »

alabhyajindal wrote: post #123

The WebAssembly community should really focus more the developer experience of using it. I recently completed a project where I wrote a compiler¹ targeting it and found the experience to be rather frustrating. Given that Wasm is designed with formal semantics in mind, why is the DX of using it as a target so bad? I used binaryen.js to emit Wasm in my compiler and didn't get a feeling that I am targeting a well design…

i found assembly is easier to assemble from scratch (it's apple and orange but.). Most materials should exclude these tooling, mostly rust based tools. We should be able to write them by hands just like when assembly was taught. Compiler and assembly are separate classes. I think it's bad assumption that only compiler devs only care about wasm. It's compiling target, sure, but framing it this way will not broaden its knowledge.

Re: WASM 3.0 Completed

#159

Post by munificent »

k9294 wrote: post #127
flohofwoe wrote: post #95

Earlier quoted context omitted.

Well, arguably the worst thing about WASM is the naming. It's neither directly related to the web, nor is it an assembly syntax. It's just another virtual ISA. "Direct DOM access for WASM" makes about as much sense as "direct C++ stdlib access for the x86 instruction set" - none ;)

Oh wow, that really is terrible naming... I always thought WASM was a specification for compiling code into something that runs natively in web browsers—like a web-specific compilation target.. Today I learned.

It's an instruction set architecture that browsers happen to support executing directly.

Re: WASM 3.0 Completed

#160

Post by whizzter »

quix0t3 wrote: post #130
Jtsummers wrote: post #90

Earlier quoted context omitted.

> steve job's ghost will prevent wasm adoption. https://webassembly.org/features/ That isn't updated for Safari 26, but by that table Safari 18 is only missing 3 standardized features that Chrome supports, with a fourth that is disabled by default. So what's the point of your comment? Just to make noise and express your ignorance?

Historically speaking, apple has consistently limited web app functionality on iOS since 2008. I think we would be much further ahead if it wasn't for Apple’s policies under his leadership. Apple took over the distribution to prioritize a cut to the app store which crippled/slowed the open web PWA and WASM adoption.

Sure, and that's why Asm.JS(regular JS with special semantics) and later Wasm(bytecode translateable to JS) was so brilliant. It already worked on Safari, they had the option of either:

A: look slow compared to other engines that supported it

B: implement it

Now, stuff like the exception handling stuff and tail calls probably aren't shimmable via JS, but at this point they don't gain much from being obstructionists.

Post reply on HN