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

171–180 of 251 posts

Re: Pay attention to WebAssembly

#171

Post by pjmlp »

RantyDave wrote: post #123
hankman86 wrote: post #28

Earlier quoted context omitted.

Neither was Java at the time when browsers had support Java applets. At a closer look, Java Applets suffered from much of the same problems that plague WebAssembly. Like the inability of interact with the DOM (or other browser APIs) without calling out to JavaScript. Or the fact that you had to split up the code on your side into a JavaScript part (these days, perhaps transpiled from Typescript) and a part that was J…

Java also didn't have to face the fact that, now, Javascript runtimes are really good. There's not that much between Javascript and WASM ... and JS can access the DOM.

Just like JavaApplets could.

Re: Pay attention to WebAssembly

#172

Post by pjmlp »

skywal_l wrote: post #166
pjmlp wrote: post #155

20 years ago, > More than 20 programming tools vendors offer some 26 programming languages — including C++, Perl, Python, Java, COBOL, RPG and Haskell — on .NET. https://news.microsoft.com/2001/10/22/massive-industry-and-d...

I believe .NET was not open initially. Moreover, there are some patents involved I believe. Add to that the general distrust of Micro$oft among the open source community (especially in 2001).

Sure, that was just one example, there are plenty of others to reach for since 1960's.

Re: Pay attention to WebAssembly

#173

Post by kaba0 »

mdasen wrote: post #81
fancyfredbot wrote: post #5

WebAssembly is full of potential. But so are Java bytecode, SPIR and various others. Why will WebAssembly take off where these haven't?

I think what makes thing succeed or not can be subtle (and therefore it's easy to disagree with). Ultimately, I think WASM will succeed because it's a uniting force among communities. Rust people are behind it, Microsoft and C#/.NET are behind it, people in the Go, Python, and other communities are behind it, and the browser vendors are behind it. Java applets were things that were slow to load and didn't interface w…

I don’t think that Flash and Java “created their own little world”, but rather that they were entities not “accepted” by browsers, so they remained in a “third-party” status, but that was not their decision to make.

Re: Pay attention to WebAssembly

#175

Post by kaba0 »

dragonwriter wrote: post #67
russtrotter wrote: post #35

Earlier quoted context omitted.

To continue the Java bytecode prior comment, at one point, java was in all browsers of the time (i.e. Applets). However, it lost, and seemingly removed with extreme prejudice with no nods to backwards compatibility. Java also enjoys multiple HLLs that target its bytecode (Scala, Kotlin, Groovy, Jython, etc) and there's nothing in the runtime capabilities that tie it to any kind of constrained platform (threading, IO,…

> To continue the Java bytecode prior comment, at one point, java was in all browsers of the time No, it wasn't. > (i.e. Applets). Applets required (1) installing Java on the system, and (2) installing a plugin for Java in the browser. The capacity to run them was not built in natively to any major browser. > However, it lost, and seemingly removed with extreme prejudice with no nods to backwards compatibility. It pr…

> But not C/C++ (or, now, Rust/Go), in which a lot of common code on which native-targeted code in other languages rely is written.

It does actually. Graal can run LLVM bytecode. Also, if you mean some specific C library used by everything, the Java ecosystem is absolutely huge and has the benefit of being almost completely written in Java with very little native code.

Re: Pay attention to WebAssembly

#176

Post by ashvardanian »

duskwuff wrote: post #90
ashvardanian wrote: post #65

I am surprised there is no isolation schema for binaries. WASM may look lite and fast compared to Docker, but its still painfully slow compared to AVX or Neon enabled assembly. We went from VMs to Containers. From Containers to WASM. Now, I guess, we just need to learn how to properly isolate simple binaries.

> [WASM is] still painfully slow compared to AVX or Neon enabled assembly. There's an open proposal to add SIMD intrinsics to WASM. https://github.com/WebAssembly/proposals/issues/1

Yeah, saw it, but never tried. Java, C# and other high level languages have libraries for basic SIMD operations. It's completely different world from manually invoking intrinsics in C or writing raw assembly. I am wondering where WASM will land.

Visually it's definitely not Assembly. It actually looks more like Python than C. I guess my subjective assumptions are based entirely on looks. Will have to try it for smth, will definitely share afterwards :)

Re: Pay attention to WebAssembly

#177

Post by usrbinbash »

WebAssembly will not displace Server Side languages.

"oh but it compiles once and then runs everywhere!!!!"...ceased to be an argument over 15y ago, when it became clear that the "backend" is synonymous with linux, and almost every machine has the same architecture. Plus, the time required by the compilation step is not prohibitive in a CI/CD pipeline.

Re: Pay attention to WebAssembly

#178

Post by hansworst »

nahumfarchi wrote: post #156
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?

Not sure if they use the same, but here's an article about text rendering from the CTO of Figma: https://medium.com/@evanwallace/easy-scalable-text-rendering...

Re: Pay attention to WebAssembly

#179

Post by skywal_l »

pjmlp wrote: post #172
skywal_l wrote: post #166

Earlier quoted context omitted.

I believe .NET was not open initially. Moreover, there are some patents involved I believe. Add to that the general distrust of Micro$oft among the open source community (especially in 2001).

Sure, that was just one example, there are plenty of others to reach for since 1960's.

Chip8 for example.

/s

Re: Pay attention to WebAssembly

#180

Post by fxtentacle »

brrrrrm wrote: post #55
fxtentacle wrote: post #44

Earlier quoted context omitted.

TIL that Wasm doesn't have GC. But I did observe periodic CPU spikes and app freezes with Wasm+WebGL. So now I wonder where they came from. As for TensorFlow, no I deliberately compared their CPU-only Xnnpack backend against Wasm. So both didn't use the GPU. But obviously Sse3 and avx also help a lot. Emscripten is a compiler while Wasm is an execution backend. I think it makes sense to treat them as separate because…

on an M1 I think TF.js is within 2x of native XNNPACK on a single core. Since aarch64 simd width is also 128, it works out well.

I'm willing to believe that, but who would use a single core for an embarrassingly parallel problem such as image convolution? I'd expect it to use all 8 cores, but AFAIK, Wasm really only uses one. Probably that's the biggest performance factor then.
Post reply on HN