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

51–60 of 311 posts

Re: WASM Is the New CGI

#51

Post by pdpi »

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…

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 of languages (most common being C and C++ through Emscripten, and Rust).

> Maybe I’m just old, but I thought we’d learnt our lesson on running untrusted third party compiled code in a web browser.

WASM is bytecode, and I think most implementations share a lot of their runtime with the host JavaScript engine.

> In all of these cases it’s pitched as improving the customer experience but also conveniently pushes the computational cost from server to client.

The whole industry has swung from fat clients to thin clients and back since time immemorial. The pendulum will keep swinging after this too.

Re: WASM Is the New CGI

#52

Post by SkiFire13 »

palmfacehn wrote: post #9
rpcope1 wrote: post #4

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

If your webserver is already JVM based, there's no context switch between the webserver and the application. Not sure how this would be solved with WASM.

This doesn't make sense, WASM is supposed to run on the client, which is generally a different machine than the webserver, while a context switch is an event that happens within a single machine.

Re: WASM Is the New CGI

#53

Post by thot_experiment »

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.

I will likely spend time implementing my solver in several different styles because this is a project I'm tackling largely to make some points about how I think WASM should be used. I'm far from final benchmarks on this but my suspicion is that the gap will be large.

Yes javascript is very well optimized, but as someone who's spent a lot of time writing javascript where speed matters, it's not easy, and it's not predictable. You're at the mercy of arcane optimizations in V8 which might not work for your specific situation because you did something weird, and if you're taking a lot of care not to do anything weird, and manually managing your memory with typed arrays, well, then you might as well write C and compile to WASM.

Re: WASM Is the New CGI

#54

Post by wokwokwok »

What the article actually says:

> If we go back to thinking about our Application Server models; this allows us to have a fresh process but without paying the startup costs of a new process. Essentially giving us CGI without the downsides of CGI. Or in more recent terms, serverless without cold starts. This is how Wasm is the new CGI.

^ It's not a frivolous claim.

> Wasm improves performance, makes process level security much easier, and lowers the cost of building and executing serverless functions. It can run almost any language and with module linking and interface types it lowers the latency between functions incredibly.

^ Not unreasonable.

I don't agree that its necessarily totally 'game changing', but if you read this article and you get to the end and you dont agree with:

> When you change the constraints in a system you enable things that were impossible before.

Then I'm left scratching my head what it was you actually read, or what the heck you're talking about.

> Serverless is mostly there to make money for Amazon and Azures of the world and will eventually go the way of the CGI.

There's... just no possible future, in which AWS and Azure just go away and stop selling something which is making them money, when a new technology comes along and makes it easier, safer and cheaper to it.

> I kind of like this variety of headline for it's ability to stimulate discussion but it's also nonsense. CGI can be any type of code responding to an individual web request, represented as a set of parameters. It has basically nothing to do with wasm

*shakes head sadly...*

...well, time will tell, but for alllll the naysayers, WASM is here to stay and more and more people are using it for more and more things.

Good? Bad? Dunno. ...but it certainly isn't some pointless niche tech that no one cares about is about to disappear.

CGI enabled a lot of things. WASM does too. The comparison isn't totally outrageous. It'll be fun to see where it ends up. :)

Re: WASM Is the New CGI

#55

Post by smolder »

cheema33 wrote: post #6

I have a different take on this. I think local-first is the future. This is where the apps runs mostly within user's browser with little to no help from the server. Apps like Figma, Linear and Superhuman use this model very successfully. And to some degree Stackblitz does as well. If somewhat complex apps like Figma can run almost entirely within user's browser, then I think vast majority of the apps out there can. S…

I also support the development of client side applications, but I don't think they should necessarily be run in a browser or sandbox or be bought through an app store, and it's definitely not a new idea.

Re: WASM Is the New CGI

#56

Post by svieira »

smolder wrote: post #25
svieira wrote: post #13

Earlier quoted context omitted.

It's quite buried amid a lot of extra paragraphs expositing about WASM and the future of serverless functions in general, but the article does contain this quote: > One of the many effect of how [WASM] modules are isolated is that you can "pause" a module, and save its memory as a data segment. A similar concept to a Snapshot of a virtual machine. You can then start as many copies of the paused module as you like. (A…

This is not like CGI. Calling it "the new CGI" seems to me like a way to confuse people, since CGI was a response to individual requests and carrying state across requests was always extra work. None of this has to do with WASM in particular.

With CGI the developer of the script could pretend that the-only-thing-which-existed was this request and do all kinds of things that would bring down a persistent process (leak memory, mutate globals, etc.) The problem was that spinning up a process per-request was expensive and slow. Now, with WASM's memory model it becomes possible to have a process that both does all the slow work initialization work once and has the ease-of-reasoning properties of CGI's "a single process for a single request" serving model.

Re: WASM Is the New CGI

#57

Post by SkiFire13 »

pjmlp wrote: post #7
rpcope1 wrote: post #4

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

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.

All of those bytecode formats were designed to support higher abstractions. WASM on the other hand was born from asm.js, which tried to remove abstraction to make code run faster. Ultimately the goal for WASM was to run code faster, hopefully near native speed, which is not a priority for all the bytecodes you mentioned. If that wasn't needed then Javascript would have been enough.

Re: WASM Is the New CGI

#58

Post by thot_experiment »

TekMol wrote: post #46
thot_experiment wrote: post #37

Earlier quoted context omitted.

Off the rip because I didn't spend time to make the JS implementation keep all of it's data in a typed array that I manually manage, because it's tedious to do that in JS and it's straightforward in C. Though I'm betting there are other benefits I'll get from -O2 and static analysis.

Compiling your C to WASM might make it run twice as fast as compiling it to JS. That's all. All other aspects of the workflow are the same.

I will try but I suspect the final score will be

    1. WASM
    2. JS handwritten for speed
    3. C compiled to JS
and the gaps will be greater than 2x

Re: WASM Is the New CGI

#59

Post by vbezhenar »

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 from any domain without asking user whether he trusts it or not.

WASM builds on JavaScript engine, delivering similar security guarantees.

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.

So now Google Chrome is secure enough for billions of people to safely run evil WASM without compromising their phones, and you can copy this engine from Google Chrome to server and use this strong sandbox to run scripts from various users, which could share resources.

An alternative is to use virtualization. So you can either compile your code to WASM blob and run it in the big WASM server, or you can compile your code to amd64 binary, put it along stripped Linux kernel and run this thing in the VM. There's no clear winner here, I think, for now, there are pros and cons for every approach.

Re: WASM Is the New CGI

#60

Post by TekMol »

thot_experiment wrote: post #58
TekMol wrote: post #46

Earlier quoted context omitted.

Compiling your C to WASM might make it run twice as fast as compiling it to JS. That's all. All other aspects of the workflow are the same.

I will try but I suspect the final score will be 1. WASM 2. JS handwritten for speed 3. C compiled to JS and the gaps will be greater than 2x

Awesome. I will notice when you reply here, no matter when. I routinely check for new replies even to old comments.
Post reply on HN