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

271–280 of 311 posts

Re: WASM Is the New CGI

#271

Post by marcosdumay »

pjmlp wrote: post #230
marcosdumay wrote: post #218

Earlier quoted context omitted.

It never applied to any web bytecode formats, and applies to very few local local ones (arguably, none). It's just a matter of having everybody agree to install the same interpreter, yes. That never happened before.

Another example of lack of computing history. Never happened before, really?!? What examples since 1958 would make you happy? Burroughs, Corvus Systems, IBM, Apple, Unisys, MSR, embedded,.... Probably none of them, I bet.

Never happened before.

And your list has no example of anything that was universally installed on everybody's system. The closest is IBM (if you mean x86 opcodes), but code for that one needed to be specialized by OS before it became ubiquitous, and got competitors before its main OS became ubiquitous, and then became ubiquitous again but with 2 main OSes, and then got competitors again.

Re: WASM Is the New CGI

#272

Post by bhelx »

tombl wrote: post #237
bhelx wrote: post #187

Earlier quoted context omitted.

The statement is correct. Wasm cannot mark memory as executable. It's effectively a Harvard Architecture. The code and memory are split. Furthermore you cannot jump to arbitrary points in code. There isn't even a jump instruction. > 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. JIT here is referring to…

wasm has no way to remap writable memory as executable, but you can absolutely call back into javascript to instantiate and link a new executable module, like https://github.com/remko/waforth does.

Yes, I understand that you can do anything with imports. But that's not part of the Wasm spec. That's a capability the host has decided to give the module. Of course the person with the most privilege can always open holes up, but that capability is not there by default.

Re: WASM Is the New CGI

#273

Post by jeberle »

flohofwoe wrote: post #269
jeberle wrote: post #227

Earlier quoted context omitted.

Thx for this perspective and info. Regarding "signedness and floating point that closer matches hardware", I'm not seeing unsigned integers. Are they supported? I see only: > Two’s complement signed integers in 32 bits and optionally 64 bits. https://webassembly.org/docs/portability/#assumptions-for-ef... And nothing suggesting unsigned ints here: https://webassembly.org/features/

Signed and unsigned are just different views on the same bits. CPU registers don't carry signedness either after all, the value they carry is neither signed nor unsigned until you look at the bits and decide to "view" them as a signed or unsigned number. With the two's complement convention, the concept of 'signedness' only matters when a narrow integer value needs to be extended to a wider value (e.g. 8-bit to 16-bi…

CPU instruction sets do account for signed vs unsigned integers. SHR vs SAR for example. It's part of the ISAs. I'm calling this out as AFAIK, the JVM has no support for unsigned ints and so that in turn makes WASM a little more compelling.

https://en.wikibooks.org/wiki/X86_Assembly/Shift_and_Rotate

Re: WASM Is the New CGI

#274

Post by bloppe »

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…

WebAssembly has a few things that set it apart:

- The security model (touched on by other comments in this thread)

- The Component Model. This is probably the hardest part to wrap your head around, but it's pretty huge. It's based on a generalization of "libraries" (which export things to be consumed) to "worlds" (which can both export and import things from a "host"). Component modules are like a rich wrapper around the simpler core modules. Having this 2-layer architecture allows far more compilers to target WebAssembly (because core modules are more general than JVM classes), while also allowing modules compiled from different ecosystems to interoperate in sophisticated ways. It's deceivingly powerful yet also sounds deceivingly unimpressive at the same time.

- It's a W3C standard with a lot of browser buy-in.

- Some people really like the text format, because they think it makes Wasm modules "readable". I'm not sold on that part.

- Performance and the ISA design are much more advanced than JVM.

Re: WASM Is the New CGI

#275

Post by therein »

thot_experiment wrote: post #260
therein wrote: post #89

Earlier quoted context omitted.

Did you run the output through wasm-opt? The size isn't terribly bad. I have a whole complex GUI with realtime charts, based on egui, under 4MB uncompressed. This includes three fonts and even some images.

Yeah no obviously the size of the stdlib is fixed so as your binary sizes grow it stops mattering. I'm curious why you're taking the approach you describe, I think compiling entire GUI apps to WASM is the absolute worst thing, so clearly you have a different set of constraints on your work.

Yeah very much different constraints. I would send a screenshot if I knew I could make it public because the results look spectacular. Rendering at 60 to 120FPS, perfectly smooth navigation, rendering even 10k OHLC candles without a hiccup.

Re: WASM Is the New CGI

#276

Post by anonu »

I like the thought. I also think about how Python losing the GIL. If we can write Python to WASM and maintain multi-threading, then the browser is sort of the new "Java JRE"... (to expand on the analogies)

Re: WASM Is the New CGI

#277

Post by 0x457 »

SkiFire13 wrote: post #32
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…

The replacement for those technologies is arguably javascript. WASM is more focused on performance by providing less abstractions and an instruction set closer to assembly (hence the name). The issue with those older technologies was that the runtime itself was a third-party external plugin you had to trust, and they often had various security issues. WASM however is an open standard, so browser manifacturers can dir…

> The replacement for those technologies is arguably javascript. WASM is more focused on performance by providing less abstractions and an instruction set closer to assembly (hence the name).

That is nonsense. WASM and JS have the exact same performance boundaries in a browser because the same VM runs them. However, WASM allows you to use languages where it's easier to stay on a "fast-path".

Re: WASM Is the New CGI

#278

Post by fastball »

kaba0 wrote: post #228
adamc wrote: post #198

Earlier quoted context omitted.

Also, the start-up time for the JVM made running applets very sluggish. Java quickly became a synonym for "slow".

You can’t just compare across decades of software and hardware development. Even downloading native binaries would have been sluggish, as the download would have been slow with those download speeds.

Isn't the cold-start for the JVM still relatively slow, even in [current year]?

EDIT: seems like yes[1], at least where AWS Lambda is concerned.

[1] https://filia-aleks.medium.com/aws-lambda-battle-2021-perfor...

Re: WASM Is the New CGI

#279

Post by conradev »

chubot wrote: post #231
tantalor wrote: post #209

> Amazon started the serverless age of compute with Lambda Google App Engine (2008) predates Lambda (2014) by 6 years!

Yeah also heroku and the whole generation of “PaaS” I was never quite sure why we got the name “serverless”, or where it came from, since there were many such products a few years before, and they already had a name App engine had both batch workers and web workers too, and Heroku did too They were both pre-docker, and maybe that makes people think they were different? But I think lambda didn’t launch with docker eit…

Serverless, to me, is purely about efficiency. One way to measure that is the time for a "cold start" or "going from a state where you pay no money to one where you pay money". These gains in efficiency remove the need for over-provisioning and in many cases allow you to pass these savings onto the consumer (if you want to).

Heroku is a few seconds:

> It only takes a few seconds to start a one-off dyno process or to scale up a web or worker process.

Lambda created Firecracker to be snappier:

> The duration of a cold start varies from under 100 ms to over 1 second.

I think App Engine is in the same ballpark as Lambda (and predated it). Fly.io uses Firecracker too:

> While Fly Machine cold starts are extremely fast, it still takes a few hundred milliseconds, so it’s still worth weighing the impact it has on performance.

but WASM is yet an order of magnitude faster and cheaper:

> Cloudflare Workers has eliminated cold starts entirely, meaning they need zero spin up time. This is the case in every location in Cloudflare's global network.

WASM is currently limited in what it can do, but if all you're doing is manipulating and serving HTML, it's fantastic at that.

Re: WASM Is the New CGI

#280

Post by thot_experiment »

therein wrote: post #275
thot_experiment wrote: post #260

Earlier quoted context omitted.

Yeah no obviously the size of the stdlib is fixed so as your binary sizes grow it stops mattering. I'm curious why you're taking the approach you describe, I think compiling entire GUI apps to WASM is the absolute worst thing, so clearly you have a different set of constraints on your work.

Yeah very much different constraints. I would send a screenshot if I knew I could make it public because the results look spectacular. Rendering at 60 to 120FPS, perfectly smooth navigation, rendering even 10k OHLC candles without a hiccup.

Don't worry I'm ok without having my eyes burned out by the lack of proper subpixel AA on your fonts. :P

10k candles at 120 fps seems like you could absolutely do it in JS alone, though I suppose the app came first and wanting to deploy it to end users via a webpage is an afterthought. Tbh writing performant JS for something like this isn't fun so despite my comments to the contrary you're probably making the right choice here.

Post reply on HN