251–260 of 311 posts
Earlier quoted context omitted.
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.
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…
> 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…
So, you could run a CGI script on a serverless platform, or a "serverful" one. You could even run it locally.
https://en.wikipedia.org/wiki/Serverless_computing
Per wikipedia: "Serverless is a misnomer in the sense that servers are still used by cloud service providers to execute code for developers. However, developers of serverless applications are not concerned with capacity planning, configuration, management, maintenance, fault tolerance, or scaling of containers, virtual machines, or physical servers."
Earlier quoted context omitted.
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.
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…
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.
You say that the web is portable, but really, only Google's vision for the web is relevant, seeing how they have the final say in how the standards are implemented and evolved.
So it's basically another walled garden, only much bigger and not constrained to the CPU architecture and OS kernel.
Chromium IS a platform. And indeed many applications that do work on Chrome don't work on Firefox. So we're pretty much back where we started, but the problem is harder to see because Chrome has such a monopoly over browsers that for most intents and purposes, and for most devs, it's the only platform that exists.
Everyone is good at multiplat when there's only one plat.
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.
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…
But pedantically, serverless is to be taken literally. It implies that there is no server in your application.
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…
For all intents and purposes, when is the hardware not fully abstracted away? Even through the 2010s when running as a server was the norm, for the most part you could throw the same code onto basically any hardware without a second thought. But pedantically, serverless is to be taken literally. It implies that there is no server in your application.
Earlier quoted context omitted.
For all intents and purposes, when is the hardware not fully abstracted away? Even through the 2010s when running as a server was the norm, for the most part you could throw the same code onto basically any hardware without a second thought. But pedantically, serverless is to be taken literally. It implies that there is no server in your application.
EC2 and managed kubernetes are two examples where you still have to think about hardware.
Earlier quoted context omitted.
For all intents and purposes, when is the hardware not fully abstracted away? Even through the 2010s when running as a server was the norm, for the most part you could throw the same code onto basically any hardware without a second thought. But pedantically, serverless is to be taken literally. It implies that there is no server in your application.
EC2 and managed kubernetes are two examples where you still have to think about hardware.
The move away from CGI/FastCGI/SCGI to the application being the server was a meaningful shift in how web applications were developed. Now that we've started adopting the server back out of the application in favour of the process-based model again, albeit now largely through propriety protocols instead of a standard like CGI, serverless has come into use in recognition of that. We don't want to go back to calling it CGI because CGI is no longer the protocol du jour.
Earlier quoted context omitted.
ngl I've tried using Rust -> WASM and it's been an awful experience, I'm much much happier with C. Rust generates enormous blobs because you have to include stdlib, and if you don't you don't get any of the benefits of using Rust. I'm probably overrotating on binary size but it sure is nice being able to just read the WASM and make sense of it, which is generally the case for WASM made from C and is absolutely not th…
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.
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.