Web assembly

will I finally be able to use C for the web?
or is the just some DOA tech that will be thrown to the wayside?

Attached: webA.png (220x220, 5K)

Other urls found in this thread:

github.com/aspnet/Blazor
youtu.be/D4fNcX0Q9gA
twitter.com/NSFWRedditVideo

Bumping for interest

you fucks really do not get what the fuck WA is, do you?

WA should not exist. It is a solution to a problem that you shouldn't have in the first place.

>a problem that you shouldn't have in the first place
um, what? more and more applications are running inside a browser, it is easier to tell a brainlet "go to this website and suddenly you have an photo cropping tool", rather than "download and install this which may or may not work on your OS, and then run it, and then you have your image editing tool"

and because browsers run in many architectures (ARM, x86, RISC-V in the future, etc), you need to have a standard on which you have to agree upon. webassembly is the solution

unless you are happy telling people to download another VM? all successful languages have a VM in the middle. C# (mono/.NET), Java/Kotlin/Scala (JVM), Python (the interperter, not a VM but still)

bundling a universal VM in the browser is inevitable, i guarantee you it is 1000000 times better than fucking cancerscript

Attached: it-looks-like-your-trip-to-flavortown-is-over-16340433.png (500x584, 149K)

>will I finally be able to use C for the web?
Doubt so.
Though there are C->JS translators.
>or is the just some DOA tech that will be thrown to the wayside?
It's tech for more sophisticated DRMs. Nothing else.

>will I finally be able to use C for the web?
it already works, you can compile C to wasm with the emscripten compiler
however, what exactly are you hoping to write? the nice thing about C on desktop is that you have the mature ecosystem with all the good libraries, on wasm this all disappears

You mean Rust.

Get ready for the "I'm a C Programmer" JS->C 2gb websites

github.com/aspnet/Blazor
I really want to use F# instead of jabbascript.

I think you've fundamentally misunderstood the concept of web assembly.

I think it should have never been in a browser. Neither should be a pdf reader. The browser should instead use existing programs instead of reinventing whole desktop environment. It would be great if the only thing a browser did was handling HTTP and issuing the data to appropriate programs.

Thats the point of it being in a browser you dumb fuck. The browser will provide an execution environment and functionality requested by the WASM VM, like http or a graphics context or a bridge to native apis.

So could a browser use my desktop pdf reader by using Wasm?

AutoCAD was ported to the browser using WebAssembly..
youtu.be/D4fNcX0Q9gA

If your desktop pdf reader was made in C

I don't mean using the same code and compiling it C->Wasm, I mean using the same program.

Why would you want a website executing arbitrary programs on your desktop?
WASM exists to sandbox everything within the browser, instead of the shit we had with Java and Flash, where some arbitrary outside program was running possibly unsafe code on your computer.
With WASM, even if the code is unknown, it's limited to the browser environment, and can't compromise your computer—and if it does, it was an exploit in your browser, which will quickly get fixed, instead of in your Flash Player plugin, where the exploit will sit there until Adobe decides to fix it.

>Why would you want a website executing arbitrary programs on your desktop?
That's not what I want. What I want is that the browser inform my operating system that it's got a pdf file and wants to open it. The operating system would decide that a fitting program for a pdf file would be a pdf reader and open it in a frame prepared inside the browser. I see how Wasm is needed with its ability to sandbox programs (would be nice if it had some privilege system like Android although nobody even cares about permissions because apps ask for everything) but I would like it to not be a part of the thing that handles HTTP. But yeah, a fundamental problem is that web pages aren't loaded at once - you have dynamically loaded content and then the programs would need to know that they can perform HTTP requests by talking with the HTTP thing. I'm well aware that what I want is at least difficult and possibly impossible with the current state of things.

Or maybe we could implement programs as Haskell functions and they would perform HTTP requests simply by evaluating the desired part which was passed from HTTP thing.

>I see how Wasm is needed with its ability to sandbox programs
The more Wasm allows you to do in the browser, the less useful it gets as a sandbox.

Generally, a sandbox exists because you want it to not do certain things. If a sandbox prevents the program from doing anything to the outside world, it renders the program useless.

I think at the moment, WASM 1.0 is enough to do anything basic you'd want a program to do, with the ability to import and export functions and memory to the host environment.
This is fine if you want WASM to be able to run in arbitrary environments that import their own API—there's a couple projects to make "server-side" WASM VMs, or a microkernel that runs WASM at ring-0, and each provides its own API.
But in the browser, you need to make your own API to import via Javascript. Given this, there's a proposal for browsers to provide "Host bindings" so that WASM programs can interact with the DOM and other Web APIs without a developer needing to create all the tedious glue-code themselves.

You already can use it, go get some code running with emscripten.

Alternatively just declare a fixed ArrayBuffer at the top of your code and use that for all data access and variables, implementing your own memory management, since this is basically what WASM and C are anyway.

You still have to use js as middle man.