I do not understand how people think frameworks like Emscripten are valid.
-
@cnlohr emscripten tried to be POSIX compatible for browsers, but in reality, it's hardly conformant in anything and I would rather prefer if it instead presented browser APIs as is.
But because wasm also literally made for anything but the web, you can't do that without a bunch of js wrappers.@a1ba@suya.place @cnlohr@chaos.social tbh wasm was done in a way where by default it can't do anything, so in general to do anything with it you have to do wrappers
emscripten is just one of those -
@a1ba@suya.place @cnlohr@chaos.social tbh wasm was done in a way where by default it can't do anything, so in general to do anything with it you have to do wrappers
emscripten is just one of those@ignaloidas @cnlohr yes, except it sucks. -
@ignaloidas @cnlohr yes, except it sucks.
@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) -
@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. -
@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 -
@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 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 -
@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
-
@a1ba@suya.place @cnlohr@chaos.social consider - stuff that runs in browsers are applications
-
@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. -
@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 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 -
@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
-
@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. -
@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 -
@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 @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) -
@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@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. -
@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)@lanodan @cnlohr @ignaloidas oh, yeah, that's a thing.
At least it kinda allows to run existing software, if you really need to -
@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.@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 -
@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.
