Also it would save you the trouble of writing a shell from scratch :)
Also, is Emterpreter really an interpreter, or do they still compile parts of the code to ASM.js for performance (e.g., parts that do not contain system calls)?
I hear that there's a plan for some form of limited shared-memory concurrency which might be abusable to allow threads, but I haven't made much of the designs.
But I get your sentiment;
Welcome to the Atwood law.
You mention Bluetooth for example in the beginning which is an example of hardware that is yet not supported from the browser.
Applications beyond what can currently be done in a UNIX shell would be good. You already have thought long about it. I feel you can tell us much more about possibilities!!!
We have a tech report, that has more details on what we are aiming for here: https://web.cs.umass.edu/publication/details.php?id=2414
As another example of what we can do with real Unix abstractions in the browser, we have : https://meme.bpowers.net/
Which runs a standard Go HTTP server in a web worker, and instead of doing XMLHttpRequests to a remote service, can route those requests to the in-browser HTTP server! In this case it is about 10x slower, but I think that is an artifact of the GopherJS compiler I have yet to work out.
> You mention Bluetooth for example in the beginning which
> is an example of hardware that is yet not supported from
> the browser.
Same with traditional C and C++ applications. Wrapping program invocations or APIs with Emscripten can be a pain, and if you have a couple of programs you want to use together, forget it. Browsix lets you compile the program down to a single js file, provide input as you expect (by sticking files on a filesystem, or providing stdin), and register a handle for stdout + stderr.
There's also this https://github.com/shellinabox/shellinabox and this http://www.web-console.org/
Click on the "live demo" link, quite a long delay (few minutes), finally terminal-like display appears with "$" prompt.
However entering usual unix commands, ls, cd, etc., gives error: "Error while executing /usr/bin/ls: TypeError: get length method called on incompatible Object", or "/usr/bin/cd: command not found".
Running with FF Nightly. Don't know if it's me, FF, or the app.
What am I missing?
Second, Firefox stable (46) is currently supported, but something has changed in the nightly that breaks us. It should be simple to track down, but in the meantime using almost anything other than FF nightly should work! (Safari, Gnome Web, Chrome{,ium}, IE Edge).
cp
cat
cpu-intensive-program
curl
dot
echo
exec
fork_test
go-bench
grep
head
hello
hello-socket
http-example
lat_syscall
ls
mkdir
nice
node
pipeline-example
priority-test
rm
rmdir
sh
sha1sum
socket-example
sort
stat
tail
tee
touch
wc
xargs
That's expected:
$ lsb_release -i
Distributor ID: Gentoo
$ ls {,/usr}/bin/cd
ls: cannot access /bin/cd: No such file or directory
ls: cannot access /usr/bin/cd: No such file or directory
$ type cd
cd is a shell builtin
Seems to only happen right after a command though, hitting return a few times gets rid of it.
Yield is relatively new, part of ES6, and I think is tied into async/await. It might be possible to use it in combination with something like Babel, but I didn't go down that route. I think the way forward is SharedArrayBuffers and their blocking wait()s on futexes.
My point: JavaScript, it's ecosystem and community are bad enough to be proprietary. It's the new skurge of the web browser and what do people do? Make 'applications' with it.
But then, the idea of heaping Javascript monsters upon a mere browser seemed ludicrous to me 20 years ago - so I may not be the best judge of those sort of things...