WASM Is the New CGI • Hacker News Board

Re: WASM Is the New CGI

#261

Post by chubot » Thu, Oct 10, 2024, 5:09 PM UTC

bloppe wrote: post #252

randomdata wrote: post #249

Earlier quoted context omitted.

> I was never quite sure why we got the name “serverless”, or where it came from Serverless refers to the software not being a server (usually implied to be a HTTP server), as was the common way to expose a network application throughout the 2010s, instead using some other process-based means to see the application interface with an outside server implementation. Hence server -less . It's not a new idea, of course. G…

Pedantry police here. I would define serverless to mean that all the hardware is completely abstracted away. For instance, on EC2, you have to pick an instance type. You pick how much memory and compute you need. On a managed kuberenetes cluster, you still have to think about nodes. On a serverless platform, though, you have no idea how many computers or what kinds of computers are actually running your code. It just…

FWIW I agree with you -- serverless does not refer to "web server", it refers to "linux server machine" (whether it's physical or virtual)

You don't care about the specific machine, the OS kernel, the distro, the web server, or SSL certificates when you're doing "serverless"

And the SAME was true of "PaaS"

This whole subthread just proves that the cloud is a mess -- nobody knows what "serverless" is or that App Engine / Heroku already had it in 2008 :)

Re: WASM Is the New CGI

#262

Post by bloppe » Thu, Oct 10, 2024, 5:11 PM UTC

chubot wrote: post #261

bloppe wrote: post #252

Earlier quoted context omitted.

Pedantry police here. I would define serverless to mean that all the hardware is completely abstracted away. For instance, on EC2, you have to pick an instance type. You pick how much memory and compute you need. On a managed kuberenetes cluster, you still have to think about nodes. On a serverless platform, though, you have no idea how many computers or what kinds of computers are actually running your code. It just…

FWIW I agree with you -- serverless does not refer to "web server", it refers to "linux server machine" (whether it's physical or virtual) You don't care about the specific machine, the OS kernel, the distro, the web server, or SSL certificates when you're doing "serverless" And the SAME was true of "PaaS" This whole subthread just proves that the cloud is a mess -- nobody knows what "serverless" is or that App Engin…

I agree the "serverless" is not a good name. But hey, it stuck :/

I also can't come up with one that's significantly better.

Re: WASM Is the New CGI

#263

Post by mdhb » Thu, Oct 10, 2024, 5:12 PM UTC

ewoodrich wrote: post #250

themoonisachees wrote: post #190

Earlier quoted context omitted.

It is not my intention to be contrarian, but honestly this might be the most incorrect comment I've ever read on hacker news, in several different ways. Sure, some of these might be subjective, but for example chromeOS is Linux with a shiny coat in top, how could it be any better than, well, Linux, let alone miles ahead?

ChromeOS uses the Linux kernel but unless you enable developer mode (which has multiple levels of scary warnings including on every boot and requires completely wiping the device to enable) everything runs in the Chrome web sandbox or the Android VM. A ChromeOS user isn't apt-get installing binaries or copy/pasting bash one liners from Github. If you enable the Linux dev environment, that also runs in an isolated VM…

Even when you enable “developer mode” which is essentially Debian in a VM the level of care that went into making sure that no matter what happens there you will never suffer a full system compromise is truly impressive.

To give you a sense of where they were half a decade ago you can already see that it’s as I described miles in front of anything that exists even today in this video: https://youtu.be/pRlh8LX4kQI

When we get to talking about when they went for a total ground up first principles approach with Fuchsia as a next generation operating system that is something else entirely on a different level again.

I genuinely didn’t have a hint of irony in my original comment. They are actually that much better when it comes to security.

Re: WASM Is the New CGI

#264

Post by jauntywundrkind » Thu, Oct 10, 2024, 5:12 PM UTC

VyseofArcadia wrote: post #184

jauntywundrkind wrote: post #161

Earlier quoted context omitted.

I've already mentioned ChromeOS as one counter-example. SerenityOS and Ladybird browser forked but until recently had a lot of overlap. LG's WebOS is used on a range of devices, derived from the Palm Pre WebOS released in 2009. The gigantic special OS is baggage which already has been cut loose numberous times. Yes you can run some fine light Linux OS'es in 4GB but man, having done the desktop install for gnome or kd…

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 complainy world. This is a diseased view, is reprehensible small minded & aggressively mean, and it's absurd given how much incredibly effort has been poured into making HTML and CSS incredibly capable competent featureful fast systems, for shame: torturing a poor, overburdened document display engine into pretending it's a sane place for apps to run

The web has a somewhat earned reputation for being overwhelmed by ads, which slow things down, but today it feels like most native mobile apps are 60MB+ and also have burdensome slow ads too.

There aren't really any tries to go full in on the web. We have been kind of a second system half measure, for the most part, since Pre WebOS gave up on mobile (since FirefoxOS never really got a chance). Apps have had their day and I'm fine with there being offerings for those with a predeliction for prehistoric relics, but the web deserves a real full go, deserves a chance too, and the old salty grudges and mean spirits shouldn't obstruct the hopeful & the excited who have pioneered some really great tech that has both become the most popular connected ubiquitous tech on the planet, but which is also still largely a second system and not the whole of the thing.

The web people are always hopeful & excited & the native app people are always overbearingly negative nellies, old men yelling at the cloud. Yeah, there's some structural issues of power around the cloud today, but as Molly White's recent XOXO talk says, the web is still the most powerful system that all humanity shares that we can use to enrich ourselves however we might dream, and I for one feel great excitement and energy, that this is the only promise I see right now that shows open potential. (I would be overjoyed to see native apps show new promise but they feel tired & their adherents to be displeasurable & backwards looking) https://www.youtube.com/watch?v=MTaeVVAvk-c

Re: WASM Is the New CGI

#265

Post by randomdata » Thu, Oct 10, 2024, 5:18 PM UTC

chubot wrote: post #261

bloppe wrote: post #252

Earlier quoted context omitted.

Pedantry police here. I would define serverless to mean that all the hardware is completely abstracted away. For instance, on EC2, you have to pick an instance type. You pick how much memory and compute you need. On a managed kuberenetes cluster, you still have to think about nodes. On a serverless platform, though, you have no idea how many computers or what kinds of computers are actually running your code. It just…

FWIW I agree with you -- serverless does not refer to "web server", it refers to "linux server machine" (whether it's physical or virtual) You don't care about the specific machine, the OS kernel, the distro, the web server, or SSL certificates when you're doing "serverless" And the SAME was true of "PaaS" This whole subthread just proves that the cloud is a mess -- nobody knows what "serverless" is or that App Engin…

> it refers to "linux server machine" (whether it's physical or virtual)

No, "server" most definitely refers to software that listens for network requests. Colloquially, hardware that runs such software is often also given the server moniker ("the computer running the server" is a mouthful), but that has no applicability within the realm of discussion here. If you put the user in front of that same computer with a keyboard and mouse controlling a GUI application, it would no longer be considered a server. We'd call it something like a desktop. It is the software that drives the terminology.

> nobody knows what "serverless" is or that App Engine / Heroku already had it in 2008 :)

Hell, we were doing serverless in the 90s. You uploaded your CGI script to the provider and everything else was their problem.

The difference back then was that everyone used CGI, and FastCGI later on, so we simply called it CGI. If you are old enough to recall, you'll remember many providers popped up advertising "CGI hosting". Nowadays it is a mishmash of proprietary technologies, so while technically no different than what we were doing with CGI back in the day, it isn't always built on literal CGI. Hence why serverless was introduced as a more broad term to capture the gamut of similar technologies.

Re: WASM Is the New CGI

#266

Post by consteval » Thu, Oct 10, 2024, 5:19 PM UTC

VyseofArcadia wrote: post #222

consteval wrote: post #206

Earlier quoted context omitted.

The Web is portable, operating systems are not. Windows and Mac, being short-sighted, did this to themselves. Nobody can agree on anything, Microsoft is constantly deprecating UI frameworks, and it's not convenient at all to write local apps. It's only JUST NOW we have truly portable UI frameworks. And it's only because of the Web.

QT has been around for decades. So has GTK. Bindings for whatever language you could possibly want. Runs on whatever OS you want. We've had "truly portable" UI frameworks since the late 90s. This has not been an issue for my entire adult life. 20 years ago, I was using desktop applications that ran on Mac OS X, Windows, and *nix with no modifications. They were written in Python, used GTK, and just worked. Web apps a…

Even those are not portable because they don't target the #1 personal computer in use - smart phones.

Re: WASM Is the New CGI

#267

Post by titzer » Thu, Oct 10, 2024, 5:22 PM UTC

flohofwoe wrote: post #182

torginus wrote: post #177

Earlier quoted context omitted.

PNacl also had the same sandboxing requirement, yet had many of the features still missing today from WAsm (threads, 3d graphics API support, access to other native APIs), and it didn't suffer from slow startup times. It had pretty nice and quick uptake considering the tooling was very similar to native toolchains. According to this benchmark (first Google result I found), it was even faster: https://apryse.com/blog/…

I had been working both with NaCl and PNaCl back then, and truth be told, once Google made the switch from NaCl to PNaCl most advantages just disappeared. The compilation of the PNaCl bytecode on start (which was more or less just a subset of LLVM IR) took longer than even the first WASM implementations. PNaCl definitely suffered hard from slow startup times because it ran LLVM for compilation from PNaCl bytecode to…

It's also worth noting that the NaCl and PNaCl teams were integrated into a large Wasm team at Google and brought their expertise to the project. While we didn't all 100% agree on every decision made in Wasm design, we were intimately familiar with the tradeoffs made by those prior projects.

Ultimately the sandboxing requirement of running in-process with the renderer process and integrating with Web APIs like JS dictated hard requirements for security.

Re: WASM Is the New CGI

#268

Post by mshockwave » Thu, Oct 10, 2024, 5:23 PM UTC

kaba0 wrote: post #145

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 think the first approach gives a lot more room for the host to create optimizations, to the point we could see hardware with custom instructions to make WASM faster Heh, there were literally CPUs with some support for the JVM! But it turns out that “translating” between different forms is not that expensive (and can be done ahead of time and cached), given that CPUs already use a higher level abstraction of x86/a…

> Heh, there were literally CPUs with some support for the JVM!

Jazelle, a dark history that ARM never wants to mention again

Re: WASM Is the New CGI

#269

Post by flohofwoe » Thu, Oct 10, 2024, 5:25 PM UTC

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/

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-bit), specifically whether the new bits needs to be replicated from the narrow value's topmost bit (for signed extension) or set to zero (for unsigned extension).

It would be interesting to speculate what a high level language would look like with such sign-agnostic "Schroedinger's integer types").

Re: WASM Is the New CGI

#270

Post by ranger_danger » Thu, Oct 10, 2024, 5:27 PM UTC

pajamaboin wrote: post #20

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…

This article is about WASM on the server so to answer your question it's different because it's not pushing computational cost from the server to the client. It can, but it doesn't in all cases. That's a huge difference. Others have already commented others (better sandboxing, isolation, etc)

It's amazing how many people don't actually read the article and just start commenting right away. It's like leaving bad amazon reviews for products you haven't purchased.