Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WASM Is the New CGI

roborooter.com

Post reply on HN
Print view View original

81–90 of 311 posts

Re: WASM Is the New CGI

#81

Post by flohofwoe »

thot_experiment wrote: post #58
TekMol wrote: post #46

Earlier quoted context omitted.

Compiling your C to WASM might make it run twice as fast as compiling it to JS. That's all. All other aspects of the workflow are the same.

I will try but I suspect the final score will be 1. WASM 2. JS handwritten for speed 3. C compiled to JS and the gaps will be greater than 2x

You forgot 'C compiled to the asm.js subset of Javascript', that would be on second place right after WASM (the switch from asm.js to WASM was hardly noticeable in my C/C++ code performance-wise - some browsers had special 'fast paths' for the asm.js subset though).

Re: WASM Is the New CGI

#82

Post by curtisblaine »

OtomotO wrote: post #64
llm_trw wrote: post #50

Earlier quoted context omitted.

>Incidentally, I think that's why local-first didn't take off yet Local first is what we had all throughout the 80s to 10s. It's just that you can make a lot more from people who rent your software rather than buy it.

More and more reliably. When people have an abo that cannot be quit every month it gives more financial security to the company. Previously people would buy e.g. the creative suite from Adobe and then work with that version for many, many years to come

Previously people would crack CS from Adobe then work with that version for many, many years to come :)

Re: WASM Is the New CGI

#83

Post by torginus »

flohofwoe wrote: post #68
torginus wrote: post #62

Earlier quoted context omitted.

Hehehe, so the future is how we used to run applications from before the era of the web.

Except with runtime safety, no installation process, no pointless scare popups when trying to run an app directly downloaded from the internet, and trivial distribution without random app store publishing rules getting in the way. In a way - yes - it's almost like it was before the internet, but mostly because other ways to distribute and run applications have become such a hassle, partly for security reasons, but mo…

Apps like these were incredibly common on Windows from the late 90s-early 2010s era. They could do all this (except for the sandboxing thing). You just downloaded a single .exe file, and it ran self-contained, with all its dependencies statically linked, and it would work on practically any system.

On MacOS, the user facing model is still that you download an application, drop it in the Applications folder, and it works.

Re: WASM Is the New CGI

#84

Post by flohofwoe »

torginus wrote: post #83
flohofwoe wrote: post #68

Earlier quoted context omitted.

Except with runtime safety, no installation process, no pointless scare popups when trying to run an app directly downloaded from the internet, and trivial distribution without random app store publishing rules getting in the way. In a way - yes - it's almost like it was before the internet, but mostly because other ways to distribute and run applications have become such a hassle, partly for security reasons, but mo…

Apps like these were incredibly common on Windows from the late 90s-early 2010s era. They could do all this (except for the sandboxing thing). You just downloaded a single .exe file, and it ran self-contained, with all its dependencies statically linked, and it would work on practically any system. On MacOS, the user facing model is still that you download an application, drop it in the Applications folder, and it wo…

> You just downloaded a single .exe file, and it ran self-contained, with all its dependencies statically linked, and it would work on practically any system.

Yeah, but try that today (and even by 2010 that wouldn't work anymore). Windows will show a scare popup with a very hard to find 'run anyway' button, unless your application download is above a certain 'reputation score' or is code-signed with an expensive EV certificate.

> On MacOS, the user facing model is still that you download an application, drop it in the Applications folder, and it works.

Not really, macOS will tell you that it cannot verify that the app doesn't do any harm and helpfully offer to move the application into the trash bin (unless the app is signed and notarized - for which you'll need an Apple developer account, and AFAIK even then there will be a 'mild' warning popup that the app has been downloaded from the internet and whether you want to run it anyway). Apple is definitely nudging developers towards the app store, even on macOS.

Re: WASM Is the New CGI

#85

Post by jblecanard »

smolder wrote: post #2

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?

Totally agree there, the article makes complete confusion between the execution model and the tech used to execute. Especially since it says « not CGI as the protocol but as the model ».

As far as model goes, the serverless one is not a different model. It is still a flavor of the CGI concept. But the underlying tech is different. And not that much. It is only serverless for you as a customer. Technically speaking, it runs on servers in micro-VMs.

Those are orthogonal matters, and even if such tech as the middleware mentioned get some wind, the execution model is still the same and is not new.

Re: WASM Is the New CGI

#86

Post by createaccount99 »

cheema33 wrote: post #6

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

The frontend space is moving away from client-side state, not toward it.

Re: WASM Is the New CGI

#87

Post by torginus »

flohofwoe wrote: post #78
torginus wrote: post #76

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…

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

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

Re: WASM Is the New CGI

#88

Post by mlnj »

SkiFire13 wrote: post #52
palmfacehn wrote: post #9

Earlier quoted context omitted.

If your webserver is already JVM based, there's no context switch between the webserver and the application. Not sure how this would be solved with WASM.

This doesn't make sense, WASM is supposed to run on the client, which is generally a different machine than the webserver, while a context switch is an event that happens within a single machine.

WASM on the server also means that an execution engine that containerizes and runs server code in one of the many languages without the overhead of an entire OS like we do with containers now.

Re: WASM Is the New CGI

#89

Post by therein »

thot_experiment wrote: post #61
tsimionescu wrote: post #47

Earlier quoted context omitted.

Debugging a Rust program compiled to Javascript is MUCH harder than debugging one compiled to WASM. That is the whole point. And even making the program work when compiled to JS is iffy, as JS has a few breaking constraints, notably that it is single threaded. Sure, native JS is easier still. But there is a huge wealth of code already written in languages that are not JS. If you want a web app that needs this code, y…

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.

Re: WASM Is the New CGI

#90

Post by bryanrasmussen »

createaccount99 wrote: post #86
cheema33 wrote: post #6

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

The frontend space is moving away from client-side state, not toward it.

the frontend space is always moving in every direction at the same time, this is known as Schrodinger's frontend, depending on when you look at it and what intentions you have - you may think you're looking at the backend.
Post reply on HN