[Forwarding a response from Alon Zakai, who is behind Emscripten and
CC'ing him]
>>> There is also another use-case which has been brought up. As the
>>> web
>>> platform is becoming more powerful, people have started converting
>>> code written for other platforms to javascript+html.
>> By "html", here, do you mean something else than<canvas>?
>> Is there something that compiles any Windows/Mac/Linus UI framework
>> into
>> "HTML5"?
> There is pyjamas that compiles Python into JS and GWT that compiles Java into
> JS. Both are UI frameworks, and being able to use sync calls in both would be
> more natural since the original languages have lots of sync stuff I believe.
> I don't know how important this use case is though. But we would like to
> compile open source UI frameworks like Qt and GTK into JS using emscripten,
> and sync would help a lot there.
>
>>> For example the
>>> emscipten[1] and mandreel[2] allow recompiling C++ code to
>>> javascript
>>> which is then run in a web browser.
>> I've been following loosely this topic and all examples I've seen
>> were
>> either about pure computation (like turning a C GZIP library in JS)
>> or
>> graphics stuffs (using canvas, hence my above question).
>>
>>> Many times such code relies on APIs or libraries which contain
>>> blockingcalls.
>> Do you have an example of that? I haven't seen one so far, but that's
>> an
>> interesting point.
>> Specifically, I can't recall having seen any C/C++->JS example that
>> were
>> doing IO (maybe files, but not network),
>> Last I heard, Emscripten compiles to JS from LLVM bytecode. I'm not
>> sure
>> they rely on any library containing blocking calls.
>> But as I said, I have been following that loosely.
> The normal C/C++ IO calls are all synchronous - fopen, fread, etc.
>
> As you said above, this is indeed less of a problem for pure computation. But
> when compiling a complete game engine for example (like in BananaBread), you
> need to handle everything a complete app needs, including synchronous IO.
> Both file IO and and network IO (for multiplayer, downloading assets, etc. -
> we haven't gotten around to that yet though in BananaBread) are relevant, as
> well as synchronous GL operations using WebGL.
>
>>> Technically it might
>>> be possible to automatically rewrite such code to use asynchronous
>>> coding patterns, but so far I don't think anyone has managed to do
>>> that.
>> Naively, I would say, that once we've paid the price to compile code
>> from one language to another, you're not that far off from compiling
>> to
>> a given coding pattern. Especially compiling from LLVM bytecode.
>> Regardless, has anyone tried at all? Has anyone tried to compile to
>> JS+Promises or JS+task.js?
> Consider even the simple and very common case of
>
> ..
> while (!feof(f)) {
> fread(buf, 100, 1, f);
> ..process data in buf..
> }
> ..
>
> I don't have any good ideas for something asynchronous to compile this into
> that does not currently substantially harm performance. Compiling synchronous
> code into continuation passing style, generators, control flow emulation, or
> some other async style would greatly reduce performance. In theory JS engines
> could optimize those styles, but it would be hard and I don't think this is
> at the top of anyone's list of priorities for any JS engine.
>
> Now, we could say that sync code, mainly IO, will run slowly but that is ok
> because it's mainly just done during startup. That's true to some extent, but
> startup is very important too, in BananaBread we already have 5-10 seconds or
> so to load the entire game engine, a lot of which is file IO and processing,
> and we have gotten requests to improve that as much as possible because it is
> very significant for the user's initial impression.
>
> Best,
> Alon Zakai