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

111–120 of 311 posts

Re: WASM Is the New CGI

#111

Post by silvestrov »

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…

Most of all the problem with Java Applets was that they were very slow to load and required so many resources that the computer came to a halt.

They also took much longer to develop than whatever you could cook up in plain html and javascript.

Re: WASM Is the New CGI

#112

Post by openrisk »

It is challenging to forecast how client-server architectures would evolve on the basis of technical merit, even if we restrict to "web architectures" (this itself being a bundle of multiple options).

Massive scaling with minimal resources is certainly one important enabler. If you were, e.g., to re-architect wikipedia with the knowledge and hardware of today how would you do it with wasm (on both desktop and mobile). How about a massive multiplayer game etc.

On the other hand you have the constraints and costs of current commercial / business model realities and legacy patterns that create a high bar for any innovation to flurish. But high does not mean infinitely high.

I hate to be the person mentioning AI on every HN thread but its a good example of the long stagnation and then torrential change that is the hallmark of how online connected computing adoption evolves: e.g., we could have had online numerically very intensive apps and API's a long time ago already (LLM's are not the only useful algorithm invented by humankind). But we didnt. It takes engineering a stampede to move the lazy (cash) cows to new grass land.

So it does feel that at some point starting with a fresh canvas might make sense (as in, substantially expand what is possible). When the cruft accumulates sometimes it collapses under its own weight.

Re: WASM Is the New CGI

#113

Post by baq »

llm_trw wrote: post #50
curtisblaine wrote: post #40

Earlier quoted context omitted.

That's intentional: they need you and your data tied to the server to make money. But there's no reason why it couldn't be local first (except the business model), since the bulk of execution is local. Incidentally, I think that's why local-first didn't take off yet: it's difficult to monetize and it's almost impossible to monetize to the extent of server-based or server-less. If your application code is completely l…

>Incidentally, I think that's why local-first didn't take off yet Local first is what we had all throughout the 80s to 10s. It's just that you can make a lot more from people who rent your software rather than buy it.

The sweet, sweet ARR. Investors love it, banks love it, employees should also love it since it makes their paychecks predictable.

It sucks for customers, though.

Re: WASM Is the New CGI

#114

Post by flohofwoe »

kgeist wrote: post #99
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…

>Wasm has verification specification. This verified subset makes security exploits seen in those older technologies outright impossible Both Java and .NET verify their bytecode. >Wasm bytecode is trivial (as it gets) to turn into machine code JVM and .NET bytecodes aren't supercomplicated either. Probably the only real differences are: 1) WASM was designed to be more modular and slimmer from the start, while Java and…

AFAIK the big new thing in WASM is that it enforces 'structured control flow' - so it's a bit more like a high level AST than an assembly-style virtual ISA. Not sure how much of that matters in practice, but AFAIK that was the one important feature that enabled the proper validation of WASM bytecode.

Re: WASM Is the New CGI

#115

Post by jamil7 »

TekMol wrote: post #39
jamil7 wrote: post #33

Earlier quoted context omitted.

You’re assuming a lot of things in this comment, it seems like you believe every software engineer is working with the same constraints, language and platform as yourself.

No. I say we could build the same dev experience to non-js coders by offering them compile-2-js tools instead of compile-2-wasm tools.

Not really because then you need a JS environment everywhere you want to run your code. If I write a Rust module I have the possibility to compile to WASM or machine code. This is what I meant in my other comment, your assumption is everyone is making browser apps in Javascript that don't have any performance or resource constraints.

Re: WASM Is the New CGI

#116

Post by DanielHB »

TekMol wrote: post #10

I don't see WASM as a significant step forward. In fact, I question its purpose altogether. Before WASM you could already compile code from other languages into JavaScript. And have the same benefits as you have with WASM. The only benefit WASM brings is a bit faster execution time. Like twice the speed. Which most applications don't need. And which plain JavaScript offers about two years later because computers beco…

> Before WASM you could already compile code from other languages into JavaScript. And have the same benefits as you have with WASM.

If you are referring to asm.js you must be joking. asm.js was basically a proof of concept and is worse in every way compared to WASM.

Like parsing time overhead alone makes it a non-option for most large applications.

You seem to imply you should just do it in plain JS instead for "deployment, execution and debugging" benefits. Imagine if you could be free to use those python ML libs in any language of your choice, that alone is enough of an argument. No one is going to reimplement them in JS (or any other environemtn) unless there is a huge ecosystem movement around it.

Re: WASM Is the New CGI

#117

Post by iainmerrick »

flohofwoe wrote: post #114
kgeist wrote: post #99

Earlier quoted context omitted.

>Wasm has verification specification. This verified subset makes security exploits seen in those older technologies outright impossible Both Java and .NET verify their bytecode. >Wasm bytecode is trivial (as it gets) to turn into machine code JVM and .NET bytecodes aren't supercomplicated either. Probably the only real differences are: 1) WASM was designed to be more modular and slimmer from the start, while Java and…

AFAIK the big new thing in WASM is that it enforces 'structured control flow' - so it's a bit more like a high level AST than an assembly-style virtual ISA. Not sure how much of that matters in practice, but AFAIK that was the one important feature that enabled the proper validation of WASM bytecode.

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.

Re: WASM Is the New CGI

#118

Post by TekMol »

jamil7 wrote: post #115
TekMol wrote: post #39

Earlier quoted context omitted.

No. I say we could build the same dev experience to non-js coders by offering them compile-2-js tools instead of compile-2-wasm tools.

Not really because then you need a JS environment everywhere you want to run your code. If I write a Rust module I have the possibility to compile to WASM or machine code. This is what I meant in my other comment, your assumption is everyone is making browser apps in Javascript that don't have any performance or resource constraints.

    possibility to compile to WASM or machine code
How is this better than "possibility to compile to JS or machine code"?

Re: WASM Is the New CGI

#119

Post by iainmerrick »

singularity2001 wrote: post #66
rpcope1 wrote: post #4

So basically we're reinventing the JVM and it's ecosystem?

except that WASM has a huge classloader / linker problem: It's still very hard to combine two wasm files into one and get the memory merger right. Maybe component model can fix it but it comes with so much bloated nonsense that an adaption in Safari might take forever.

It's a problem for some use cases, but is it really a "huge" problem in general?

You can't easily publish a library in WASM and link it into another application later. But you can publish it as C++ source (say) and compile it into a C++ application, and build the whole thing as WASM.

What are the scenarios where you really really want libraries in WASM format?

Re: WASM Is the New CGI

#120

Post by jauntywundrkind »

bigstrat2003 wrote: post #91
torginus wrote: post #62

Earlier quoted context omitted.

Hehehe, so the future is how we used to run applications from before the era of the web.

Except worse, because everything has to run in a gigantic web browser even if it could be a small native app.

Every native app has to be run in a gigantic special OS when it could be a small webapps running in a medium sized browser.

Many many ChromeOS (web based consumer OS) laptops are 4GB of ram. You do not want to try that with any normal OSes.

Post reply on HN