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

WASM Is the New CGI

roborooter.com

Post reply on HN
Print view View original

211–220 of 311 posts

Re: WASM Is the New CGI

#211

Post by fallous »

PoignardAzur wrote: post #142
fallous wrote: post #19

This article really does remind me of an old Law of Software that we used to invoke: Any sufficiently large and long-lived application will eventually re-implement the entire software stack it runs on, including the operating system.. and it will re-implement it poorly. I'm unsure of the source for this Law, but it certainly proves correct more often than not.

The witty version is known as Greenspun's tenth rule: "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." The general pattern is called the Inner-Platform Effect.

YES! The Inner-Platform Effect is exactly what I was trying to dig up through my fossilized neurons. Thank you.

Re: WASM Is the New CGI

#212

Post by Tepix »

flohofwoe wrote: post #171
Tepix wrote: 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).

The WASM code doesn't have access to the DOM, if you want to have a web app that interacts with the user (intriguing, isn't it?) you'll end up writing a lot of javascript glue code.

Re: WASM Is the New CGI

#213

Post by norswap »

vbezhenar wrote: post #59
junto wrote: 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…

Java and Flash failed to deliver its promise of unbreakable sandbox where one could run anything without risking compromising host. They tried, but their implementations were ridden with vulnerabilities and eventually browsers made them unusable. Other mentioned technologies didn't even promise that, I think. JavaScript did deliver its promise of unbreakable sandbox and nowadays browser runs JavaScript, downloaded fr…

> WASM proved to be secure and JVM did not.

This is an oversimplification — there's nothing about the JVM bytecode architecture making it insecure. In fact, it is quite simpler as an architecture than WASM.

Applets were just too early (you have to remember what the state of tech looked like back then), and the implementation was of poor quality to boot (owing in part to some technical limitations — but not only).

But worst of all, it just felt jank. It wasn't really part of the page, just a little box in it, that had no connection to HTML, the address bar & page history, or really anything else.

The Javascript model rightfully proved superior, but there was no way Sun could have achieved it short of building their own browser with native JVM integration.

Today that looks easy, just fork Chromium. But back then the landscape was Internet Explorer 6 vs the very marginal Mozilla (and later Mozilla Firefox) and proprietary Opera that occasionally proved incompatible with major websites.

Re: WASM Is the New CGI

#214

Post by anthk »

thot_experiment wrote: post #29
pjmlp wrote: post #7

Earlier quoted context omitted.

Yeah, by folks that most likely used to bash Application Servers from early 2000's. Not only JVM, also CLR, BEAM, P-Code, M-Code, and every other bytecode format since UNCOL came to be in 1958, but lets not forget about the coolness of selling WASM instead.

The coolness of WASM is that I can run WASM on like 99.999% of the targets I care to run code on with zero friction. Everyone (well it's HN so someone is probably on LYNX) reading this page is doing so in a browser with a WASM runtime. That has tremendous value.

Not Lynx as it doesn't show up the correct layout on comments.

But Dillo works perfectly fine. No JS, no WASM, crazy fast on a n270 netbook.

I can't barely run WASM programs that could be run fine under a Pentium 3-4.

Re: WASM Is the New CGI

#215

Post by tightbookkeeper »

feverzsj wrote: post #92

Companies choose wasm to avoid crawlers.

And Google probably wanted to ban applets etc because they were negatively impacting search

That doesn’t mean there weren’t good technical reasons, but that’s not necessarily the driver,

For example, ssl is obviously good, but ssl required also raises the cost of making a new site above zero, greatly reducing search spam (a problem that costs billions otherwise).

Re: WASM Is the New CGI

#216

Post by consteval »

xnorswap wrote: post #42
thot_experiment wrote: post #22

Earlier quoted context omitted.

Bad take. Yes, you can probably optimize a lot of algos in JS such that they are pretty fast, but THAT is cumbersome. I'd much rather write the things I need to go fast in a language that's good at that (I use C for this). I'm currently working on a toolpath optimizer and I'm compiling just the optimizer function to WASM, it's a couple kilobytes and will probably be an order of magnitude faster than the JS implementa…

Javascript is incredibly well optimised, I'm surprised if there's an order of magnitude difference between JS and WASM without a fundamental difference in algorithm chosen.

When it comes to GC languages they can often appear very fast for use cases that don't use a lot of memory.

If you use an algorithm that near exhausts memory, that's where you'll start seeing that "order of magnitude" difference between JS and something like C++. The same goes for Java and C#.

At low memory utilization, the GC can just put off collection, which saves execution time, so the runtime appears fast. But if you're close to the limit, then the GC has no choice but to pause often before continuing. Not very many algorithms will encounter this, but applications might, depending on what they do.

Re: WASM Is the New CGI

#217

Post by swsieber »

pjmlp wrote: post #183
pdpi wrote: post #178

Earlier quoted context omitted.

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

JVM is one bytecode among many since 1958, no need to keep bashing against it as way to champion WASM. Opt-in or not, it is there on the runtime.

It seems relevant since we are in a thread asking to compare WASM to java applets.

Re: WASM Is the New CGI

#218

Post by marcosdumay »

pjmlp wrote: post #134
thot_experiment wrote: post #29

Earlier quoted context omitted.

The coolness of WASM is that I can run WASM on like 99.999% of the targets I care to run code on with zero friction. Everyone (well it's HN so someone is probably on LYNX) reading this page is doing so in a browser with a WASM runtime. That has tremendous value.

Applies to most bytecode formats, it is a matter of implementation.

It never applied to any web bytecode formats, and applies to very few local local ones (arguably, none).

It's just a matter of having everybody agree to install the same interpreter, yes. That never happened before.

Re: WASM Is the New CGI

#219

Post by flohofwoe »

Tepix wrote: post #212
flohofwoe wrote: post #171

Earlier quoted context omitted.

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

The WASM code doesn't have access to the DOM, if you want to have a web app that interacts with the user (intriguing, isn't it?) you'll end up writing a lot of javascript glue code.

There are enough binding libraries by now where you don't need to write a single line of JS (e.g. https://rustwasm.github.io/wasm-bindgen/examples/dom.html).

For better or worse, browser APIs have been designed to be used with Javascript so some FFI magic needs to happen when called from other languages, with or without WASM.

And if each web API would automatically come with a C API specification (like WebGPU kinda does for instance), Rust people would complain anyway that they need to talk to an 'archaic' C API instead of a 'modern' Rust API etc etc...

Re: WASM Is the New CGI

#220

Post by igrunert »

kgeist wrote: post #103
Laremere wrote: post #49

Earlier quoted context omitted.

Wasm has a great benefits over those technologies: - Wasm has verification specification that wasm bytecode must comply to. This verified subset makes security exploits seen in those older technologies outright impossible. Attacks based around misbehaving hardware like heartbleed or rowhammer might still be possible, but you, eg, can't reference memory outside of your wasm's memory by tricking the VM to interpret a n…

Btw, is WASM really more secure? JVM and .NET basically have capability-based security thanks to their OOP design together with bytecode verification: if you can't take a reference to an object (say, there's a factory method with a check), you can't access that object in any way (a reference is like an access token). As far as I understand, in WASM memory is a linear blob, so if I compile C++ to WASM, isn't it possib…

When discussing security it's important to keep in mind the threat model.

We're mostly concerned with being able to visit a malicious site, and execute wasm from that site without that wasm being able to execute arbitrary code on the host - breaking out of the sandbox in order to execute malware. You say the only benefit is that access to the OS is isolated, but that's the big benefit.

Having said that, WebAssembly has some design decisions that make your exploits significantly more difficult in practice. The call stack is a separate stack from WebAssembly memory that's effectively invisible to the running WebAssembly program, so return oriented programming exploits should be impossible. Also WebAssembly executable bytecode is separate from WebAssembly memory, making it impossible to inject bytecode via a buffer overflow + execute it.

If you want to generate WebAssembly code at runtime, link it in as a new function, and execute it, you need participation from the host, e.g. https://wingolog.org/archives/2022/08/18/just-in-time-code-g...

Post reply on HN