Some time has passed, and while emscripten hasn't been a laser focus it has remained glued on the year's priority list. Just defining the API for C interoperability has been a lot of work, but JavaScript has been kept in mind so that it would one day be able to come out swinging.
We now have a proof-of-concept means of integrating JavaScript and Rebol in a natural way, through functions whose specs are blocks and whose bodies are strings of JavaScript code. The JS-NATIVE offers conventional run-and-return--when the body of the code finishes, it considers the operation over. The JS-AWAITER sandboxes asynchronous operations to appear synchronous, not returning when the body is finished but keeping the caller waiting until an implicit resolve() function is called.
I assume the first step would be to get that little REPL console working.
The links above are to the source for the current iteration of the REPL, which embraces this technique. There is a very long way to go in terms of error handling, exceptions, and being truly easy-to-use for a casual scripter...really it was just a proof-of-concept to get the model out the door.
Here's a page with the REPL: Ren Garden
It tries to attack the basic problems, while trying to throw in a couple of Ren-Garden-isms. Do shift-enter for multi-line input, and you can try something that does a loop containing an INPUT and a PRINT. Cancellation still needs work (the previous iteration of the demo handled it, but it hasn't been accomodated by this one yet). There are some attempts at undo-ability across evaluations.
(Note: For anyone concerned about the current size of the download, there's a lot that can be done about it. If we were willing to rely on browsers with SharedArrayBuffer and WebAssembly threading enabled, we could build directly to webassembly and avoid the bloat and performance hit of using the "emterpreter". Not to mention how much stuff is built into the EXE that is not needed for JavaScript. Anyone planning on using GOB!? Not to mention all the support for file ports and other things that the HTTP model would not use in that form...)
The codebase tries to stay within the realms of defined behavior at the abstraction level of C, and so it has mechanically been able to compile with emscripten for some time. But when it comes down to making it work in a way that is favorable, code tends not to design or write itself.
For some of the reasoning of why it works like it does, see "On giving libRebol JS more powers than JavaScript". It should probably be easy enough to grok if you do JavaScript for a living, and hopefully you can critique or suggest improvements. There's also a fair amount of design to consider in terms of the bridging, so feedback would be valuable on things like "How to bridge arguments to user natives / JS natives"
(I did a lot of C years ago though more recently I do javascript exclusively so I do have some background to help me work on this if it’s not complete a waste of time…
)
I think now is the time at which someone who doesn't practice C but has a lot of JavaScript knowledge can start making a real, interesting thing! While being able to compile Rebol on bare metal remains an imperative, I think the web delivery vehicle is probably the best first chance at getting people exposed to the ideas.
And the language has not stood still. Whether it's things like being able to feed left hand sides into PATH! or truly invisible COMMENTs or pushing the evaluator with things like MATCH, there are a lot of new ideas to show!