@a1ba@suya.place @cnlohr@chaos.social yeah

what I meant more, is that if you want "wasm with web interfaces" - that's entirely possible to have with a wrapper, it's more of a question from the languages you're compiling to wasm to support it (emscripten is easy because posix has near-universal support, while browser interfaces don't)

@ignaloidas @cnlohr yes but POSIX doesn't play nice with a complete absence of a filesystem and not only that but the whole asynchronous nature of running stuff in web browser.

It just doesn't work like that.

@a1ba@suya.place @cnlohr@chaos.social look, I don't disagree than emscripten is shit

I'm just saying that it's not wasm's fault that there's no wrapper for just connecting to browser interfaces

@ignaloidas @cnlohr oh, I get it.

No, I think it is wasm fault because it's literally in the name.

@ignaloidas @cnlohr I may be stupid

but if thing called webthing, I suppose it should be for web

but I think there are more uses for wasm as a language for virtual machine that you can embed into your application rather than something to run in browser

@a1ba@suya.place @cnlohr@chaos.social consider - stuff that runs in browsers are applications

@ignaloidas @cnlohr yeah, it's code.

But without JS? Nearly useless.

@a1ba@suya.place @cnlohr@chaos.social Just like it's useless outside of the browser without other code

I don't see why it should be particularly different in browsers. And this way, there's way more flexibility with it.

@ignaloidas @cnlohr wasm running in a wasi compliant virtual machine is quite useful.

@ignaloidas @cnlohr I think if there was something like that in browsers, with browser specifics, like accessing DOM, sandboxed APIs and so on

wasm would get much more adoption than just running Quake with emscripten

@a1ba@suya.place @cnlohr@chaos.social again, I think it's more of a language interface question (what does DOM API look like in C) than a wasm interface question

@ignaloidas @cnlohr it's already solved problem in another kind of wrapper: an operating system kernel.

It doesn't care from which language you call it unless you can emit syscalls.

@a1ba@suya.place @cnlohr@chaos.social right, but still - the wast, wast majority of software is useless without posix calls

sure, you can provide some interface to web apis, but you'll still often need to wrap libraries/posix to fit into web apis

so in the end you're just moving where you're doing the wrapping

@a1ba @cnlohr @ignaloidas Reminds me that even the most extremely basic profile of POSIX for embedded systems (PSE52) still requires a filesystem.

https://posix.opengroup.org/docs/pse52-2003.html
(Extreme because it's basically just turning POSIX into an extension of ISO C. Like there's nothing about shell & utilities or multi-user. That's in PSE54)

@ignaloidas @cnlohr the webapps written in javascript that your browser run right now doesn't require POSIX. And you know I wasn't talking about POSIX here.

Let me write interactive websites without JS dammit. Wasm could've been an alternative if the "web" in its name had _any_ meaning.

@lanodan @cnlohr @ignaloidas oh, yeah, that's a thing.

At least it kinda allows to run existing software, if you really need to

@a1ba@suya.place @cnlohr@chaos.social most of wasm's utility was and is in the fact that you can have a way to use existing, non-browser code in browsers

if you want to use wasm instead of JS - just get down for a bit to write the JS wrappers, and congratulations - you can now have a painful experience dealing with browser API's from other languages

@ignaloidas @cnlohr so basically, yes, emscripten is what we deserve.

And the only application for it is to run some 90s games stuttering in a single frame per second.

@a1ba@suya.place @cnlohr@chaos.social @ignaloidas@not.acu.lt And well, stuff like fopen() is part of ISO C, so without it… what you'd have is a subset of ISO C, at which point what the heck is that environment even from a portability point of view.

@lanodan @cnlohr @ignaloidas I started appreciating actually somewhat conforming environments after I've witnessed homebrew development on switch, psvita and psp.

In all three cases it's some random newlib + gcc port. newlib kinda okay for ISO C99-ish. But C++? Eh... POSIX? Don't even think about it.

It's an enormous amount of work, yeah. But I understand now why people don't maintain their ports for these targets for too long.