WASM Is the New CGI

Post by networked » Thu, Oct 10, 2024, 1:43 PM UTC

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.

Post by jmull » Thu, Oct 10, 2024, 1:47 PM UTC

moi2388 wrote: post #67

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…

> 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. Might be true, but both will be more than fast enough. We develop Blazer WASM. When it comes to performance, dotnet is not the issue

Post by afavour » Thu, Oct 10, 2024, 1:51 PM UTC

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…

Post by nilslice » Thu, Oct 10, 2024, 2:11 PM UTC

flohofwoe wrote: post #140

iainmerrick wrote: post #119

Earlier quoted context omitted.

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?

The only situation I can think of is a plugin system for native applications, where 'WASM DLLs' would solve a lot of issues compared to native DLLs. But those WASM plugins would be self-contained and wouldn't need to dynamically load other WASM 'DLLs', so that situation is trivial even without the WASM Component Model thingie (which I also think is massively overengineered and kinda pointless - at least from my PoV,…

Post by tightbookkeeper » Thu, Oct 10, 2024, 2:15 PM UTC

mmis1000 wrote: post #181

perching_aix wrote: post #160

Earlier quoted context omitted.

> JavaScript did deliver its promise of unbreakable sandbox Aren't its VM implementations routinely exploited? Ranging from "mere" security feature exploits, such as popunders, all the way to full on proper VM escapes? Like even in current day, JS is ran interpreted on a number of platforms, because JIT compiling is not trustworthy enough. And I'm pretty sure the interpreters are no immune either.

Both chrome and firefox lock down the javascript that site is running into their own box. By using a standalone process and whatever mechanism system provided. A pwned site alone isn't enough to cause damage. You also need to overcome other layer of defenses (unlike something like flash that can be owned from it's script engine alone) It usually require multi 0 day to overcome all those defense and do anything useful…