Live data from Hacker News

WASM Is the New CGI

roborooter.com

171–180 of 311 posts

Re: WASM Is the New CGI

#171
post #167

I disagree. In particular for me the allure for CGI was its simplicity. Have you played around with WASM in the browser? It involves way too many steps to get it integrated into the web page and to interact with it. I let chatgpt do the tedious work, have a look at a minimal example: https://chatgpt.com/share/6707c2f3-5840-8008-96eb-e5002e2241...

The part of loading and instantiating the WASM blob is 3 lines of Javascript, and two of those are for the fetch() call. Calling into the WASM module is a regular JS function call. Not sure how this could be simplified much further, it is much simpler than dealing with FFI in other runtime environments (for instance calling into native code from Java or Kotlin on Android).

Re: WASM Is the New CGI

#172
post #162

Earlier quoted context omitted.

> JavaScript did deliver its promise of unbreakable sandbox Aren't its VM implementations routinely exploited? Ranging from "mere" security feature exploits, such as popunders, all the way to full on proper VM escapes? Like even in current day, JS is ran interpreted on a number of platforms, because JIT compiling is not trustworthy enough. And I'm pretty sure the interpreters are no immune either.

There were a bunch of things missing from OPs description around the security considerations of Wasm but it has a lot of other stuff on top of what the browser provides when it’s executing JavaScript. The primary one is its idea of a “capability model” where it basically can’t do any kinds of risky actions (I.e touch the outside world via the network or the file system for example) unless you give it explicit permiss…

I was surprised when google has agreed to implement the capabilities model for Chrome. I would guess that asking the user for permission to access the microphone would not sit well with google. In smartphones they own the OS so they can ignore wasm's security model as much as they like.

Re: WASM Is the New CGI

#173
post #8

Can someone explain to me what the difference really is between WASM and older tech like Java Applets, ActiveX, Silverlight and Macromedia Flash, because they don’t really sound much different to me. Maybe I’m just old, but I thought we’d learnt our lesson on running untrusted third party compiled code in a web browser. In all of these cases it’s pitched as improving the customer experience but also conveniently push…

Pushing compute to the client is the whole point, and is often a major improvement for the end user, especially in the era in which phones are faster than the supercomputers of the 90s. And otherwise, WASM is different in two ways. For one, browsers have gotten pretty good at running untrusted 3rd party code safely, which Flash or the JVM or IE or.NET were never even slightly adequate for. The other difference is tha…

CLR means Common Language Runtime for a reason.

From 2001,

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

Re: WASM Is the New CGI

#175
post #174

WASM runs on the client side. WASM is basically the new Microsoft Common Language Runtime, or the new JVM etc. But OPEN!

Plenty of choices for that, and Wikipedia doesn't list everything if one is willing to dive into computing history.

https://en.wikipedia.org/wiki/Bytecode

Re: WASM Is the New CGI

#176
post #162

Earlier quoted context omitted.

There were a bunch of things missing from OPs description around the security considerations of Wasm but it has a lot of other stuff on top of what the browser provides when it’s executing JavaScript. The primary one is its idea of a “capability model” where it basically can’t do any kinds of risky actions (I.e touch the outside world via the network or the file system for example) unless you give it explicit permiss…

I was surprised when google has agreed to implement the capabilities model for Chrome. I would guess that asking the user for permission to access the microphone would not sit well with google. In smartphones they own the OS so they can ignore wasm's security model as much as they like.

I feel there’s a bit of a disconnect here between Google’s Ads division who are looking to basically do the bare minimum to avoid getting repeatedly spanked primarily by the EU but also now with talk of a breakup in the US and most other parts of Google who I say this entirely unironically are by far the best of all major options with regards to security in both the browser and their public cloud offerings. I’d even extend that possibly to operating systems as well. ChromeOS is miles in front of anything else out there currently but on mobile Android has historically lagged behind iOS although that gap is close to indistinguishable in 2024.

Re: WASM Is the New CGI

#177

Earlier quoted context omitted.

I feel like I need to be a bit more frank > WASM is just a bytecode (similar to JVM or .NET bytecode but even higher level ... Yes, and I think this was a poor engineering choice on behalf of WASM engineering team, instead of using something much closer to actual assembly. And we are grappling with long startup times and lots of compiler infra pushed into the client because of that. > ...not your own WASM blob, but y…

> they made bad technical decisions in the design Considering that the most important design requirement was to have a security model that's good enough for running untrusted code in web browsers at near native performance, I think the WASM peeps did a pretty good job. Your requirements may be different, but then maybe WASM simply isn't the right solution for you (there are plenty of alternatives outside web browsers…

PNacl also had the same sandboxing requirement, yet had many of the features still missing today from WAsm (threads, 3d graphics API support, access to other native APIs), and it didn't suffer from slow startup times. It had pretty nice and quick uptake considering the tooling was very similar to native toolchains.

According to this benchmark (first Google result I found), it was even faster:

https://apryse.com/blog/wasm/wasm-vs-pnacl

While it might not have been perfect, WASM is yet to catch up in many ways, and some of its limitations might come from its design.

Re: WASM Is the New CGI

#178
post #137
post #51

Earlier quoted context omitted.

Unlike ActiveX, Silverlight, or Flash, it's an open standard developed by a whole bunch of industry players, and it has multiple different implementations (where Java sits on that spectrum is perhaps a bit fuzzier). That alone puts it heads and shoulders above any of the alternatives. Unlike the JVM, WASM offers linear memory, and no GC by default, which makes it a much better compilation target for a broader range o…

WasmGC is there no matter what, unless we are talking about an incomplete implementation, also plenty of linear memory based bytecodes since 1958.

WasmGC is a feature you can opt in to, rather than a core feature of the platform. It's more of an enabler for languages that expect a GC from their host platform (for things like Dart and Kotlin). Inversely, other forms of bytecode might have linear memory, but the JVM isn't one of those.

For the purposes of OP's question, the memory model difference is one of the key reasons why you might want to use wasm instead of a java applet.

Re: WASM Is the New CGI

#179
post #8

Can someone explain to me what the difference really is between WASM and older tech like Java Applets, ActiveX, Silverlight and Macromedia Flash, because they don’t really sound much different to me. Maybe I’m just old, but I thought we’d learnt our lesson on running untrusted third party compiled code in a web browser. In all of these cases it’s pitched as improving the customer experience but also conveniently push…

For starters, in that it gives you memory safe bytecodes computation that aren't coupled with one specific language.

Re: WASM Is the New CGI

#180
post #162

Earlier quoted context omitted.

There were a bunch of things missing from OPs description around the security considerations of Wasm but it has a lot of other stuff on top of what the browser provides when it’s executing JavaScript. The primary one is its idea of a “capability model” where it basically can’t do any kinds of risky actions (I.e touch the outside world via the network or the file system for example) unless you give it explicit permiss…

I was surprised when google has agreed to implement the capabilities model for Chrome. I would guess that asking the user for permission to access the microphone would not sit well with google. In smartphones they own the OS so they can ignore wasm's security model as much as they like.

[deleted]
Post reply on HN