Live data from Hacker News

WASM Is the New CGI

roborooter.com

1–10 of 311 posts

Re: WASM Is the New CGI

#2
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 which is meant to be a universal code representation for a universal virtual machine. Have I missed something?

Re: WASM Is the New CGI

#3
post #2

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 which is meant to be a universal code representation for a universal virtual machine. Have I missed something?

The use of wasm makes sense to me in context of the article.

Re: WASM Is the New CGI

#5
post #2

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 which is meant to be a universal code representation for a universal virtual machine. Have I missed something?

The use of wasm makes sense to me in context of the article.

The article does not seem to support the title. You'll have to show me how it does. 'serverless' is a wholly different concept that doesn't have much to do with wasm. You could say it's CGI as a service, but that has nothing to do with wasm.

Re: WASM Is the New CGI

#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. Server side mostly is there to sync data between different instances of the app if the user uses it from different locations.

The tooling for this is in the works, but is not yet mature. e.g Electric-SQL. Once these libraries are mature, I think this space will take off.

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

WASM could succeed as well. But mostly in user's browser. Microsoft uses it today for C#/Blazor. But it isn't the correct approach as dotnet in browser will likely never be as fast as Javascript in the browser.

Re: WASM Is the New CGI

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

Re: WASM Is the New CGI

#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 pushes the computational cost from server to client.

Re: WASM Is the New CGI

#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 become faster.

And you pay dearly for being these two years ahead in terms of execution time. WASM is much more cumbersome to handle than plain JS when it comes to deployment, execution and debugging.

In IT we see it over and over again that saving developer time is more important than saving CPU cycles. So I think chosing WASM over plain JS is a net negative.

Post reply on HN