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

301–310 of 311 posts

Re: WASM Is the New CGI

#301

Post by 01HNNWZ0MV43FF »

nox101 wrote: post #243
tightbookkeeper wrote: post #199

Earlier quoted context omitted.

Flash/applets could have been isolated in a process too, right?

yes but no, because they needed access to the OS for various services, all of which would have had to be isolated from the user code. Sun and Adobe woiod never have done this. Chrome did it, Safari and Firefox followed. WASM runs in that environment. Flash/applets ran outside of that environment. they did that precisely to provide services the broswer didn't back then.

Chrome did put a sandbox around Flash, didn't they? I thought the bigger reasons it died out was that it didn't integrate with DOM and Apple hated it

Re: WASM Is the New CGI

#302

Post by tightbookkeeper »

IshKebab wrote: post #290
tightbookkeeper wrote: post #208

Earlier quoted context omitted.

But that’s missing a few steps. First they banned all those technologies saying JavaScript was sufficient, then only later made wasm. There never was a wasm vs applet debate.

Nobody banned Flash. Apple just sensibly didn't implement it, because it was shit on phones. Android did support Flash and the experience was awful .

They sure banned Java Applets.

> Nobody banned Flash.

What happened first? Chrome dropping support for flash, or flash stopped making updates?

Re: WASM Is the New CGI

#303

Post by afiori »

TekMol wrote: post #118
jamil7 wrote: post #115

Earlier quoted context omitted.

Not really because then you need a JS environment everywhere you want to run your code. If I write a Rust module I have the possibility to compile to WASM or machine code. This is what I meant in my other comment, your assumption is everyone is making browser apps in Javascript that don't have any performance or resource constraints.

possibility to compile to WASM or machine code How is this better than "possibility to compile to JS or machine code"?

There are significantly more (and more varied) wasm runtimes than js runtimes.

Re: WASM Is the New CGI

#304

Post by iforgotpassword »

kaba0 wrote: post #157
iforgotpassword wrote: post #41

Earlier quoted context omitted.

That's a bit oversimplified. I had this thought too and tried to figure out why this is different, and I think there are some major points. The biggest one is in which order they were built and designed. If we take Java and ask why applets didn't take off since they could do everything WASM offers and more, two things come to mind: it was fucking slow on contemporary machines, and the gui framework sucked. WASM is th…

Wasm is more open, because we effectively have 1.5 browsers left, and whatever google decides will be the de facto “web standard” everyone should follow. If google were pushing for a slightly revamped jvm/applet model, that would be the standard (as the JVM is as open/standardized as it gets)

I don't buy it. WAS is still open from the start, and incredibly more simple and thus easier to implement securely.

And no, for reasons stated before an applet model would never become the standard again. You'd rather have to integrate Java with the browser so it's entirely under your control, and considering how massive it is and how hard it was to properly sandbox it, nobody in their right mind would decide on this. WASM reuses a lot of infrastructure already there, it's simply the best solution from a technical standpoint.

Re: WASM Is the New CGI

#305

Post by friendzis »

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 is indeed a weird name if you know what you are talking about. I was dumbfounded by the term until I met people who actually thought of anything beyond pushing to git as "the server".

Backend returns 4xx/5xx? The server is down. Particular data is not available in this instance and app handles this error path poorly? The server is down. There is no API to call for this, how do I implement "the server"?

Some people still hold the worldview that application deployment is similar to mod-php where source files are yoloed to live filesytem. In this worldview, ignorant of complexities in operations, serverless is perfectly fitting marketing term, much like Autopilot, first chosen by Musk, chef's kiss.

Re: WASM Is the New CGI

#306

Post by randomdata »

friendzis wrote: post #305
chubot wrote: post #231

Earlier quoted context omitted.

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 is indeed a weird name if you know what you are talking about. I was dumbfounded by the term until I met people who actually thought of anything beyond pushing to git as "the server". Backend returns 4xx/5xx? The server is down. Particular data is not available in this instance and app handles this error path poorly? The server is down. There is no API to call for this, how do I implement "the server"? Som…

> Serverless is indeed a weird name if you know what you are talking about.

It is a perfectly logical name if you know what you are talking about and are familiar with the history of how these so-called serverless applications used to be developed.

Which is to say that back in the day, once CGI fell out of fashion, the applications became servers themselves. You would have a listening HTTP server right within the application, often reverse proxied through something like Apache or nginx, and that is how it would be exposed to the world. The downside of this model is that your application always needs to be resident in order to serve requests, and, from a scaling perspective, you need to predict ahead of time many server instances are needed to handle the request load. This often resulted in poor resource utilization.

Now with a return to back to the CGI-esq model, where you have managing servers call upon the application through a process-based execution flow, albeit no longer using CGI specifically, the application is no longer the server again. This allows systems to save on resources by killing off all instances of your application when no requests are happening, and, with respect to scalability, it gives the freedom to the system the ability to launch as many instances of your application as is required to handle the load when the requests start coming in.

Hence, with the end of the application being the server under the adoption of said process-based model, the application became serverless.

> I was dumbfounded by the term

The marketers have certainly tried to usurp the term for other purposes. It seems just about everything is trying to be called "serverless" nowadays. Perhaps that is the source of your dumbfoundary? Then again, if you know what you are talking about then you know when marketers are blowing smoke, so...

Re: WASM Is the New CGI

#307

Post by Vilian »

cogman10 wrote: post #288
DanielHB wrote: post #110

Earlier quoted context omitted.

> WASM proved to be secure and JVM did not. It is interesting to ask why that is the case, from my point of view the reason is that the JVM standard library is just too damn large. While WASM goes on a lower-level approach of just not having one. To make WASM have the capabilities required the host (the agent running the WASM code) needs to provide them. For a lot of languages that means using WASI, moving most of th…

I'll just add one thing here, WASM's platform access is VERY small. There's almost no runtime associated with WASM and thus no guarantees to what WASM can access. When you throw WASM into the browser, it's access to the outside world is granted by the javascript container that invokes it. That's very different compared to how other browser extensions operated. The old browser extensions like the JVM or flash were lit…

Wht can't wasm have it own invoker, instead of relying on javascript?

Re: WASM Is the New CGI

#308

Post by nox101 »

kaba0 wrote: post #293
nox101 wrote: post #246

Earlier quoted context omitted.

yes you're missing something. Java applets and flash outside of any security and they ran the users code in that insecure environment WASM, in broswers, runs entirely inside a secure environment with no access to the system. js->browser->os | +--Flash/java-->os vs wasm->browser->os further. WASM and Js are in their own process with no os acesss. they can't access the os except by rpc to the broswer flash/java tho, ra…

Seems like a trivial thing to fix though, it was a lack of will over an explicit design tradeoff. At Applet’s time there was simply no such API surface to attach to and make useful programs.

it's not a trivial thing to fix. It took apple, Mozilla, and google years to refsctor their broswers to isolate user code in its own process and then effiently ipc all services to other processes.

chrome started with that but also started without GPU based graphics and spent 2-3 years adding yet another process make it possible. mozilla and safari took almost 10 years to catch up.

Re: WASM Is the New CGI

#309

Post by empthought »

eduction wrote: post #242
norswap wrote: post #213

Earlier quoted context omitted.

> WASM proved to be secure and JVM did not. This is an oversimplification — there's nothing about the JVM bytecode architecture making it insecure. In fact, it is quite simpler as an architecture than WASM. Applets were just too early (you have to remember what the state of tech looked like back then), and the implementation was of poor quality to boot (owing in part to some technical limitations — but not only). But…

> back then the landscape was Internet Explorer 6 vs the very marginal Mozilla Your timeline is off by about five years. Java support shipped with Netscape Navigator 2 in 1995, and 95/96/97 is when Java hype and applet experimentation peaked. Netscape dominated this era. IE6 wouldn’t come out until 2001 and IE share generally wouldn’t cross 50% until 2000 https://en.m.wikipedia.org/wiki/File:Internet-explorer-usage..…

ActiveX and Macromedia Flash were also popular alternatives to Java applets. Until v8 and Nitro were available, browser-based JavaScript was not a credible option for many apps.

Re: WASM Is the New CGI

#310

Post by flohofwoe »

jeberle wrote: post #273
flohofwoe wrote: post #269

Earlier quoted context omitted.

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

Yes some instructions do - but surprisingly few (for instance there's signed/unsigned mul/div instructions, but add/sub are 'sign-agnostic'). The important part is that any 'signedness' is associated with the operation, and not with the operands or results.
Post reply on HN