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

251–260 of 520 posts

Re: WASM 3.0 Completed

#251

Post by marcosdumay »

cjs_ac wrote: post #115
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 ;)

If you want to compare the situation to x86, direct DOM access for WebAssembly is more akin to the BIOS than C++ stdlib access. If it can't interact with the outside world, it's just a very special toy that you can only use to play a game that isn't any fun, and a good candidate for those 'What's the next COBOL?' discussions that come up every now and then.

It's basically that joke about Haskell, that nobody uses it because it can't have any effect... but for WASM the developers are insisting on making sure it's real.

Re: WASM 3.0 Completed

#252

Post by em-bee »

bonestamp2 wrote: post #207
cedws wrote: post #192

Earlier quoted context omitted.

But then you need two things instead of one. It should be made possible to build WASM-only SPAs. The north star of browser developers should be to deprecate JS runtimes the same way they did Flash.

I agree with the first part, but getting rid of JS entirely means that if you want to augment some HTML with one line of javascript you have to build a WASM binary to do it? I see good use cases for building entirely in html/JS and also building entirely in WASM.

getting rid of javascript entirely means to be able to manipulate the DOM without writing any javascript code. not to remove javascript from the browser. javascript will still be there if you want to use it.

Re: WASM 3.0 Completed

#253

Post by jadenPete »

Support for garbage collection is really nice to see. Previously, it’s been very difficult to do garbage collection in WASM because you don’t have direct access to the stack, so traditional approaches like stack scanning haven’t been feasible.

Re: WASM 3.0 Completed

#254

Post by marcosdumay »

flohofwoe wrote: post #139
cjs_ac wrote: post #120

Earlier quoted context omitted.

It's still there - you can still do I/O in C, even if you have to call a library function. In WebAssembly, there's no mechanism for I/O of any sort.

...in WASM you also call a function to do IO though? That function is just provided by the host environment via the function import table, but conceptually it's the exact same thing as a Linux syscall, a BIOS int-call or calling into a Windows system DLL.

As long as that function doesn't receive any parameter that is like any data actually on the DOM.

So you either create a very concrete JS library that translates specific WASM data into IO actions, or one that serializes and deserialize everything all around but can be standardized.

At this point, none of those options are much more capable than Java applets... Or, in fact, if you put a network call between the WASM and the JS, you won't even add much complexity.

Re: WASM 3.0 Completed

#255

Post by [deleted] »

magicalhippo wrote: post #191
baq wrote: post #125

Earlier quoted context omitted.

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

It was glorious I tell you. Especially how you could increase the segment value by one or the offset by 16 and you would address the same memory location. Think of the possibilities! And if you wanted more than 1MB you could just switch memory banks[1] to get access to a different part of memory. Later there was a newfangled alternative[2] where you called some interrupt to swap things around but it wasn't as cool. T…

[deleted]

Re: WASM 3.0 Completed

#256

Post by fidotron »

tracker1 wrote: post #250
fidotron wrote: post #205

Earlier quoted context omitted.

This is the truth, and it's not really much better in non-GCed languages either. (In reality my impression is the GCed wasm side runtimes are even worse). Some of the least fun JavaScript I have ever written involved manually cleaning up pointers that in C++ would be caught by destructors triggering when the variable falls out of scope. It was enough that my recollections of JNI were more tolerable. (Including for go…

Was this dealing with DOM nodes and older IE versions by chance? That was probably the single biggest reason to wrap all DOM manipulation with JQuery in that it did a decent job of tracking and cleanup for you. IIRC, a lot of the issues came from the DOM and JS being in separate COM areas and the bridge not really tracking connections for both sides.

I need to pass all the user input events to a game engine, and get back the results into the webgl JS runtime side renderer. (The games at https://www.luduxia.com/ )

Re: WASM 3.0 Completed

#257

Post by [deleted] »

nagisa wrote: post #243
zarzavat wrote: post #234

Earlier quoted context omitted.

I still don't understand why it's slower to mask to 33 or 34 bit rather than 32. It's all running on 64-bit in the end isn't it? What's so special about 32?

That's because with 32-bit addresses the runtime did not need to do any masking at all. It could allocate a 4GiB area of virtual memory, set up page permissions as appropriate and all memory accesses would be hardware checked without any additional work. Well that, and a special SIGSEGV/SIGBUS handler to generate a trap to the embedder. With 64-bit addresses, and the requirements for how invalid memory accesses shoul…

[deleted]

Re: WASM 3.0 Completed

#258

Post by atroche »

phkahler wrote: post #119

Still looking forward to when they support OpenMP. We have an experimental Solvespace web build which could benefit quite a bit from that. https://cad.apps.dgramop.xyz/ Open source CAD in the browser.

This is one of the best WASM-based web UIs I've seen! What was the hardest part of getting your desktop build working via Emscripten?

Re: WASM 3.0 Completed

#259

Post by prewett »

jjcm wrote: post #12

I'm definitely excited to see 64 bit as a default part of the spec. A lot of web apps have been heavily restricted by this, in particular any online video editors. We see a bunch of restrictions due to the 32 bit cap today here at Figma. One thing I'm curious though is whether mobile devices will keep their addressable per-tab memory cap the same. It's often OS defined rather than tied to the 32 bit space.

I guess I’m just a crusty ol’ greybeard C++ developer, but it seems like a video editor is out of place in a document browser. There’s a perfectly good native operating system that nobody uses any more.

If we think we need a more thoroughly virtualized machine than traditional operating system processes give us (which I think is obvious), then we should be honest and build a virtualization abstraction that is actually what we want, rather than converting a document reader into a video editor…

Re: WASM 3.0 Completed

#260

Post by tormeh »

jesse__ wrote: post #238
cedws wrote: post #180

When is WASM finally going to be able to touch the DOM? It feels like that was the whole point of WASM and instead its become a monster of its own that barely has anything to do with web anymore. When can we finally kill JavaScript?

Hot take alert > When is WASM finally going to be able to touch the DOM? Coming from a web background, and having transitioned to games / realtime 3D applications... Fuck the DOM dude. The idea that programming your UI via not one but TWO DSLs, and a scripting language, is utter madness. In principal, it might sound good (something something separation of concerns, or whatever-the-fuck), but in reality you always end…

Preach. HTML and CSS are markup languages for creating documents. Using them for GUI applications is wild and obviously a bad idea.
Post reply on HN