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

221–230 of 311 posts

Re: WASM Is the New CGI

#221

Post by BiteCode_dev »

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…

WASM is a child of the browser community and built on top of existing infra.

Java was an outsider trying to get in.

The difference is not in the nature of things, but rather who championed it.

Re: WASM Is the New CGI

#222

Post by VyseofArcadia »

consteval wrote: post #206
VyseofArcadia wrote: post #184

Earlier quoted context omitted.

I for one don't want to use web apps. I want the speed, convenience, and availability of native apps. I want to use applications that work if the internet isn't. I want to use applications that store my data locally. I want to use unglamorous applications that just work and use a native GUI toolkit instead of torturing a poor, overburdened document display engine into pretending it's a sane place for apps to run. Not…

The Web is portable, operating systems are not. Windows and Mac, being short-sighted, did this to themselves. Nobody can agree on anything, Microsoft is constantly deprecating UI frameworks, and it's not convenient at all to write local apps. It's only JUST NOW we have truly portable UI frameworks. And it's only because of the Web.

QT has been around for decades. So has GTK. Bindings for whatever language you could possibly want. Runs on whatever OS you want. We've had "truly portable" UI frameworks since the late 90s. This has not been an issue for my entire adult life. 20 years ago, I was using desktop applications that ran on Mac OS X, Windows, and *nix with no modifications. They were written in Python, used GTK, and just worked.

Web apps are popular because 1) people don't like installing things anymore for some reason and 2) it's easier to justify a subscription pricing model.

Re: WASM Is the New CGI

#223

Post by skybrian »

norswap wrote: post #213
vbezhenar wrote: post #59

Earlier quoted context omitted.

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…

Yes it’s true that there’s more to the story, but also, Java really is more complicated and harder to secure than WASM. You need to look at the entire attack surface and not just the bytecode.

For example, Java was the first mainstream language with built-in threading and that resulted in a pile of concurrency bugs. Porting Java to a new platform was not easy because it often required fixing threading bugs in the OS. By contrast, JavaScript and WASM (in the first version) are single-threaded. For JavaScript it was because it was written in a week, but for WASM, they knew from experience to put off threading to keep things simple.

Java also has a class loader, a security manager that few people understand and sensitive native methods that relied on stack-walking to make sure they weren’t called in the wrong place. The API at the security boundary was not well-designed.

A lot of this is from being first at a lot of things and being wildly ambitious without sufficent review, and then having questionable decisions locked in by backward compatibility concerns.

Re: WASM Is the New CGI

#224

Post by layer8 »

To expand the premise in the title, to be a true heir to that lineage, I would say that WASM needs to be as easy to host and deploy as PHP applications are (or used to be) on the LAMP stack of any random hosting provider. I suspect that’s not quite the case yet?

Re: WASM Is the New CGI

#225

Post by tromp »

adamc wrote: post #198
jasode wrote: post #189

Earlier quoted context omitted.

>So there's no fundamental difference between WASM and JVM bytecode. There's only practical difference: WASM proved to be secure and JVM did not. There's more to it than just the sandbox security model. The JVM bytecode doesn't have pointers which has significant performance ramifications for any language with native pointers. This limitation was one of the reasons why the JVM was never a serious compilation target p…

Also, the start-up time for the JVM made running applets very sluggish. Java quickly became a synonym for "slow".

Lack of 64-bit ints didn't help either...

Re: WASM Is the New CGI

#226

Post by titzer »

kaba0 wrote: post #150
titzer wrote: post #129

Earlier quoted context omitted.

I worked on JVM bytecode for a significant number of years before working on Wasm. JVM bytecode verification is non-trivial, not only to specify, but to implement efficiently. In Java 6 the class file format introduced stack maps to tame a worst-case O(n^3) bytecode verification overhead, which had become a DoS attack vector. Structured control flow makes Wasm validation effectively linear and vastly simpler to under…

Are they validating code to the same degree though? Like, there are obviously learned lessons in how WASM is designed, but at the same time JVM byte code being at a slightly higher level of abstraction can outright make certain incorrect code impossible to express, so it may not be apples to oranges. What I’m thinking of is simply memory corruption issues from the linear memory model, and while these can only corrupt…

Wasm bytecode verification is more strict than JVM bytecode verification. For example, JVM locals don't have declared types, they are inferred by the abstract interpretation algorithm (one of the reasons for the afore-mentioned O(n^3) worst case). In Wasm bytecode, all locals have declared types.

Wasm GC also introduces non-null reference types, and the validation algorithm guarantees that locals of declared non-null type cannot be used before being initialized. That's also done as part of the single-pass verification.

Wasm GC has a lower-level object model and type system than the JVM (basically structs, arrays, and first-class functions, to which object models are lowered), so it's possible that a higher-level type system, when lowered to Wasm GC, may not be enforceable at the bytecode level. So you could, e.g. screw up the virtual dispatch sequence of a Java method call and end up with a Wasm runtime type error.

Re: WASM Is the New CGI

#227

Post by jeberle »

titzer wrote: post #129
iainmerrick wrote: post #117

Earlier quoted context omitted.

I don't think there's any significant advance in the bytecode beyond e.g. JVM bytecode. The difference is in the surface area of the standard library -- Java applets exposed a lot of stuff that turned out to have a lot of security holes, and it was basically impossible to guarantee there weren't further holes. In WASM, the linear memory and very simple OS interface makes the sandboxing much more tractable.

I worked on JVM bytecode for a significant number of years before working on Wasm. JVM bytecode verification is non-trivial, not only to specify, but to implement efficiently. In Java 6 the class file format introduced stack maps to tame a worst-case O(n^3) bytecode verification overhead, which had become a DoS attack vector. Structured control flow makes Wasm validation effectively linear and vastly simpler to under…

Thx for this perspective and info. Regarding "signedness and floating point that closer matches hardware", I'm not seeing unsigned integers. Are they supported? I see only:

> Two’s complement signed integers in 32 bits and optionally 64 bits.

https://webassembly.org/docs/portability/#assumptions-for-ef...

And nothing suggesting unsigned ints here:

https://webassembly.org/features/

Re: WASM Is the New CGI

#228

Post by kaba0 »

adamc wrote: post #198
jasode wrote: post #189

Earlier quoted context omitted.

>So there's no fundamental difference between WASM and JVM bytecode. There's only practical difference: WASM proved to be secure and JVM did not. There's more to it than just the sandbox security model. The JVM bytecode doesn't have pointers which has significant performance ramifications for any language with native pointers. This limitation was one of the reasons why the JVM was never a serious compilation target p…

Also, the start-up time for the JVM made running applets very sluggish. Java quickly became a synonym for "slow".

You can’t just compare across decades of software and hardware development. Even downloading native binaries would have been sluggish, as the download would have been slow with those download speeds.

Re: WASM Is the New CGI

#229

Post by pjmlp »

tsimionescu wrote: post #196
pjmlp wrote: post #173

Earlier quoted context omitted.

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

It's not the same thing though. All of these languages have specific constructs for integrating with the CLR, the CLR is not just a compilation target like WASM is. C++/CLR even has a fourth kind of variable compared to base C++ (^, managed references of a type, in addition to the base type, * pointers to the type, and & references to the type). IronPython has not had a GIL since its early days. I'm sure the others h…

As if WebAssembly doesn't impose similar restrictions, with specific kinds of toolchains, and now the whole components mess.

This WebAssembly marketing is incredible.

Re: WASM Is the New CGI

#230

Post by pjmlp »

marcosdumay wrote: post #218
pjmlp wrote: post #134

Earlier quoted context omitted.

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.

Another example of lack of computing history.

Never happened before, really?!?

What examples since 1958 would make you happy?

Burroughs, Corvus Systems, IBM, Apple, Unisys, MSR, embedded,....

Probably none of them, I bet.

Post reply on HN