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

Pay attention to WebAssembly

harshal.sheth.io

Post reply on HN
Print view View original

151–160 of 251 posts

Re: Pay attention to WebAssembly

#151

Post by brabel »

cogman10 wrote: post #49
dom96 wrote: post #37

Earlier quoted context omitted.

It seems strange for WASM to get a GC. Shouldn't it just expose a malloc and free call?

The thought is less about WASM having a GC and more about WASM being able to leverage the runtime's GC. The assumption is that WASM will run in something like a v8 where the it already has a GC for Javascript. So, rather than distributing a WASM executable with all the code needed to implement a GC, you'd have it rely on the inbuilt GC. As it stands, WASM is really only a good target for C/C++/Rust. Any other languag…

> And yes, WASM exposes malloc and free.

No it doesn't. Unless you're referring to WASI, but WASI is not WASM, it's just a common API which modules can call when running on WASI-compliant WASM runtimes.

All WASM itself has is linear memory, and that is not exposed via malloc/free, but via lower level instructions to set bytes on a page and grow when necessary (but not "free"). See the available instructions in the spec[1].

[1] https://www.w3.org/TR/wasm-core-1/#memory-instructions%E2%91...

Re: Pay attention to WebAssembly

#152

Post by kaba0 »

pie_flavor wrote: post #113
SquibblesRedux wrote: post #83

Reading the article, I felt like I was back in 1996 reading about the Java bytecode compiler and the JVM plugin for the browser. Java had such great promise for web page-hosted code, that would be portable, performant, and safe. Why would one think WebAssembly will succeed where Java failed? (Well, Java did not exactly fail, but its purpose and typical usage radically changed over the years.)

Java failed because - it depended on an installation outside the browser, poorly versioned - and a plugin too, which was extra noise for the user, and not nearly so pain-free as Flash's was - it was not , under any circumstances, performant (this was before HotSpot) - AWT was truly, thoroughly, god awful (this was before Swing) Finally, it was caught between two realms. Clunkier than JS and more difficult to work wit…

I always feel these comparisons do not make much sense - it’s like comparing some pre-industrial thing with its today’s equivalent: browsers were simply absolutely not what they are now.

Like, 2 of your points were simply politics, where js just happened to get chosen, while performance got rapidly faster in the coming years. If anything, Java was well ahead of its time and the surrounding environment was not yet ready.

Re: Pay attention to WebAssembly

#153

Post by kaba0 »

charcircuit wrote: post #121
pie_flavor wrote: post #113

Earlier quoted context omitted.

Java failed because - it depended on an installation outside the browser, poorly versioned - and a plugin too, which was extra noise for the user, and not nearly so pain-free as Flash's was - it was not , under any circumstances, performant (this was before HotSpot) - AWT was truly, thoroughly, god awful (this was before Swing) Finally, it was caught between two realms. Clunkier than JS and more difficult to work wit…

>- it was not, under any circumstances, performant It was performant enough for one of the most popular games of all time, Minecraft, which was originally a game in a Java applet.

As mentioned, that happened much later, so it is irrelevant.

But for the others, java is insanely fast today, with pretty much the state of the art GC it has. In practice, a really significant chunk of all important server backends run on the JVM.

Re: Pay attention to WebAssembly

#154

Post by kaba0 »

the_duke wrote: post #133
SquibblesRedux wrote: post #83

Reading the article, I felt like I was back in 1996 reading about the Java bytecode compiler and the JVM plugin for the browser. Java had such great promise for web page-hosted code, that would be portable, performant, and safe. Why would one think WebAssembly will succeed where Java failed? (Well, Java did not exactly fail, but its purpose and typical usage radically changed over the years.)

There are fundamental differences here. Webassembly is a small stack machine based on an open standard. It is built bottom up, with a very small core. Additional features like SIMD, garbage collection,posix style system interfaces (WASI), linking, garbage collection,... are built as optional extensions based on real world feedback. There already are a multitude of different implementations. (the three browsers, the W…

With all due respect, do you know anything about Java?

What do you think it is? https://docs.oracle.com/javase/specs/jvms/se7/html/

And no, Java is absolutely not a huge runtime - it is a simple stack-based vm with garbage collection made originally for goddamn TV set-top boxes, so it has an absolutely small instruction set. It just happens to be so good for multitudes of reasons that the biggest implementation (yes, it has absolutely insane amount of ones, tour claim of wasm having multiple implementations is just ridiculous compared to the amount of jvms), OpenJDK basically runs the backend of a great deal of all significant web applications.

Re: Pay attention to WebAssembly

#156

Post by nahumfarchi »

evmar wrote: post #62

> Figma makes use of a low-level C++ library called Skia for 2D graphics rather than building their own graphics engine This is not quite right. The bulk of Figma rendering is Figma-custom GPU code. It's true that Figma uses Skia, but only for some specific graphics algorithms in Skia, not as a general purpose rendering library. Source: I work on this code.

One thing that I was curious about, if I may ask, is how does Figma goes about font rendering?

Re: Pay attention to WebAssembly

#157

Post by pjmlp »

astlouis44 wrote: post #77
hsheth2 wrote: post #75

Earlier quoted context omitted.

Thanks for the correction - I'll update my post shortly.

Thoughts on gaming’s role to play with WebAssembly..? My team and I are current working on Unreal Engine WASM support, with WebGPU integration on the way. Personally, I believe native games on the web is going to disrupt Steam and the app stores and enable a whole new distribution channel for developers, especially indies. No 30% cut, works on any device with a browser.

If you are happy to play Playstation 2 like games on the browser yes, because that is as much 3D hardware capabilities they are aware of.

Re: Pay attention to WebAssembly

#158

Post by fulafel »

hankman86 wrote: post #18

There are many things to love about WebAssembly, but let’s not forget it’s downsides. Like it’s threading model relies on Web workers and SharedArrayBuffers and is a royal pain in the … to work with. Not to mention that you’ll need to become COOP/COEP compliant to mitigate side-channel attacks. Then there is the plain fact that it requires a compilation step, which is OK for large apps. But it makes me wonder if wasm…

The only significant perf advantage WebAssembly has in browser vs JS is currently access to (Pentium II era) SIMD. This is a regrettable choice, because most languages targeting the browsers are now lacking access to SIMD.

Heavier computation is currently being done with WebGL shaders (eg Google Meet background swap, TensorFlow tfjs).

Re: Pay attention to WebAssembly

#159

Post by H8crilA »

kaba0 wrote: post #154
the_duke wrote: post #133

Earlier quoted context omitted.

There are fundamental differences here. Webassembly is a small stack machine based on an open standard. It is built bottom up, with a very small core. Additional features like SIMD, garbage collection,posix style system interfaces (WASI), linking, garbage collection,... are built as optional extensions based on real world feedback. There already are a multitude of different implementations. (the three browsers, the W…

With all due respect, do you know anything about Java? What do you think it is? https://docs.oracle.com/javase/specs/jvms/se7/html/ And no, Java is absolutely not a huge runtime - it is a simple stack-based vm with garbage collection made originally for goddamn TV set-top boxes, so it has an absolutely small instruction set. It just happens to be so good for multitudes of reasons that the biggest implementation (yes,…

Fun exercise: write a simple compiler with a JVM output. The JVM stack language is so easy, and it's the best way to explore it / something like it!

(Otherwise you're spot on and the GP clearly has no idea about Java)

Re: Pay attention to WebAssembly

#160

Post by pjmlp »

greggman3 wrote: post #97
astlouis44 wrote: post #77

Earlier quoted context omitted.

Thoughts on gaming’s role to play with WebAssembly..? My team and I are current working on Unreal Engine WASM support, with WebGPU integration on the way. Personally, I believe native games on the web is going to disrupt Steam and the app stores and enable a whole new distribution channel for developers, especially indies. No 30% cut, works on any device with a browser.

I think it depends Problems with *traditional* games via WASM/WebGPU in the browser * Many games are 10-100gig+ in size. The browser provides no good way to store this data for your game and the fact that you had to wait 15mins to multiple hours means you gain no advantage. Further, browser have a balance to keep between letting any site put gigs of data on your machine vs not. And on top of that, the browser provide…

Additionally, WebGL 2.0 is stuck on a GL ES 3.0 subset, and when WebGPU 1.0 comes out later this year, it will be a subset of Vulkan 1.0, DX 12 1.0, Metal 1.0 until it ever gets adoption across all browsers, before they even think about moving forward.

It took about 10 years between 1.0 and 2.0 for WebGL broader adoption.

And in any case they are hardly available on game consoles.

Post reply on HN