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

281–290 of 311 posts

Re: WASM Is the New CGI

#281

Post by throwaway313373 »

> The Rack web server interface from the Ruby community eventually made into python via the Flask application server and the WSGI specification.

It's amazing how just one sentence can be so utterly wrong.

WSGI actually predates rack by several years: first WSGI spec was published in 2003 [0], rack was split from Rails in 2007 [1].

Flask is not an "application server", it is one of the web frameworks that implements WSGI interface. Another popular framework that also implements it is Django. Flask is not the first WSGI implementation, so I'm not sure why author decided to mention Flask specifically. It's probably one of the most popular WSGI implementations but there is nothing special about it, it hasn't introduced any new concepts or a new paradigm or anything like that.

I'm not sure if the rest of the article is even worth reading if the author can't even get the basic facts right but for some reason feels the need to make up total nonsense in their place.

[0] https://peps.python.org/pep-0333/

[1] https://github.com/rack/rack/blob/main/CHANGELOG.md

Re: WASM Is the New CGI

#282

Post by kaba0 »

adamc wrote: post #241
kaba0 wrote: post #228

Earlier quoted context omitted.

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.

But web pages were not so sluggish, hence people chose them over using applets.

Web pages at the time could at most , its interactivity was extremely limited compared to what we have know. Meanwhile a java applet could include a full-blown IDE/CAD/what have you

Re: WASM Is the New CGI

#283

Post by duped »

bloppe wrote: post #274
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…

> This is probably the hardest part to wrap your head around, but it's pretty huge.

It's just an IDL, IDL's have been around a long time and have been used for COM, Java, .NET, etc.

Re: WASM Is the New CGI

#284

Post by nobleach »

fastball wrote: post #278
kaba0 wrote: post #228

Earlier quoted context omitted.

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...

I have a couple Quarkus apps that I've run in Lambdas that start in about a second. This is without using GraalVM too! Good enough for what I was doing (taking a list of file names, finding them in an S3 bucket and zipping them into a single payload)

Re: WASM Is the New CGI

#285

Post by tsimionescu »

pjmlp wrote: post #229
tsimionescu wrote: post #196

Earlier quoted context omitted.

It's not the same thing though. All of these languages have specific constructs for integrating with the CLR, the CLR is not just a compilation target like WASM is. C++/CLR even has a fourth kind of variable compared to base C++ (^, managed references of a type, in addition to the base type, * pointers to the type, and & references to the type). IronPython has not had a GIL since its early days. I'm sure the others h…

As if WebAssembly doesn't impose similar restrictions, with specific kinds of toolchains, and now the whole components mess. This WebAssembly marketing is incredible.

Are there any examples of how, say, C++ compiled for WASM is different from native C++, or Python on WASM vs CPython? I haven't really used or cared about WASM, so I'm happy to learn, I don't have some agenda here.

Re: WASM Is the New CGI

#286

Post by VyseofArcadia »

jauntywundrkind wrote: post #264
VyseofArcadia wrote: post #184

Earlier quoted context omitted.

I for one don't want to use web apps. I want the speed, convenience, and availability of native apps. I want to use applications that work if the internet isn't. I want to use applications that store my data locally. I want to use unglamorous applications that just work and use a native GUI toolkit instead of torturing a poor, overburdened document display engine into pretending it's a sane place for apps to run. Not…

These are all the views of a fossil. Maybe some truth, historically, but years out of date. Want an offline app? Possible for a long time, build a local-first app. Don't want to build a client-server system? Fine, build an isolated webapps. There's so many great tools for webdev that get people going fast, that are incomparably quick at throwing something together. It's just bias and ignorance of an old crusty compla…

These are all the views of someone who is hopelessly naive. Maybe some truth, but ignorant of where we came from and how we got here. This is a diseased view, is reprehensible, small minded, and aggressively mean, and it's absurd given how much complexity has been poured into making computers do simple things in the most complex way possible.

My man, I am not a fossil. I came of age with web apps. But I am someone who has seen both sides. I have worked professionally on both desktop applications and as a full stack web developer, and my informed takeaway is web apps are insane. Web dev is a nightmarish tower of complexity that is antithetical to good engineering practice, and you should only do it if you are working in a problem space that is well and truly web-native.

I try to live by KISS, and nontrivial web apps are not simple. A couple of things to consider:

1. If it is possible to do the same task with a local application, why should I instead do that task with a web app that does everything in a distributed fashion? Unnecessary distributed computing is insane.

2. If it is possible to do the same task with a local application, and as a single application, not client-server, why should I accept the overhead of running it in a browser? Browsers are massive, complex, and resource hungry. Sure, I'll just run my application inside another complex application inside a complex OS. What's another layer? But actually, raw JS, HTML, and CSS are too slow to work with, so I'll add another layer and do it with React. But actually, React is also too slow to work with, so I'll add another layer and do it with Next.js. That's right, we've got frameworks inside of frameworks now. So that's OS -> GUI library -> browser -> framework -> framework framework -> application.

3. The world desperately needs to reduce its energy consumption to reduce the impact of climate change. If we can make more applications local and turn off a few servers, we should.

I am not an old man yelling at the cloud. I am a software engineer who cares deeply about efficient, reliable software, and I am begging, pleading for people to step back for a second and consider whether a simpler mode of application development is sufficient for their needs.

Re: WASM Is the New CGI

#287

Post by dartos »

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…

When lambda came out and serverless started getting big, most scrappy startups hired many frontend devs.

It was the heydays of SPAs, light backends, and thick frontends.

“Serverless” is a great way to say “you don’t need to be a backend dev or even know anything about backend to deploy with us”

And it worked really really well.

Then people realized that they should know a thing or two about backend.

I always really hated that term.

Re: WASM Is the New CGI

#288

Post by cogman10 »

DanielHB wrote: post #110
vbezhenar wrote: post #59

Earlier quoted context omitted.

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…

> 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 literally the browser calling into a binary blob with full access to the whole platform.

That is why the WASM model is secure vs the JVM model. WASM simply can't interact with the system unless it is explicitly given access to the system from the host calling it. It is even more strictly sandboxed than the Javascript engine which is executing it.

Re: WASM Is the New CGI

#289

Post by [deleted] »

nobleach wrote: post #284
fastball wrote: post #278

Earlier quoted context omitted.

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...

I have a couple Quarkus apps that I've run in Lambdas that start in about a second. This is without using GraalVM too! Good enough for what I was doing (taking a list of file names, finding them in an S3 bucket and zipping them into a single payload)

[deleted]

Re: WASM Is the New CGI

#290

Post by IshKebab »

tightbookkeeper wrote: post #208
IshKebab wrote: post #38

Earlier quoted context omitted.

ActiveX wasn't sandboxed so it was a security joke. Flash and Silverlight were full custom runtimes that a) only worked with a specific language, and b) didn't integrate well with the existing web platform. WASM fixes all of that.

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.
Post reply on HN