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

81–90 of 100 posts

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

#81

Post by crabmusket »

austin-cheney wrote: post #7

Web Assembly has (at least in the past) a business problem. In the past in nearly all prior discussions on this the greatest proponents for Web Assembly were developers who wanted to bring their technologies into the browser because they hate JavaScript. That is a horrible business case that is more effort than any value returned and no user will ever care about. Worse, it won't ever work if you intended it to be a J…

> In the past in nearly all prior discussions on this the greatest proponents for Web Assembly were developers who wanted to bring their technologies into the browser because they hate JavaScript.

I couldn't speak for "nearly all prior discussions", though I don't doubt there were many devs excited that they could bring their favourite language into a browser.

But if I remember correctly, WASM developed pretty directly out of asm.js, which was about bringing high performance code to the web. Yes, it was compiled from C, but not because people hated JS, but because writing the asm.js subset was awful, and writing C was a better way to target the low level high performance virtual machine.

Sure, there were plenty of existing libraries in C which were leveraged (e.g. the demo of Unreal running in the browser), but "I can compile a Python interpreter into a webpage" did not seem to me to be the reason for WASM, just a frivolous side-effect.

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

#82

Post by erhaetherth »

dmingod666 wrote: post #79
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…

very good alternative is wails 6-10mb single binary use any frontend js tech you want automatically go functions exposed to the js side so you don't need to think about making endpoints, it makes and uses a websockets between the binary and the ui uses WebView2 and not chrome

Sounds like Tauri, which is built on Rust instead of Go.

> By using the OS's native web renderer, the size of a Tauri app can be less than 600KB.

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

#83

Post by yen223 »

DarkNova6 wrote: post #15
austin-cheney wrote: post #7

Web Assembly has (at least in the past) a business problem. In the past in nearly all prior discussions on this the greatest proponents for Web Assembly were developers who wanted to bring their technologies into the browser because they hate JavaScript. That is a horrible business case that is more effort than any value returned and no user will ever care about. Worse, it won't ever work if you intended it to be a J…

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.

Are there any good Blazor websites out there?

I'm not sure if I've ever encountered one in the wild, but to be fair I wasn't really looking.

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

#84

Post by erhaetherth »

6510 wrote: post #33
darby_eight wrote: post #26

Earlier quoted context omitted.

I mean, it's slow, it uses about ~500x more memory than my irc client does, the interface doesn't meld with the rest of the OS, the options for end-users to actually customize how the app works are direly limited... I'm probably missing gripes but thankfully I haven't had to use it for a couple of years.

It's hard to list all the differences. Say, file association is quite useful.

But you can do file association on the web https://developer.mozilla.org/en-US/docs/Web/Progressive_web...

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

#85

Post by 01HNNWZ0MV43FF »

marcosdumay wrote: post #47
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.

Well, it's possible that we can only create a serious application-aware OS security layer by forcing people to write an emulator for some random VM... But I'd expect it to be easier to go and write application-aware security on your OS.

Unfortunately I am having to support like 3 OSes.

4 if you count the Linux kernel of 2020 as distinct from the Linux kernel of 2024.

A userspace, in-process solution is very very appealing until everyone is on Linux of 2024+.

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

#86

Post by pjmlp »

emporas wrote: post #80
pjmlp wrote: post #59

Earlier quoted context omitted.

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!".

"Write once, run everywhere" is pretty important goal to achieve. When a project has to be written for a platform, and then ported to other platforms, then some ports or all of them turn out to be pretty bad. Essentially the program runs only on one platform well. The ports also may turn out to be a significant burden depending on the size of the project, which usually grows over time. Take Adobe as an example. It's…

And just like multiple times since 1958's UNCOL, WASM write once run anywhere will reveal itself as not really true, specially when going beyond bare bone computations, using multiple runtimes and competing WASI implementations, that will never make it to the browser, and are cloud vendor specific.

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

#87

Post by pjmlp »

DarkNova6 wrote: post #60
pjmlp wrote: post #41

Earlier quoted context omitted.

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.

Let's say I use Microsoft technologies since MS-DOS 3.3, and Blazor isn't the first great thing that eventually goes south.

I belong to the group of people that knows Web Forms before .NET 1.0, went through Silverlight, XNA, WinRT, UAP, UWP,...

One thing that Web Forms and Silverlight taught me, is that working directly with browser tech, regardless how bad it may be, is much better than debugging framework and VS interoperability code.

For the same reason I master C, regardless of my opinion on it, and its bad influences in security, I have a much easier time on UNIX clones, than otherwise would be.

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

#88

Post by flohofwoe »

marcosdumay wrote: post #70
robocat wrote: post #64

Earlier quoted context omitted.

I thought it was the DOM API that was glacially slow? Would WASM directly accessing the DOM be an improvement of more than say 5%

The DOM has two different APIs, a batch and a piecewise ones. The batch one is incredibly optimized in all the browsers, while the piecewise one usually do not receive any attention at all. Now, FFI the interface between WASM and JS is incredibly slow. That's by design. I guess the goal was to push every important API into WASM, and leave the FFI just for interfacing code, like on normal environments. People avoid pr…

Calling between WASM and JS really hasn't been slow in browsers since around 2018:

https://hacks.mozilla.org/2018/10/calls-between-javascript-a...

It would be extremely surprising if calling overhead into JS to manipulate the DOM is noticeable in profiling instead of being dominated by the actual DOM manipulation (I have mainly experience with WebGL and WebGPU, where each call also goes through a JS shim, with a sometimes nontrivial amount of work happening in the JS shim, and the actual call overhead from WASM into JS is absolutely negligable compared to the overall cost, which is typically inside the WebGL and WebGPU implementation).

Also: if performance matters, don't use the DOM in the first place!

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

#89

Post by flohofwoe »

triyambakam wrote: post #42
dcode wrote: post #19

Earlier quoted context omitted.

> the Web side is largely complete and successful Perhaps from a C++ perspective, say a monolith with kilobytes of bindings driving a canvas. Yet > the original purpose of Wasm includes, as per the charter, "and interoperate gracefully with JavaScript and the Web", which is far from complete and, thanks to WASI and the Component Model, hardly improving. I guess it will remain a mystery how WASI could basically replac…

Can you elaborate on why you think WASI and the Component Model is ruining that? I am only vaguely familiar with the state of WASM and squinting from this distance it seemed that WASI and the CM were meant to really improve a lot of problems. I'm not familiar with WebIDL bindings

The WASM component model looks like it wants to free us from the "C ABI" (yes I know technically there's no such a thing) and give us a "high level language agnostic ABI", but when you take a closer look it's really just a hodgepodge of base types from the Rust stdlib in a trenchcoat, so it basically replaces the "C ABI" with something that's a bit friendlier for Rust coders to work with, but that's about it (at least that's the gist, of course there's a lot more than the ABI spec, but that's also a problem of the Component Model: it lacks focus)

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

#90

Post by dartos »

lxgr wrote: post #68
dartos wrote: post #65

Earlier quoted context omitted.

When I’ve tried writing programs targeting wasm (in assemblyscript and rust) and platforms for them to run on, special care had to be taken to treat each language differently (how they encode strings differently for example.) This means that not only do I need to take special care that my code can compile to wasm, but the platform devs (also me, in this case) needs to take special care to support a variety of differe…

That's of course an option if you're fine with your deployables being architecture- and OS-dependent, and very often that's the case. But for when it's not, I think a platform-independent and language-agnostic bytecode standard is a valuable thing to have.

In the extreme scenario where you want to run arbitrary untrusted code on arbitrary machines, that would be useful, but wasm isn’t a solution for that.

If I need to specifically support how certain languages compile to wasm (meaning I don’t support arbitrary wasm) then what’s the point?

It’s just Java applets again.

Post reply on HN