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

WebAssembly adoption: Is slow and steady winning the race?

thenewstack.io

Post reply on HN
Print view View original

51–60 of 100 posts

Re: WebAssembly adoption: Is slow and steady winning the race?

#51

Post by davidalayachew »

eviks wrote: post #39
Traubenfuchs wrote: post #25

Earlier quoted context omitted.

> VMs like Python and Java require huge effort to embed. As a (backend) Java dev, I couldn't let that stand. And indeed I found out java now offers a tool called jlink with first class support, that will create a system native (e.g. .dmg on my macbook) executable with the JRE embedded. The javafx example project* I found could be downloaded, built and run from its native release all within less than 5 minutes. Mind y…

But all of Chrome doesn't take 6 seconds to start

jlink is very much out of date. jpackage is the new way to do it. I use jpackage for all of my builds.

Pointing to the 2 most recent projects I have, my Microsoft Paint clone starts up ~0.25 secs, and my Checkers clone is the same.

Re: WebAssembly adoption: Is slow and steady winning the race?

#52

Post by lxgr »

LunaSea wrote: post #16
azakai wrote: post #11

This quote from the end of the article is good: > With this in mind, maybe Wasm is mainstream. Spencer notes, for instance, that anyone who browses the web is likely to be interacting with WebAssembly on a daily basis. I think that's correct. Non-Web usecases are a more complicated story (that the article focuses on), but the Web side is largely complete and successful, and that was the original purpose of Wasm. In t…

Really? I can't think of a mainstream (as in used daily) site that uses WASM. Do you have some in mind?

Lichess and Chess.com use it for local position evaluation and playing against the computer (in analysis).

Re: WebAssembly adoption: Is slow and steady winning the race?

#53

Post by lxgr »

pjmlp wrote: post #45

I really don't see much of a value outside the browser, other than an avenue for startups to resell yet another bytecode based platform, as if we haven't had enough since UNCOL (1958). The ongoing attempts to bring back application servers, but with Kubernetes, WASM and plenty of YAML, is a kind of tragic irony. And on the browser, if one needs performance it is better served with GPU code than WebAssembly, other tha…

> if one needs performance it is better served with GPU code than WebAssembly

What? No! Would you suggest replacing e.g. the Linux kernel (parts of which are very performance critical) with GPU code too?

WebGPU is great for, well, GPU-like compute! That's not nearly all performance-critical compute. One example: Stockfish, a top chess engine, is exclusively CPU-based, and runs perfectly in WASM.

> At least we got the revenge of plugins, Flash, ActiveX and Java applets, running back on the browser thanks to WebAssembly based implementations.

Couldn't disagree more. Flash, ActiveX and Java were unpopular because they all came with their own weird/non-native-feeling GUI toolkits and UI paradigms (e.g. breaking right clicks and text selection, Ctrl+F etc.). Flash and ActiveX were also closed source and only available on some platforms. ActiveX was also very badly sandboxed on top of all of that.

WASM is none of that. The only thing you'd notice e.g. about a site bringing its own media codec, game engine etc. in WASM instead of JavaScript is better performance.

Re: WebAssembly adoption: Is slow and steady winning the race?

#54

Post by lxgr »

Traubenfuchs wrote: post #25
01HNNWZ0MV43FF wrote: post #9

Earlier quoted context omitted.

I have high hopes for wasm on the desktop for app plugins. Loading a whole binary DLL/SO is such a risk. VMs like Lua don't give you enough performance. VMs like Python and Java require huge effort to embed. Once the SIMD stuff is in, it may even have enough performance for music plugins. wasm codecs would be real cool too. Nobody likes having to build and install ffmpeg. `ffmpeg-4.0.wasm`... just imagine.

> VMs like Python and Java require huge effort to embed. As a (backend) Java dev, I couldn't let that stand. And indeed I found out java now offers a tool called jlink with first class support, that will create a system native (e.g. .dmg on my macbook) executable with the JRE embedded. The javafx example project* I found could be downloaded, built and run from its native release all within less than 5 minutes. Mind y…

Let's please not justify bad/bloaty plugin/extension runtimes with "at least it's not as bad as Electron".

A framework producing a Hello World application, even if it has a GUI, with a double- or triple-digit size in MB and memory consumption on the same order, is doing something very wrong.

Re: WebAssembly adoption: Is slow and steady winning the race?

#55

Post by lxgr »

chompychop wrote: post #29
leptons wrote: post #21

Earlier quoted context omitted.

Running FFMPEG in the browser through WASM is a game changer for me.

But isn't it really slow (like 20x or so) than native FFMPEG?

I'd be very surprised. I haven't tried ffmpeg in WASM myself, but I do know that for Stockfish, a popular and very CPU-hungry chess engine, the difference is within 20-30% or so vs. an optimized native build.

Re: WebAssembly adoption: Is slow and steady winning the race?

#56

Post by lxgr »

6510 wrote: post #36

The assumption is that javascript is bad and that the solution is to not fix it. asm.js was another example.

asm.js was the opposite of an alternative to JavaScript: It was a performant JavaScript dialect used as a compilation target for various languages otherwise targeting emscripten.

WASM is the spiritual successor to that, getting rid of the (in retrospect quite hilarious) "embedded backwards compatibility layer".

Re: WebAssembly adoption: Is slow and steady winning the race?

#57

Post by azakai »

kamikazeturtles wrote: post #50
callahad wrote: post #20

Earlier quoted context omitted.

Figma has been powered by WebAssembly for the past 7 years.

What parts of Figma though? Is it just used for cpu intensive operations like triangulation of svgs to render in webgl or is the site's core logic all done is wasm? I'm sorry, I don't use Figma but I'm really curious about its tech stack

They have a bunch of nice blogposts about that:

https://www.figma.com/blog/webassembly-cut-figmas-load-time-...

The main part of the app is in wasm, I believe (it's in C++ that they compile).

Re: WebAssembly adoption: Is slow and steady winning the race?

#58

Post by bsder »

azakai wrote: post #11

This quote from the end of the article is good: > With this in mind, maybe Wasm is mainstream. Spencer notes, for instance, that anyone who browses the web is likely to be interacting with WebAssembly on a daily basis. I think that's correct. Non-Web usecases are a more complicated story (that the article focuses on), but the Web side is largely complete and successful, and that was the original purpose of Wasm. In t…

> the Web side is largely complete and successful

Can WASM access the DOM? Or do you still have to go through a glacially slow Javascript export shim?

Re: WebAssembly adoption: Is slow and steady winning the race?

#59

Post by pjmlp »

lxgr wrote: post #53
pjmlp wrote: post #45

I really don't see much of a value outside the browser, other than an avenue for startups to resell yet another bytecode based platform, as if we haven't had enough since UNCOL (1958). The ongoing attempts to bring back application servers, but with Kubernetes, WASM and plenty of YAML, is a kind of tragic irony. And on the browser, if one needs performance it is better served with GPU code than WebAssembly, other tha…

> if one needs performance it is better served with GPU code than WebAssembly What? No! Would you suggest replacing e.g. the Linux kernel (parts of which are very performance critical) with GPU code too? WebGPU is great for, well, GPU-like compute! That's not nearly all performance-critical compute. One example: Stockfish, a top chess engine, is exclusively CPU-based, and runs perfectly in WASM. > At least we got the…

Linux kernel isn't supposed to run in the browser.

Indeed WASM is nothing like yet bytecode being capitalised by startups, in search of the next Java goldmine, by folks that enjoy bashing about it. /s

App servers bad, Kubernetes with WASM, "oh boy that is soooo cool!".

Re: WebAssembly adoption: Is slow and steady winning the race?

#60

Post by DarkNova6 »

pjmlp wrote: post #41
DarkNova6 wrote: post #15

Earlier quoted context omitted.

But Blazor seems to do a fine job replacing JS with C#? If you really want go to all-native JS because it has advantages, sure you can do. But what I see are bloated SPAs written in a language not designed for large software, based on an environment that likes to change and break things. It's abstractions upon abstractions get a hold of this mess. I don't see why WASM couldn't compete.

Blazor is doing a fine job being a home for WebForms and Silverlight refugees, how far it will stay relevant remains to be seen. On my job I have zero reasons to suggest it, given the split between FE and BE teams.

Organisations always move slower than technologies. And if Microservies show anything it is that sometimes you just need a technical solution for a human problem.

I understand your lack of desire to touch anything remotely resembling frontend. Yet your hostility towards Blazor perplexes me, as for me it is the hot garbage that is JS is a primary reason.

Post reply on HN