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

331–340 of 520 posts

Re: WASM 3.0 Completed

#331

Post by pjmlp »

wyldfire wrote: post #265
prewett wrote: post #259

Earlier quoted context omitted.

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 actuall…

> ... document browser ... document reader ... I'm going to assume you're being sincere. But even the crustiest among us can recognize that the modern purpose for web browsers is not (merely) documents. Chances are, many folks on HN in the last month have booked tickets for a flight or bought a home or a car or watched a cat video using the "document browser". > If we think we need a more thoroughly virtualized machi…

We have, but not by choice, I miss my native apps, even though ChromeOS Platform pays the bills.

Re: WASM 3.0 Completed

#333

Post by pjmlp »

imoverclocked wrote: post #296
syndeo wrote: post #294

Earlier quoted context omitted.

> run WASM on bare metal Heh, reminds me of those boxes Sun used to make that only ran Java. (I don’t know how far down Java actually went; perhaps it was Solaris for the lower layers now that I think about it…)

With hypervisors and a Linux kernel doing the heavy lifting, the WASM on bare metal probably just looks a lot like a regular process. I would bet Sun did similar … minus the hypervisor. I do miss the Solaris 10/OpenSolaris tech though. I don’t know anything that comes close to it today.

Solaris is still around, while OpenSolaris forks support Oxide endeavours.

Re: WASM 3.0 Completed

#335

Post by flohofwoe »

marcosdumay wrote: post #254
flohofwoe wrote: post #139

Earlier quoted context omitted.

...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…

> At this point, none of those options are much more capable than Java applets

Java applets allowed to load and call into native DLLs via JNI, so they were definitely much more capable than WASM, but also irresponsibly unsafe.

In your own WASM host implementation you could even implement a dlopen() and dlsym() to load and call into native DLLs, but any WASM host which cares about safety wouldn't allow that (especially web browsers).

Re: WASM 3.0 Completed

#336

Post by lukan »

nasso_dev wrote: post #221
colordrops wrote: post #202

Earlier quoted context omitted.

Isn't going through the JS APIs slow?

used to be, in the early days, but nowadays runtimes optimized the function call overhead between WASM and JS to near zero https://hacks.mozilla.org/2018/10/calls-between-javascript-a...

It did improved a lot, but unfortunately not near zero enough.

It is managable if you avoid js wasm round trips, but if you assume the cost is near zero you will be in for a unpleasant surprise.

When I have to do a lot of different calls into my wasm blob, I am way way faster batching them. Meaning making one cal into wasm, that then gets all the data I want and returns it.

Re: WASM 3.0 Completed

#337

Post by flohofwoe »

prewett wrote: post #259
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 actuall…

The problem is: even us old timers can't deny nor change the fact that operating systems have been putting up barriers to disallow running untrusted code downloaded from the internet.

Try to distribute an installer on Windows that isn't signed with an extensive EV-certificate for instance. It's scare popup galore.

Not to mention the closed gardens of the Apple and Google Stores which even when you get in, you can be kicked out again for absolutely no objective reason (they don't even need to tell you why).

> then we should be honest and build a virtualization abstraction that is actually what we want,

This is not in the interest of Microsoft, Google or Apple. They can't put the open web back into the box (yet, anyway), but they will not support any new attempts to create an open software ecosystem on "their" platforms.

Re: WASM 3.0 Completed

#338

Post by afiori »

someuser345 wrote: post #304
hinkley wrote: post #35

Still no mention of DOM. See you all for WASM 4.0.

End-users DON'T want developers' apps running in the browser to have freedom to access everything on the end-users' machines. Not having direct dom access is a security feature, as much as an MMU is. Please don't ask for this.

Wasm is sandboxed at pretty much the same security boundary as js there is nothing a DOM-enabled wasm module could do (security/privacy wise) that JavaScript can't already do

Re: WASM 3.0 Completed

#339

Post by afiori »

mikewarot wrote: post #128
hinkley wrote: post #35

Still no mention of DOM. See you all for WASM 4.0.

If you give WASM access to everything, you've defeated the main reason it exists. Ambient authority is the reason we need WASM in the first place.

For server applications true, but the reason browsers made wasm was because they needed a safer/portable/standardizable alternative to PNaCl

Re: WASM 3.0 Completed

#340

Post by silon42 »

tormeh wrote: post #260
jesse__ wrote: post #238

Earlier quoted context omitted.

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.

HTML is pretty bad (XUL was better), but (subset) of CSS is probably OK.
Post reply on HN