18 ms·

WASM Is the New CGI

258 points by burglins 2y ago

tantalor 2y ago
> Amazon started the serverless age of compute with Lambda Google App Engine (2008) predates Lambda (2014) by 6 years!
- chubot 2y ago
  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
  - Uehreka 2y ago
    PaaS, Containerization and Serverless are different concepts. App Engine is PaaS: You provide your app to the service in a runnable form (maybe a container image, maybe not) and they spin up a dedicated server (or slice of a server) to run it continuously. Lambda is Serverless: You provide them a bit of code and a condition under which that code should run. They charge you only when that thing happens and the code runs. How they make that happen (deploy it to a bajillion servers? Only deploy it when it’s called?) are implementation details that are abstracted from the user/developer as long as Lambda makes sure that the code runs whenever the condition happens. So with PaaS you have to pay even if you have 0 users, and when you scale up you have to do so by spinning up more “servers” (which may result in servers not being fully utilized). With Serverless you pay for the exact amount of compute you need, and 0 if your app is idle.
    - chubot 2y ago
      > They charge you only when that thing happens and the code runs. That's how App Engine worked in 2008, and it looks like it still works that way: https://cloud.google.com/appengine/pricing https://cloud.google.com/appengine/pricing Apps running in the flexible environment are deployed to virtual machine types that you specify. These virtual machine resources are billed on a per-second basis with a 1 minute minimum usage cost. This applied to both the web workers and the batch workers It was "serverless" in 2008! > spin up a dedicated server (or slice of a server) to run it continuously. Absolutely NOT true of App Engine in 2008, and I'm pretty sure Heroku in 2008 too!
    - tantalor 2y ago
      I recall you could configure app engine with maximum number of instances you wanted, but you definitely weren't charged if usage was 0. They would start the instances as needed. The fact that lambda would automatically scale to meet whatever QPS you got sounds terrifying.
  - randomdata 2y ago
    > 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. Good old CGI is serverless, but CGI defines a specific protocol whereas serverless refers to a broad category of various implementations.
    - bloppe 2y ago
      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 runs when it needs to. Of course there's still an HTTP server somewhere, though. 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 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."
      - randomdata 2y ago
        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.
        bloppe 2y ago
        EC2 and managed kubernetes are two examples where you still have to think about hardware.
  - conradev 2y ago
    Serverless, to me, is purely about efficiency. One way to measure that is the time for a "cold start" or "going from a state where you pay no money to one where you pay money". These gains in efficiency remove the need for over-provisioning and in many cases allow you to pass these savings onto the consumer (if you want to). Heroku is a few seconds: > It only takes a few seconds to start a one-off dyno process or to scale up a web or worker process. Lambda created Firecracker to be snappier: > The duration of a cold start varies from under 100 ms to over 1 second. I think App Engine is in the same ballpark as Lambda (and predated it). Fly.io uses Firecracker too: > While Fly Machine cold starts are extremely fast, it still takes a few hundred milliseconds, so it’s still worth weighing the impact it has on performance. but WASM is yet an order of magnitude faster and cheaper: > Cloudflare Workers has eliminated cold starts entirely, meaning they need zero spin up time. This is the case in every location in Cloudflare's global network. WASM is currently limited in what it can do, but if all you're doing is manipulating and serving HTML, it's fantastic at that.
  - dartos 2y ago
    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.
  - friendzis 2y ago
    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.
    - randomdata 2y ago
      > 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...
smolder 2y ago
I kind of like this variety of headline for it's ability to stimulate discussion but it's also nonsense. CGI can be any type of code responding to an individual web request, represented as a set of parameters. It has basically nothing to do with wasm which is meant to be a universal code representation for a universal virtual machine. Have I missed something?
- waynecochran 2y ago
  The use of wasm makes sense to me in context of the article.
  - smolder 2y ago
    The article does not seem to support the title. You'll have to show me how it does. 'serverless' is a wholly different concept that doesn't have much to do with wasm. You could say it's CGI as a service, but that has nothing to do with wasm.
    - svieira 2y ago
      It's quite buried amid a lot of extra paragraphs expositing about WASM and the future of serverless functions in general, but the article does contain this quote: > One of the many effect of how [WASM] modules are isolated is that you can "pause" a module, and save its memory as a data segment. A similar concept to a Snapshot of a virtual machine. You can then start as many copies of the paused module as you like. (As I tell friends, it's like saving your game in an emulator.) > The snapshotted module has no extra startup time ... > If we go back to thinking about our Application Server models; this allows us to have a fresh process but without paying the startup costs of a new process. Essentially giving us CGI without the downsides of CGI. Or in more recent terms, serverless without cold starts. This is how Wasm is the new CGI.
      - smolder 2y ago
        This is not like CGI. Calling it "the new CGI" seems to me like a way to confuse people, since CGI was a response to individual requests and carrying state across requests was always extra work. None of this has to do with WASM in particular.
rpcope1 2y ago
So basically we're reinventing the JVM and it's ecosystem?
- pjmlp 2y ago
  Yeah, by folks that most likely used to bash Application Servers from early 2000's. Not only JVM, also CLR, BEAM, P-Code, M-Code, and every other bytecode format since UNCOL came to be in 1958, but lets not forget about the coolness of selling WASM instead.
  - thot_experiment 2y ago
    The coolness of WASM is that I can run WASM on like 99.999% of the targets I care to run code on with zero friction. Everyone (well it's HN so someone is probably on LYNX) reading this page is doing so in a browser with a WASM runtime. That has tremendous value.
    - pjmlp 2y ago
      Applies to most bytecode formats, it is a matter of implementation.
      - marcosdumay 2y ago
        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.
        pjmlp 2y ago
        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.
cheema33 2y ago
I have a different take on this. I think local-first is the future. This is where the apps runs mostly within user's browser with little to no help from the server. Apps like Figma, Linear and Superhuman use this model very successfully. And to some degree Stackblitz does as well. If somewhat complex apps like Figma can run almost entirely within user's browser, then I think vast majority of the apps out there can. Server side mostly is there to sync data between different instances of the app if the user uses it from different locations. The tooling for this is in the works, but is not yet mature. e.g Electric-SQL. Once these libraries are mature, I think this space will take off. Serverless is mostly there to make money for Amazon and Azures of the world and will eventually go the way of the CGI. WASM could succeed as well. But mostly in user's browser. 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.
- jamil7 2y ago
  I work on an iOS app like this right now, it predates a lot of these newer prebuilt solutions. There are some really nice features of working and building features this way, when it works well you can ignore networking code entirely. There are some tradeoffs though and a big one has been debugging and monitoring as well as migrations. There is also some level of end user education because the apps don’t always work the way they’re expecting. The industry the app serves is one in which people are working in the field, doing data entry on a tablet or phone with patchy connections.
- mattdesl 2y ago
  I’m not sure I’d call Figma local first. If I’m offline or in a spotty wifi area, I can’t load my designs. And unless it’s recently changed, if you lose wifi and quit the browser after some edits, they won’t be saved.
  - curtisblaine 2y ago
    That's intentional: they need you and your data tied to the server to make money. But there's no reason why it couldn't be local first (except the business model), since the bulk of execution is local. Incidentally, I think that's why local-first didn't take off yet: it's difficult to monetize and it's almost impossible to monetize to the extent of server-based or server-less. If your application code is completely local, software producers are back to copy-protection schemes. If your data is completely local, you can migrate it to another app easily, which is good for the user but bad for the companies. It would be great to have more smaller companies embracing local-first instead of tech behemoths monopolizing resources, but I don't see an easy transition to that state of things.
junto 2y ago
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 pushes the computational cost from server to client.
- palmfacehn 2y ago
  There have also been exploits of Chrome's JS sandbox. For me the greatest difference is that WASM is supported by the browser itself. There isn't the same conflict of interest between OS vendors and 3rd party runtime providers.
- freetonik 2y ago
  Not an answer, but I think it’s unfair to group Flash with the others because it was both the editor/compiler and the player were proprietary. I guess same applies to Silverlight at least.
  - Kwpolska 2y ago
    The ActiveX "player" (Internet Explorer) was also proprietary. And I'm not sure if you could get away without proprietary Microsoft tools to develop for it.
- tptacek 2y ago
  Java Applets and ActiveX had less-mediated (Applets, somewhat; ActiveX, not at all) access to the underlying OS. The "outer platform" of WASM is approximately the Javascript runtime; the "outer platform" of Applets is execve(2).
- pajamaboin 2y ago
  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)
TekMol 2y ago
I don't see WASM as a significant step forward. In fact, I question its purpose altogether. Before WASM you could already compile code from other languages into JavaScript. And have the same benefits as you have with WASM. The only benefit WASM brings is a bit faster execution time. Like twice the speed. Which most applications don't need. And which plain JavaScript offers about two years later because computers become faster. And you pay dearly for being these two years ahead in terms of execution time. WASM is much more cumbersome to handle than plain JS when it comes to deployment, execution and debugging. In IT we see it over and over again that saving developer time is more important than saving CPU cycles. So I think chosing WASM over plain JS is a net negative.
- pulse7 2y ago
  When computers become faster, WASM will still be twice the speed of JavaScript, because untyped languages limit the optimizations.
- thot_experiment 2y ago
  Bad take. Yes, you can probably optimize a lot of algos in JS such that they are pretty fast, but THAT is cumbersome. I'd much rather write the things I need to go fast in a language that's good at that (I use C for this). I'm currently working on a toolpath optimizer and I'm compiling just the optimizer function to WASM, it's a couple kilobytes and will probably be an order of magnitude faster than the JS implementation while being FAR LESS cumbersome to write. My JS doesn't change at all because i can just call the "native function" from JS, replacing my original JS impl.
  - TekMol 2y ago
    probably be an order of magnitude faster than the JS implementation What makes you think so?
    - thot_experiment 2y ago
      Off the rip because I didn't spend time to make the JS implementation keep all of it's data in a typed array that I manually manage, because it's tedious to do that in JS and it's straightforward in C. Though I'm betting there are other benefits I'll get from -O2 and static analysis.
fallous 2y ago
This article really does remind me of an old Law of Software that we used to invoke: Any sufficiently large and long-lived application will eventually re-implement the entire software stack it runs on, including the operating system.. and it will re-implement it poorly. I'm unsure of the source for this Law, but it certainly proves correct more often than not.
- PoignardAzur 2y ago
  The witty version is known as Greenspun's tenth rule: "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." The general pattern is called the Inner-Platform Effect.
  - anthk 2y ago
    And a complete TCL spec.
  - fallous 2y ago
    YES! The Inner-Platform Effect is exactly what I was trying to dig up through my fossilized neurons. Thank you.
deleted 2y ago
[deleted]
slt2021 2y ago
putting everything in WASM really drains the battery on mobile. I hate WASM heavy websites as often they have bloat of javascript and site is very slow, especially during scrolling, zooming due to abuse of event listeners and piss poor coding discipline. I kinda miss sometimes server rendered index.php
- thot_experiment 2y ago
  WASM is a double edged sword, if you're compiling fast implementations of heavy lift functions to WASM and calling them in lieu of a JS impl you're going to end up saving battery life. If you're generating bindings for some legacy disaster and shipping it to clients as a big WASM blob you're going to hell.
wokwokwok 2y ago
What the article actually says: > If we go back to thinking about our Application Server models; this allows us to have a fresh process but without paying the startup costs of a new process. Essentially giving us CGI without the downsides of CGI. Or in more recent terms, serverless without cold starts. This is how Wasm is the new CGI. ^ It's not a frivolous claim. > Wasm improves performance, makes process level security much easier, and lowers the cost of building and executing serverless functions. It can run almost any language and with module linking and interface types it lowers the latency between functions incredibly. ^ Not unreasonable. I don't agree that its necessarily totally 'game changing', but if you read this article and you get to the end and you dont agree with: > When you change the constraints in a system you enable things that were impossible before. Then I'm left scratching my head what it was you actually read, or what the heck you're talking about. > Serverless is mostly there to make money for Amazon and Azures of the world and will eventually go the way of the CGI. There's... just no possible future, in which AWS and Azure just go away and stop selling something which is making them money, when a new technology comes along and makes it easier, safer and cheaper to it. > I kind of like this variety of headline for it's ability to stimulate discussion but it's also nonsense. CGI can be any type of code responding to an individual web request, represented as a set of parameters. It has basically nothing to do with wasm *shakes head sadly...* ...well, time will tell, but for alllll the naysayers, WASM is here to stay and more and more people are using it for more and more things. Good? Bad? Dunno. ...but it certainly isn't some pointless niche tech that no one cares about is about to disappear. CGI enabled a lot of things. WASM does too. The comparison isn't totally outrageous. It'll be fun to see where it ends up. :)
jillesvangurp 2y ago
WASM replaces a language specific vm (javascript) with a general purpose one anywhere javascript vms are currently used. But not exclusively just there. General purpose here means it can run just about anything with a compiler or interpreter for it. Including javascript. So anything, anywhere. Since it is generally implemented as part of the javascript engine, it inherits a lot of stuff that comes with it like sandboxing and access to the APIs that come with it. Standardizing access to that is a bit of an ongoing process but the end state here is that anything that currently can only be done in Javascript will also be possible in WASM. And a lot more that is currently hard or impossible in Javascript. And it all might run a little faster/smoother. That makes WASM many things. But the main thing it does is remove a lot of restrictions we've had on environments where Javascript is currently popular. Javascript is a bit of a divisive language. Some people love it, some people hate it. It goes from being the only game in town to being one of many things you can pick to do a thing. It's been styled as a Javascript replacement, as a docker replacement, as a Java replacement, a CGI replacement (this article), etc. The short version of it is that it is all of these things. And more.
- marcyb5st 2y ago
  While I don't have a problem with Javascript, I have a problem with the ecosystem around publishing JS for the web. There are so many tools that do more or less the same thing and whose boundaries are unclear. Additionally, when you eventually manage to get everything working it feels brittle (IMHO). For someone that doesn't do that professionally, it is daunting. Nowadays, the few times I need to build something for the web I use leptos which has a much nicer DX and even if it didn't reach 1.x yet, it feels more stable that chaining like 5 tools to transpile, uglify, minify, pack, ... your JS bundle.
torginus 2y ago
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 emulate codegen or hot reload, by dynamically reloading the entire Wasm runtime and preserving the memory, but the user experience will be clunky. I don't see any technical reason why this couldn't be possible. If this were a security measure, it could be trivially bypassed. Also, WASM bytecode is very similar conceptually to .NET IL, Java bytecode etc., things designed for JIT compilation. I kind of dislike WASM. It's a project lacking strong direction and will to succeed in a timely manner. First, the whole idea is conceptually unclear, its name suggests that it's supposed to be 'assembly for the web', a machine language for a virtual CPU, but it's actually an intermediate representation meant for compiler backends, with high-level features planned such as GC support. It's still missing basic features, like the aforementioned hot reload, non-hacking threading, native interfacing with the DOM (without Javascript ideally), low-overhed graphics/compute API support, low-level audio access etc. You can't run a big multimedia app without major compromises in it.
- flohofwoe 2y ago
  > Just in Time (JIT) compilation is not possible as dynamic Wasm code generation is not allowed for security reasons. Browsers definitely use a form of JIT-ing for WASM (which is a bit unfortunate, because just as with JITs, you might see slight 'warmup stutter' when running WASM code for the first time - although this has gotten a lot better over the years). ...also I'm pretty sure you can dynamically create a WASM blob in the browser and then dynamically instantiate and run that - not sure if that's possible in other WASM runtimes though, and even in the browser you'll have to reach out Javascript, but that's needed for accessing any sort of 'web API'.
  - torginus 2y ago
    >Browsers definitely use a form of JIT-ing for WASM I (and the article) wasn't referring to this kind of JIT. I was referring to the ability to dynamically create or modify methods or load libraries while the app is running (like `DynamicMethod` in .NET). Afaik WASM even in the browser does not allow modifying the blob after instantiation. The thing you are referring to puzzles me as well. I initially thought that WASM would be analogous to x86 or ARM asm and would be just another architecture emitted by the compiler. Running it in the browser would just involve a quick translation pass to the native architecture (with usually 1-to-1 mapping to machine instructions) and some quick check to see that it doesn't do anything naughty. Instead it's an LLVM IR analog that needs to be fed into a full-fledged compiler backend. I'm sure there are good technical reasons as to why it was designed like this, but as you mentioned, it comes with tangible costc like startup time and runtime complexity.
feverzsj 2y ago
Companies choose wasm to avoid crawlers.
- ram_rattle 2y ago
  I do not understand this, can you please explain
  - nicce 2y ago
    Probably just a typical cat and mouse game. Some crawlers support React based websites already, for example, so they can render the content and crawl based on that. I believe crawlers do not execute yet the WASM code. But in time, they will.
- tightbookkeeper 2y ago
  And Google probably wanted to ban applets etc because they were negatively impacting search That doesn’t mean there weren’t good technical reasons, but that’s not necessarily the driver, For example, ssl is obviously good, but ssl required also raises the cost of making a new site above zero, greatly reducing search spam (a problem that costs billions otherwise).
DanielHB 2y ago
I have been thinking we would be heading for a world where WASM replaces code running lambda functions on the cloud for a long time. WASM is traditionally seen as running on a host platform, but there is no reason it needs to be this way. Because of the sandbox nature of WASM technically it could even run outside an operating system or in ring0 bypassing a lot of OS overhead. Compiling to WASM makes a whole range of deployment problems a lot simpler for the user and gives a lot of room for the hosting environment to do optimizations (maybe even custom hardware to make WASM run faster).
openrisk 2y ago
It is challenging to forecast how client-server architectures would evolve on the basis of technical merit, even if we restrict to "web architectures" (this itself being a bundle of multiple options). Massive scaling with minimal resources is certainly one important enabler. If you were, e.g., to re-architect wikipedia with the knowledge and hardware of today how would you do it with wasm (on both desktop and mobile). How about a massive multiplayer game etc. On the other hand you have the constraints and costs of current commercial / business model realities and legacy patterns that create a high bar for any innovation to flurish. But high does not mean infinitely high. I hate to be the person mentioning AI on every HN thread but its a good example of the long stagnation and then torrential change that is the hallmark of how online connected computing adoption evolves: e.g., we could have had online numerically very intensive apps and API's a long time ago already (LLM's are not the only useful algorithm invented by humankind). But we didnt. It takes engineering a stampede to move the lazy (cash) cows to new grass land. So it does feel that at some point starting with a fresh canvas might make sense (as in, substantially expand what is possible). When the cruft accumulates sometimes it collapses under its own weight.
EGreg 2y ago
WASM runs on the client side. WASM is basically the new Microsoft Common Language Runtime, or the new JVM etc. But OPEN!
- pjmlp 2y ago
  Plenty of choices for that, and Wikipedia doesn't list everything if one is willing to dive into computing history. https://en.wikipedia.org/wiki/Bytecode https://en.wikipedia.org/wiki/Bytecode
akoboldfrying 2y ago
I don't know much about Wasm so this was helpful, thanks. It does seem like having the same language on both server and browser must make software delivery more flexible. >Just in Time (JIT) compilation is not possible as dynamic Wasm code generation is not allowed for security reasons. I don't follow -- is the Wasm runtime VM forbidden from JITing? (How could such a prohibition even be specified?) Assuming this is the case, I'm surprised that this is considered a security threat, given that TTBOMK JVMs have done this for decades, I think mostly without security issues? (Happy to be corrected, but I haven't heard of any.)
spintin 2y ago
[dead]
Tepix 2y ago
I disagree. In particular for me the allure for CGI was its simplicity. Have you played around with WASM in the browser? It involves way too many steps to get it integrated into the web page and to interact with it. I let chatgpt do the tedious work, have a look at a minimal example: https://chatgpt.com/share/6707c2f3-5840-8008-96eb-e5002e2241d2 https://chatgpt.com/share/6707c2f3-5840-8008-96eb-e5002e2241...
- flohofwoe 2y ago
  The part of loading and instantiating the WASM blob is 3 lines of Javascript, and two of those are for the fetch() call. Calling into the WASM module is a regular JS function call. Not sure how this could be simplified much further, it is much simpler than dealing with FFI in other runtime environments (for instance calling into native code from Java or Kotlin on Android).
  - Tepix 2y ago
    The WASM code doesn't have access to the DOM, if you want to have a web app that interacts with the user (intriguing, isn't it?) you'll end up writing a lot of javascript glue code.
    - flohofwoe 2y ago
      There are enough binding libraries by now where you don't need to write a single line of JS (e.g. https://rustwasm.github.io/wasm-bindgen/examples/dom.html https://rustwasm.github.io/wasm-bindgen/examples/dom.html). For better or worse, browser APIs have been designed to be used with Javascript so some FFI magic needs to happen when called from other languages, with or without WASM. And if each web API would automatically come with a C API specification (like WebGPU kinda does for instance), Rust people would complain anyway that they need to talk to an 'archaic' C API instead of a 'modern' Rust API etc etc...
superkuh 2y ago
Anything that requires executing arbitrary untrusted code from arbitrary untrusted sources automatically is bad and is definitely not filling the same role as server side CGI.
tantalor 2y ago
[2022]
layer8 2y ago
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?
- thomastjeffery 2y ago
  WASM runs on the browser.. What about hosting do you expect to be different?
  - fmajid 2y ago
    Like Java and JavaScript before it, WASM can also run on Kubernetes clusters and plenty of other non-browser contexts.
  - tmpz22 2y ago
    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.
    - deleted 2y ago
      [deleted]
  - layer8 2y ago
    The article is about WASM on the server, hence the analogy to CGI(-bin) in the title.
    - thomastjeffery 2y ago
      I see. My fault for not moving from "From CGI to Serverless" to "Wasm on the Server".
anonu 2y ago
I like the thought. I also think about how Python losing the GIL. If we can write Python to WASM and maintain multi-threading, then the browser is sort of the new "Java JRE"... (to expand on the analogies)
throwaway313373 2y ago
> 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/ https://peps.python.org/pep-0333/ [1] https://github.com/rack/rack/blob/main/CHANGELOG.md https://github.com/rack/rack/blob/main/CHANGELOG.md
kennu 2y ago
In my view, the big promise of server-side WASM is to have an evergreen platform that doesn't need regular updates to the application. Just like HTML web pages work "forever" in browsers, WASM-based applications could work forever on the server-side. Currently it is a huge PITA to have to update and redeploy your AWS Lambda apps whenever a Node.js or Python version is deprecated. Of course, usually the old code "just works" in the new runtime version, but I don't want to have to worry about it every few years. I think applications should work forever if you want them to, and WASM combined with serverless like Lambda will provide the right kind of platform for that.

WASM Is the New CGI

258 points by burglins 2y ago

tantalor 2y ago

> Amazon started the serverless age of compute with Lambda Google App Engine (2008) predates Lambda (2014) by 6 years!

chubot 2y ago
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
- Uehreka 2y ago
  PaaS, Containerization and Serverless are different concepts. App Engine is PaaS: You provide your app to the service in a runnable form (maybe a container image, maybe not) and they spin up a dedicated server (or slice of a server) to run it continuously. Lambda is Serverless: You provide them a bit of code and a condition under which that code should run. They charge you only when that thing happens and the code runs. How they make that happen (deploy it to a bajillion servers? Only deploy it when it’s called?) are implementation details that are abstracted from the user/developer as long as Lambda makes sure that the code runs whenever the condition happens. So with PaaS you have to pay even if you have 0 users, and when you scale up you have to do so by spinning up more “servers” (which may result in servers not being fully utilized). With Serverless you pay for the exact amount of compute you need, and 0 if your app is idle.
  - chubot 2y ago
    > They charge you only when that thing happens and the code runs. That's how App Engine worked in 2008, and it looks like it still works that way: https://cloud.google.com/appengine/pricing https://cloud.google.com/appengine/pricing Apps running in the flexible environment are deployed to virtual machine types that you specify. These virtual machine resources are billed on a per-second basis with a 1 minute minimum usage cost. This applied to both the web workers and the batch workers It was "serverless" in 2008! > spin up a dedicated server (or slice of a server) to run it continuously. Absolutely NOT true of App Engine in 2008, and I'm pretty sure Heroku in 2008 too!
  - tantalor 2y ago
    I recall you could configure app engine with maximum number of instances you wanted, but you definitely weren't charged if usage was 0. They would start the instances as needed. The fact that lambda would automatically scale to meet whatever QPS you got sounds terrifying.
- randomdata 2y ago
  > 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. Good old CGI is serverless, but CGI defines a specific protocol whereas serverless refers to a broad category of various implementations.
  - bloppe 2y ago
    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 runs when it needs to. Of course there's still an HTTP server somewhere, though. 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 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."
    - randomdata 2y ago
      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.
      - bloppe 2y ago
        EC2 and managed kubernetes are two examples where you still have to think about hardware.
- conradev 2y ago
  Serverless, to me, is purely about efficiency. One way to measure that is the time for a "cold start" or "going from a state where you pay no money to one where you pay money". These gains in efficiency remove the need for over-provisioning and in many cases allow you to pass these savings onto the consumer (if you want to). Heroku is a few seconds: > It only takes a few seconds to start a one-off dyno process or to scale up a web or worker process. Lambda created Firecracker to be snappier: > The duration of a cold start varies from under 100 ms to over 1 second. I think App Engine is in the same ballpark as Lambda (and predated it). Fly.io uses Firecracker too: > While Fly Machine cold starts are extremely fast, it still takes a few hundred milliseconds, so it’s still worth weighing the impact it has on performance. but WASM is yet an order of magnitude faster and cheaper: > Cloudflare Workers has eliminated cold starts entirely, meaning they need zero spin up time. This is the case in every location in Cloudflare's global network. WASM is currently limited in what it can do, but if all you're doing is manipulating and serving HTML, it's fantastic at that.
- dartos 2y ago
  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.
- friendzis 2y ago
  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.
  - randomdata 2y ago
    > 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...

smolder 2y ago

I kind of like this variety of headline for it's ability to stimulate discussion but it's also nonsense. CGI can be any type of code responding to an individual web request, represented as a set of parameters. It has basically nothing to do with wasm which is meant to be a universal code representation for a universal virtual machine. Have I missed something?

waynecochran 2y ago
The use of wasm makes sense to me in context of the article.
- smolder 2y ago
  The article does not seem to support the title. You'll have to show me how it does. 'serverless' is a wholly different concept that doesn't have much to do with wasm. You could say it's CGI as a service, but that has nothing to do with wasm.
  - svieira 2y ago
    It's quite buried amid a lot of extra paragraphs expositing about WASM and the future of serverless functions in general, but the article does contain this quote: > One of the many effect of how [WASM] modules are isolated is that you can "pause" a module, and save its memory as a data segment. A similar concept to a Snapshot of a virtual machine. You can then start as many copies of the paused module as you like. (As I tell friends, it's like saving your game in an emulator.) > The snapshotted module has no extra startup time ... > If we go back to thinking about our Application Server models; this allows us to have a fresh process but without paying the startup costs of a new process. Essentially giving us CGI without the downsides of CGI. Or in more recent terms, serverless without cold starts. This is how Wasm is the new CGI.
    - smolder 2y ago
      This is not like CGI. Calling it "the new CGI" seems to me like a way to confuse people, since CGI was a response to individual requests and carrying state across requests was always extra work. None of this has to do with WASM in particular.

rpcope1 2y ago

So basically we're reinventing the JVM and it's ecosystem?

pjmlp 2y ago
Yeah, by folks that most likely used to bash Application Servers from early 2000's. Not only JVM, also CLR, BEAM, P-Code, M-Code, and every other bytecode format since UNCOL came to be in 1958, but lets not forget about the coolness of selling WASM instead.
- thot_experiment 2y ago
  The coolness of WASM is that I can run WASM on like 99.999% of the targets I care to run code on with zero friction. Everyone (well it's HN so someone is probably on LYNX) reading this page is doing so in a browser with a WASM runtime. That has tremendous value.
  - pjmlp 2y ago
    Applies to most bytecode formats, it is a matter of implementation.
    - marcosdumay 2y ago
      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.
      - pjmlp 2y ago
        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.

cheema33 2y ago

I have a different take on this. I think local-first is the future. This is where the apps runs mostly within user's browser with little to no help from the server. Apps like Figma, Linear and Superhuman use this model very successfully. And to some degree Stackblitz does as well. If somewhat complex apps like Figma can run almost entirely within user's browser, then I think vast majority of the apps out there can. Server side mostly is there to sync data between different instances of the app if the user uses it from different locations. The tooling for this is in the works, but is not yet mature. e.g Electric-SQL. Once these libraries are mature, I think this space will take off. Serverless is mostly there to make money for Amazon and Azures of the world and will eventually go the way of the CGI. WASM could succeed as well. But mostly in user's browser. 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.

jamil7 2y ago
I work on an iOS app like this right now, it predates a lot of these newer prebuilt solutions. There are some really nice features of working and building features this way, when it works well you can ignore networking code entirely. There are some tradeoffs though and a big one has been debugging and monitoring as well as migrations. There is also some level of end user education because the apps don’t always work the way they’re expecting. The industry the app serves is one in which people are working in the field, doing data entry on a tablet or phone with patchy connections.
mattdesl 2y ago
I’m not sure I’d call Figma local first. If I’m offline or in a spotty wifi area, I can’t load my designs. And unless it’s recently changed, if you lose wifi and quit the browser after some edits, they won’t be saved.
- curtisblaine 2y ago
  That's intentional: they need you and your data tied to the server to make money. But there's no reason why it couldn't be local first (except the business model), since the bulk of execution is local. Incidentally, I think that's why local-first didn't take off yet: it's difficult to monetize and it's almost impossible to monetize to the extent of server-based or server-less. If your application code is completely local, software producers are back to copy-protection schemes. If your data is completely local, you can migrate it to another app easily, which is good for the user but bad for the companies. It would be great to have more smaller companies embracing local-first instead of tech behemoths monopolizing resources, but I don't see an easy transition to that state of things.

junto 2y ago

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 pushes the computational cost from server to client.

palmfacehn 2y ago
There have also been exploits of Chrome's JS sandbox. For me the greatest difference is that WASM is supported by the browser itself. There isn't the same conflict of interest between OS vendors and 3rd party runtime providers.
freetonik 2y ago
Not an answer, but I think it’s unfair to group Flash with the others because it was both the editor/compiler and the player were proprietary. I guess same applies to Silverlight at least.
- Kwpolska 2y ago
  The ActiveX "player" (Internet Explorer) was also proprietary. And I'm not sure if you could get away without proprietary Microsoft tools to develop for it.
tptacek 2y ago
Java Applets and ActiveX had less-mediated (Applets, somewhat; ActiveX, not at all) access to the underlying OS. The "outer platform" of WASM is approximately the Javascript runtime; the "outer platform" of Applets is execve(2).
pajamaboin 2y ago
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)

TekMol 2y ago

I don't see WASM as a significant step forward. In fact, I question its purpose altogether. Before WASM you could already compile code from other languages into JavaScript. And have the same benefits as you have with WASM. The only benefit WASM brings is a bit faster execution time. Like twice the speed. Which most applications don't need. And which plain JavaScript offers about two years later because computers become faster. And you pay dearly for being these two years ahead in terms of execution time. WASM is much more cumbersome to handle than plain JS when it comes to deployment, execution and debugging. In IT we see it over and over again that saving developer time is more important than saving CPU cycles. So I think chosing WASM over plain JS is a net negative.

pulse7 2y ago
When computers become faster, WASM will still be twice the speed of JavaScript, because untyped languages limit the optimizations.
thot_experiment 2y ago
Bad take. Yes, you can probably optimize a lot of algos in JS such that they are pretty fast, but THAT is cumbersome. I'd much rather write the things I need to go fast in a language that's good at that (I use C for this). I'm currently working on a toolpath optimizer and I'm compiling just the optimizer function to WASM, it's a couple kilobytes and will probably be an order of magnitude faster than the JS implementation while being FAR LESS cumbersome to write. My JS doesn't change at all because i can just call the "native function" from JS, replacing my original JS impl.
- TekMol 2y ago
  probably be an order of magnitude faster than the JS implementation What makes you think so?
  - thot_experiment 2y ago
    Off the rip because I didn't spend time to make the JS implementation keep all of it's data in a typed array that I manually manage, because it's tedious to do that in JS and it's straightforward in C. Though I'm betting there are other benefits I'll get from -O2 and static analysis.

fallous 2y ago

This article really does remind me of an old Law of Software that we used to invoke: Any sufficiently large and long-lived application will eventually re-implement the entire software stack it runs on, including the operating system.. and it will re-implement it poorly. I'm unsure of the source for this Law, but it certainly proves correct more often than not.

PoignardAzur 2y ago
The witty version is known as Greenspun's tenth rule: "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." The general pattern is called the Inner-Platform Effect.
- anthk 2y ago
  And a complete TCL spec.
- fallous 2y ago
  YES! The Inner-Platform Effect is exactly what I was trying to dig up through my fossilized neurons. Thank you.

deleted 2y ago

[deleted]

slt2021 2y ago

putting everything in WASM really drains the battery on mobile. I hate WASM heavy websites as often they have bloat of javascript and site is very slow, especially during scrolling, zooming due to abuse of event listeners and piss poor coding discipline. I kinda miss sometimes server rendered index.php

thot_experiment 2y ago
WASM is a double edged sword, if you're compiling fast implementations of heavy lift functions to WASM and calling them in lieu of a JS impl you're going to end up saving battery life. If you're generating bindings for some legacy disaster and shipping it to clients as a big WASM blob you're going to hell.

wokwokwok 2y ago

What the article actually says: > If we go back to thinking about our Application Server models; this allows us to have a fresh process but without paying the startup costs of a new process. Essentially giving us CGI without the downsides of CGI. Or in more recent terms, serverless without cold starts. This is how Wasm is the new CGI. ^ It's not a frivolous claim. > Wasm improves performance, makes process level security much easier, and lowers the cost of building and executing serverless functions. It can run almost any language and with module linking and interface types it lowers the latency between functions incredibly. ^ Not unreasonable. I don't agree that its necessarily totally 'game changing', but if you read this article and you get to the end and you dont agree with: > When you change the constraints in a system you enable things that were impossible before. Then I'm left scratching my head what it was you actually read, or what the heck you're talking about. > Serverless is mostly there to make money for Amazon and Azures of the world and will eventually go the way of the CGI. There's... just no possible future, in which AWS and Azure just go away and stop selling something which is making them money, when a new technology comes along and makes it easier, safer and cheaper to it. > I kind of like this variety of headline for it's ability to stimulate discussion but it's also nonsense. CGI can be any type of code responding to an individual web request, represented as a set of parameters. It has basically nothing to do with wasm *shakes head sadly...* ...well, time will tell, but for alllll the naysayers, WASM is here to stay and more and more people are using it for more and more things. Good? Bad? Dunno. ...but it certainly isn't some pointless niche tech that no one cares about is about to disappear. CGI enabled a lot of things. WASM does too. The comparison isn't totally outrageous. It'll be fun to see where it ends up. :)

jillesvangurp 2y ago

WASM replaces a language specific vm (javascript) with a general purpose one anywhere javascript vms are currently used. But not exclusively just there. General purpose here means it can run just about anything with a compiler or interpreter for it. Including javascript. So anything, anywhere. Since it is generally implemented as part of the javascript engine, it inherits a lot of stuff that comes with it like sandboxing and access to the APIs that come with it. Standardizing access to that is a bit of an ongoing process but the end state here is that anything that currently can only be done in Javascript will also be possible in WASM. And a lot more that is currently hard or impossible in Javascript. And it all might run a little faster/smoother. That makes WASM many things. But the main thing it does is remove a lot of restrictions we've had on environments where Javascript is currently popular. Javascript is a bit of a divisive language. Some people love it, some people hate it. It goes from being the only game in town to being one of many things you can pick to do a thing. It's been styled as a Javascript replacement, as a docker replacement, as a Java replacement, a CGI replacement (this article), etc. The short version of it is that it is all of these things. And more.

marcyb5st 2y ago
While I don't have a problem with Javascript, I have a problem with the ecosystem around publishing JS for the web. There are so many tools that do more or less the same thing and whose boundaries are unclear. Additionally, when you eventually manage to get everything working it feels brittle (IMHO). For someone that doesn't do that professionally, it is daunting. Nowadays, the few times I need to build something for the web I use leptos which has a much nicer DX and even if it didn't reach 1.x yet, it feels more stable that chaining like 5 tools to transpile, uglify, minify, pack, ... your JS bundle.

torginus 2y ago

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 emulate codegen or hot reload, by dynamically reloading the entire Wasm runtime and preserving the memory, but the user experience will be clunky. I don't see any technical reason why this couldn't be possible. If this were a security measure, it could be trivially bypassed. Also, WASM bytecode is very similar conceptually to .NET IL, Java bytecode etc., things designed for JIT compilation. I kind of dislike WASM. It's a project lacking strong direction and will to succeed in a timely manner. First, the whole idea is conceptually unclear, its name suggests that it's supposed to be 'assembly for the web', a machine language for a virtual CPU, but it's actually an intermediate representation meant for compiler backends, with high-level features planned such as GC support. It's still missing basic features, like the aforementioned hot reload, non-hacking threading, native interfacing with the DOM (without Javascript ideally), low-overhed graphics/compute API support, low-level audio access etc. You can't run a big multimedia app without major compromises in it.

flohofwoe 2y ago
> Just in Time (JIT) compilation is not possible as dynamic Wasm code generation is not allowed for security reasons. Browsers definitely use a form of JIT-ing for WASM (which is a bit unfortunate, because just as with JITs, you might see slight 'warmup stutter' when running WASM code for the first time - although this has gotten a lot better over the years). ...also I'm pretty sure you can dynamically create a WASM blob in the browser and then dynamically instantiate and run that - not sure if that's possible in other WASM runtimes though, and even in the browser you'll have to reach out Javascript, but that's needed for accessing any sort of 'web API'.
- torginus 2y ago
  >Browsers definitely use a form of JIT-ing for WASM I (and the article) wasn't referring to this kind of JIT. I was referring to the ability to dynamically create or modify methods or load libraries while the app is running (like `DynamicMethod` in .NET). Afaik WASM even in the browser does not allow modifying the blob after instantiation. The thing you are referring to puzzles me as well. I initially thought that WASM would be analogous to x86 or ARM asm and would be just another architecture emitted by the compiler. Running it in the browser would just involve a quick translation pass to the native architecture (with usually 1-to-1 mapping to machine instructions) and some quick check to see that it doesn't do anything naughty. Instead it's an LLVM IR analog that needs to be fed into a full-fledged compiler backend. I'm sure there are good technical reasons as to why it was designed like this, but as you mentioned, it comes with tangible costc like startup time and runtime complexity.

feverzsj 2y ago

Companies choose wasm to avoid crawlers.

ram_rattle 2y ago
I do not understand this, can you please explain
- nicce 2y ago
  Probably just a typical cat and mouse game. Some crawlers support React based websites already, for example, so they can render the content and crawl based on that. I believe crawlers do not execute yet the WASM code. But in time, they will.
tightbookkeeper 2y ago
And Google probably wanted to ban applets etc because they were negatively impacting search That doesn’t mean there weren’t good technical reasons, but that’s not necessarily the driver, For example, ssl is obviously good, but ssl required also raises the cost of making a new site above zero, greatly reducing search spam (a problem that costs billions otherwise).

DanielHB 2y ago

I have been thinking we would be heading for a world where WASM replaces code running lambda functions on the cloud for a long time. WASM is traditionally seen as running on a host platform, but there is no reason it needs to be this way. Because of the sandbox nature of WASM technically it could even run outside an operating system or in ring0 bypassing a lot of OS overhead. Compiling to WASM makes a whole range of deployment problems a lot simpler for the user and gives a lot of room for the hosting environment to do optimizations (maybe even custom hardware to make WASM run faster).

openrisk 2y ago

It is challenging to forecast how client-server architectures would evolve on the basis of technical merit, even if we restrict to "web architectures" (this itself being a bundle of multiple options). Massive scaling with minimal resources is certainly one important enabler. If you were, e.g., to re-architect wikipedia with the knowledge and hardware of today how would you do it with wasm (on both desktop and mobile). How about a massive multiplayer game etc. On the other hand you have the constraints and costs of current commercial / business model realities and legacy patterns that create a high bar for any innovation to flurish. But high does not mean infinitely high. I hate to be the person mentioning AI on every HN thread but its a good example of the long stagnation and then torrential change that is the hallmark of how online connected computing adoption evolves: e.g., we could have had online numerically very intensive apps and API's a long time ago already (LLM's are not the only useful algorithm invented by humankind). But we didnt. It takes engineering a stampede to move the lazy (cash) cows to new grass land. So it does feel that at some point starting with a fresh canvas might make sense (as in, substantially expand what is possible). When the cruft accumulates sometimes it collapses under its own weight.

EGreg 2y ago

WASM runs on the client side. WASM is basically the new Microsoft Common Language Runtime, or the new JVM etc. But OPEN!

pjmlp 2y ago
Plenty of choices for that, and Wikipedia doesn't list everything if one is willing to dive into computing history. https://en.wikipedia.org/wiki/Bytecode https://en.wikipedia.org/wiki/Bytecode

akoboldfrying 2y ago

I don't know much about Wasm so this was helpful, thanks. It does seem like having the same language on both server and browser must make software delivery more flexible. >Just in Time (JIT) compilation is not possible as dynamic Wasm code generation is not allowed for security reasons. I don't follow -- is the Wasm runtime VM forbidden from JITing? (How could such a prohibition even be specified?) Assuming this is the case, I'm surprised that this is considered a security threat, given that TTBOMK JVMs have done this for decades, I think mostly without security issues? (Happy to be corrected, but I haven't heard of any.)

spintin 2y ago

[dead]

Tepix 2y ago

I disagree. In particular for me the allure for CGI was its simplicity. Have you played around with WASM in the browser? It involves way too many steps to get it integrated into the web page and to interact with it. I let chatgpt do the tedious work, have a look at a minimal example: https://chatgpt.com/share/6707c2f3-5840-8008-96eb-e5002e2241d2 https://chatgpt.com/share/6707c2f3-5840-8008-96eb-e5002e2241...

flohofwoe 2y ago
The part of loading and instantiating the WASM blob is 3 lines of Javascript, and two of those are for the fetch() call. Calling into the WASM module is a regular JS function call. Not sure how this could be simplified much further, it is much simpler than dealing with FFI in other runtime environments (for instance calling into native code from Java or Kotlin on Android).
- Tepix 2y ago
  The WASM code doesn't have access to the DOM, if you want to have a web app that interacts with the user (intriguing, isn't it?) you'll end up writing a lot of javascript glue code.
  - flohofwoe 2y ago
    There are enough binding libraries by now where you don't need to write a single line of JS (e.g. https://rustwasm.github.io/wasm-bindgen/examples/dom.html https://rustwasm.github.io/wasm-bindgen/examples/dom.html). For better or worse, browser APIs have been designed to be used with Javascript so some FFI magic needs to happen when called from other languages, with or without WASM. And if each web API would automatically come with a C API specification (like WebGPU kinda does for instance), Rust people would complain anyway that they need to talk to an 'archaic' C API instead of a 'modern' Rust API etc etc...

superkuh 2y ago

Anything that requires executing arbitrary untrusted code from arbitrary untrusted sources automatically is bad and is definitely not filling the same role as server side CGI.

tantalor 2y ago

[2022]

layer8 2y ago

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?

thomastjeffery 2y ago
WASM runs on the browser.. What about hosting do you expect to be different?
- fmajid 2y ago
  Like Java and JavaScript before it, WASM can also run on Kubernetes clusters and plenty of other non-browser contexts.
- tmpz22 2y ago
  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.
  - deleted 2y ago
    [deleted]
- layer8 2y ago
  The article is about WASM on the server, hence the analogy to CGI(-bin) in the title.
  - thomastjeffery 2y ago
    I see. My fault for not moving from "From CGI to Serverless" to "Wasm on the Server".

anonu 2y ago

I like the thought. I also think about how Python losing the GIL. If we can write Python to WASM and maintain multi-threading, then the browser is sort of the new "Java JRE"... (to expand on the analogies)

throwaway313373 2y ago

> 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/ https://peps.python.org/pep-0333/ [1] https://github.com/rack/rack/blob/main/CHANGELOG.md https://github.com/rack/rack/blob/main/CHANGELOG.md

kennu 2y ago

In my view, the big promise of server-side WASM is to have an evergreen platform that doesn't need regular updates to the application. Just like HTML web pages work "forever" in browsers, WASM-based applications could work forever on the server-side. Currently it is a huge PITA to have to update and redeploy your AWS Lambda apps whenever a Node.js or Python version is deprecated. Of course, usually the old code "just works" in the new runtime version, but I don't want to have to worry about it every few years. I think applications should work forever if you want them to, and WASM combined with serverless like Lambda will provide the right kind of platform for that.