You can read the form with JS and then send it to stdin, yeah. You just overwrite global.fs.read() for reading from stdin (the full example already does that).
Question to comment readers: why would I want to do this?
Aren’t CLI programs’ power in the fact they can be chained by a shell?
Considering wasm is a target architecture everyone has their cannons pointed at, why is this special at all? Why are we now glorifying a new VM? Is it because it’s the “VM of the future” or a VM with less legal restrictions (and thus the VM of the future)?
I think everyone needs to really start thinking critically about why wasm will change anything. With LLVM IR, we can target anything. So why are we targetting a VM? Because it’s more open (which isn’t true, because the underlying hardware will not be wasm (oh but what about wasm fpgas or -based cpus?))?
I see we are in the times of “programming for the web operating system”, but I wonder what the consequences will be. I know a lot of good that can happen, but why is no one focusing on the bad?
Someone made a PR to run uni in some online REPL service; I didn’t really like the UI of that and it was slow, but figured I’d try to see if you can run this in the browser with wasm: turns out you can.
It’s just intended for playing around/previewing with out downloading, nothing more.
That being said, you could use this as a the basis for a web-based unicode/emoji UI: instead of rewriting all the unicode parts in JavaScript, you can re-use the Go code. I already did this for a GTK GUI (unreleased, as I can’t get stuff to render correct in GTK).
Can you also send some form field content to program’s stdin?
You can read the form with JS and then send it to stdin, yeah. You just overwrite
global.fs.read()for reading from stdin (the full example already does that).Question to comment readers: why would I want to do this?
Aren’t CLI programs’ power in the fact they can be chained by a shell?
Considering wasm is a target architecture everyone has their cannons pointed at, why is this special at all? Why are we now glorifying a new VM? Is it because it’s the “VM of the future” or a VM with less legal restrictions (and thus the VM of the future)?
I think everyone needs to really start thinking critically about why wasm will change anything. With LLVM IR, we can target anything. So why are we targetting a VM? Because it’s more open (which isn’t true, because the underlying hardware will not be wasm (oh but what about wasm fpgas or -based cpus?))?
I see we are in the times of “programming for the web operating system”, but I wonder what the consequences will be. I know a lot of good that can happen, but why is no one focusing on the bad?
Sorry, 12am.
Someone made a PR to run
uniin some online REPL service; I didn’t really like the UI of that and it was slow, but figured I’d try to see if you can run this in the browser with wasm: turns out you can.It’s just intended for playing around/previewing with out downloading, nothing more.
That being said, you could use this as a the basis for a web-based unicode/emoji UI: instead of rewriting all the unicode parts in JavaScript, you can re-use the Go code. I already did this for a GTK GUI (unreleased, as I can’t get stuff to render correct in GTK).
This is really awesome .. Is there some way to make a websocket available?
I just sit there and wait that kubernetes is launched in web browsers.
I’m currently in the process of porting my 2048 Solver - a few things I’ve observed:
Threading isn’t currently supported so don’t expect great performance from code leveraging go routines.
CPU heavy code tanks rendering so definitely consider wrapping your WASM logic inside a web worker.
You may need to pause execution to allow any JS event handlers you’ve defined to fire.