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

231–240 of 311 posts

Re: WASM Is the New CGI

#231

Post by chubot »

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 either

Re: WASM Is the New CGI

#232

Post by thomastjeffery »

layer8 wrote: post #224

To expand the premise in the title, to be a true heir to that lineage, I would say that WASM needs to be as easy to host and deploy as PHP applications are (or used to be) on the LAMP stack of any random hosting provider. I suspect that’s not quite the case yet?

WASM runs on the browser.. What about hosting do you expect to be different?

Re: WASM Is the New CGI

#233

Post by EasyMark »

vbezhenar wrote: post #59
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 fr…

What would you say is the performance difference between say running a qt app as native compiled vs running it in WASM? I’ve always been curious but never tried. I know it would vary based on the application but I’m guessing something that is maybe calculating some Monte Carlo model and then displaying the result or something else along those lines that actually will max out the CPU at times rather than be waiting on human interaction 99%of the time.

Re: WASM Is the New CGI

#234

Post by tmpz22 »

thomastjeffery wrote: post #232
layer8 wrote: post #224

To expand the premise in the title, to be a true heir to that lineage, I would say that WASM needs to be as easy to host and deploy as PHP applications are (or used to be) on the LAMP stack of any random hosting provider. I suspect that’s not quite the case yet?

WASM runs on the browser.. What about hosting do you expect to be different?

A more accessible toolchain for complete beginners.

PHP was literally copy/past code snippets into a file and then upload it to a hosting provider.

I don't build for WASM but I'll bet the money in my pocket to a charity of your choice that its harder for a beginner.

Re: WASM Is the New CGI

#235

Post by fmajid »

thomastjeffery wrote: post #232
layer8 wrote: post #224

To expand the premise in the title, to be a true heir to that lineage, I would say that WASM needs to be as easy to host and deploy as PHP applications are (or used to be) on the LAMP stack of any random hosting provider. I suspect that’s not quite the case yet?

WASM runs on the browser.. What about hosting do you expect to be different?

Like Java and JavaScript before it, WASM can also run on Kubernetes clusters and plenty of other non-browser contexts.

Re: WASM Is the New CGI

#236

Post by layer8 »

thomastjeffery wrote: post #232
layer8 wrote: post #224

To expand the premise in the title, to be a true heir to that lineage, I would say that WASM needs to be as easy to host and deploy as PHP applications are (or used to be) on the LAMP stack of any random hosting provider. I suspect that’s not quite the case yet?

WASM runs on the browser.. What about hosting do you expect to be different?

The article is about WASM on the server, hence the analogy to CGI(-bin) in the title.

Re: WASM Is the New CGI

#237

Post by tombl »

bhelx wrote: post #187
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…

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.

Re: WASM Is the New CGI

#238

Post by noworriesnate »

jmull wrote: post #193
moi2388 wrote: post #67

Earlier quoted context omitted.

> 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

I thought the problem was the hefty upfront price to pay for loading the runtime.

There's some truth to this, but there's a new way of rendering components on the server and pushing that HTML directly to the browser first. The components render but aren't fully interactive until the WASM comes in. It can make it feel snappy if it doesn't take too long to load the WASM.

Re: WASM Is the New CGI

#239

Post by ndiddy »

igrunert wrote: post #220
kgeist wrote: post #103

Earlier quoted context omitted.

Btw, is WASM really more secure? JVM and .NET basically have capability-based security thanks to their OOP design together with bytecode verification: if you can't take a reference to an object (say, there's a factory method with a check), you can't access that object in any way (a reference is like an access token). As far as I understand, in WASM memory is a linear blob, so if I compile C++ to WASM, isn't it possib…

When discussing security it's important to keep in mind the threat model. We're mostly concerned with being able to visit a malicious site, and execute wasm from that site without that wasm being able to execute arbitrary code on the host - breaking out of the sandbox in order to execute malware. You say the only benefit is that access to the OS is isolated, but that's the big benefit. Having said that, WebAssembly h…

The downside of WASM programs not being able to see the call stack is that it makes it impossible to port software that uses stackful coroutines/fibers/whatever you want to call them to WASM, since that functionality works by switching stacks within the same thread.

Re: WASM Is the New CGI

#240

Post by Laremere »

jeberle wrote: post #227
titzer wrote: post #129

Earlier quoted context omitted.

I worked on JVM bytecode for a significant number of years before working on Wasm. JVM bytecode verification is non-trivial, not only to specify, but to implement efficiently. In Java 6 the class file format introduced stack maps to tame a worst-case O(n^3) bytecode verification overhead, which had become a DoS attack vector. Structured control flow makes Wasm validation effectively linear and vastly simpler to under…

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/

Wasm makes no distinction between signed and unsigned integers as variables, only calling them integers. The relevant operations are split between signed and unsigned.

https://webassembly.github.io/spec/core/appendix/index-instr...

See how there's only i32.load and i32.eq, but there's i32.lt_u and i32.lt_s. Loading bits from memory or comparing them is the same operation bit for bit for each of signed and unsigned. However, less than requires knowing the desired signess, and is split between signed and unsigned.

Post reply on HN