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

71–80 of 311 posts

Re: WASM Is the New CGI

#71

Post by flohofwoe »

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…

> untrusted third party compiled code in a web browser.

WASM makes that safe, and that's the whole point. It doesn't increase the attack surface by much compared to running Javascript code in the browser, while the alternative solutions where directly poking through into the operating system and bypassing any security infrastructure of the browser for running untrusted code.

Re: WASM Is the New CGI

#72

Post by jillesvangurp »

WASM replaces a language specific vm (javascript) with a general purpose one anywhere javascript vms are currently used. But not exclusively just there. General purpose here means it can run just about anything with a compiler or interpreter for it. Including javascript. So anything, anywhere.

Since it is generally implemented as part of the javascript engine, it inherits a lot of stuff that comes with it like sandboxing and access to the APIs that come with it. Standardizing access to that is a bit of an ongoing process but the end state here is that anything that currently can only be done in Javascript will also be possible in WASM. And a lot more that is currently hard or impossible in Javascript. And it all might run a little faster/smoother.

That makes WASM many things. But the main thing it does is remove a lot of restrictions we've had on environments where Javascript is currently popular. Javascript is a bit of a divisive language. Some people love it, some people hate it. It goes from being the only game in town to being one of many things you can pick to do a thing.

It's been styled as a Javascript replacement, as a docker replacement, as a Java replacement, a CGI replacement (this article), etc. The short version of it is that it is all of these things. And more.

Re: WASM Is the New CGI

#73

Post by curtisblaine »

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…

Some applications are inherently hard to make local-first. Social media and Internet forums come to mind. Heavily collaborative applications maybe too.

Re: WASM Is the New CGI

#74

Post by boomskats »

OtomotO wrote: post #63
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 have a different take on this: It depends on what you're actually building. For the business applications I build SSR (without any JS in the stack, but just golang or Rust or Zig) is the future. It saves resources which in turn saves money, is way more reliable (again: money) and less complex (again: money) to syncing state all the time and having frontend state diverge from the actual (backend) state.

I have a different take on this:

Business applications don't care about client side resource utilisation. That resource has already been allocated and spent, and it's not like their users can decide to walk away because their app takes an extra 250ms to render.

Client-side compute is the real money saver. This means CSR/SPA/PWA/client-side state and things like WASM DuckDB and perspective over anything long-lived or computationally expensive on the backend.

Re: WASM Is the New CGI

#75

Post by flohofwoe »

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…

> WASM is much more cumbersome to handle than plain JS when it comes to deployment, execution and debugging.

For some of us it's much easier than dealing with Javascript though (for instance debugging C/C++ in Visual Studio is much nicer than debugging JS in Chrome - and that's possible by simply building for a native target, and then just cross-compile to WASM - but even the WASM debugging situation has improved dramatically with https://marketplace.visualstudio.com/items?itemName=ms-vscod...)

Re: WASM Is the New CGI

#76

Post by torginus »

Just in Time (JIT) compilation is not possible as dynamic Wasm code generation is not allowed for security reasons.

This sounds.. not right. Honestly,this is an essential feature for allowing workloads like hot reloading code cleanly.

I'm quite convinced the alleged security argument is bull. You can hot reload JS (or even do wilder things like codegen) at runtime without compromising security. Additionally, you can emulate codegen or hot reload, by dynamically reloading the entire Wasm runtime and preserving the memory, but the user experience will be clunky.

I don't see any technical reason why this couldn't be possible. If this were a security measure, it could be trivially bypassed.

Also, WASM bytecode is very similar conceptually to .NET IL, Java bytecode etc., things designed for JIT compilation.

I kind of dislike WASM. It's a project lacking strong direction and will to succeed in a timely manner. First, the whole idea is conceptually unclear, its name suggests that it's supposed to be 'assembly for the web', a machine language for a virtual CPU, but it's actually an intermediate representation meant for compiler backends, with high-level features planned such as GC support. It's still missing basic features, like the aforementioned hot reload, non-hacking threading, native interfacing with the DOM (without Javascript ideally), low-overhed graphics/compute API support, low-level audio access etc. You can't run a big multimedia app without major compromises in it.

Re: WASM Is the New CGI

#77

Post by flohofwoe »

rpcope1 wrote: post #4

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

In a way yes, except that WASM supports many more languages (e.g. back when I started to look into running C/C++ code in the browser - around 2010 or so - it was absolutely impossible to compile C/C++ to the JVM, which at the time would have been nice because Java Applets still were a thing - of course WASM didn't exist yet either, but Emscripten did, which eventually led to the creation of WASM via asm.js).

Re: WASM Is the New CGI

#78

Post by flohofwoe »

torginus wrote: post #76

Just in Time (JIT) compilation is not possible as dynamic Wasm code generation is not allowed for security reasons. This sounds.. not right. Honestly,this is an essential feature for allowing workloads like hot reloading code cleanly. I'm quite convinced the alleged security argument is bull. You can hot reload JS (or even do wilder things like codegen) at runtime without compromising security. Additionally, you can…

> Just in Time (JIT) compilation is not possible as dynamic Wasm code generation is not allowed for security reasons.

Browsers definitely use a form of JIT-ing for WASM (which is a bit unfortunate, because just as with JITs, you might see slight 'warmup stutter' when running WASM code for the first time - although this has gotten a lot better over the years).

...also I'm pretty sure you can dynamically create a WASM blob in the browser and then dynamically instantiate and run that - not sure if that's possible in other WASM runtimes though, and even in the browser you'll have to reach out Javascript, but that's needed for accessing any sort of 'web API'.

Re: WASM Is the New CGI

#79

Post by palmfacehn »

SkiFire13 wrote: post #52
palmfacehn wrote: post #9

Earlier quoted context omitted.

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.

From the article:

>Wasm on the Server

>Why on earth are we talking about Wasm? Isn't it for the browser?

>And I really hope even my mention of that question becomes dated, but I still hear this question quite often so it's worth talking about. Wasm was initially developed to run high performant code in the web browser.

Re: WASM Is the New CGI

#80

Post by DougMerritt »

pdpi wrote: post #51
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 o…

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

Indeed, graphics pioneer and all-around-genius Ivan Sutherland observed (and named) this back in 1968:

"wheel of reincarnation "[coined in a paper by T.H. Myer and I.E. Sutherland On the Design of Display Processors, Comm. ACM, Vol. 11, no. 6, June 1968)] Term used to refer to a well-known effect whereby function in a computing system family is migrated out to special-purpose peripheral hardware for speed, then the peripheral evolves toward more computing power as it does its job, then somebody notices that it is inefficient to support two asymmetrical processors in the architecture and folds the function back into the main CPU, at which point the cycle begins again.

"Several iterations of this cycle have been observed in graphics-processor design, and at least one or two in communications and floating-point processors. Also known as the Wheel of Life, the Wheel of Samsara, and other variations of the basic Hindu/Buddhist theological idea. See also blitter."

https://www.catb.org/jargon/html/W/wheel-of-reincarnation.ht...

Post reply on HN