emscripten

[Adam D. Ruppe]

> All of your complaints are about specific choices of the
> developers, not the technology.

Some killer limitations:

a) No real time networking. There is websockets aiming to correct this, but they
aren't actually working yet. Long polling gives surprisingly decent results, all
things considered, but it still sucks compared to real networking.

b) Cross domain communication requires ugly, inefficient hacks, or a proxy on your
server.

c) No sounds (without flash anyway).

d) Graphics, even if you grant the canvas element, are a joke. The latency is
brutal. Take that deviant art thing from earlier in the thread. Flick your mouse,
and watch the lines slowly catch up to you! Using X11 with a remote server is
faster than that.

e) Input requires a lot of magic. Some keys have the same identifiers, some of the
time, meaning just checking for keypress requires dozens of lines of code, and
still doesn't work right! Checking for multiple keys or mouse buttons hit at once
is very poor.

f) Very little state across loads (though html5 is adding something for this, if
it ever gets broad penetration), mentioned mainly for completeness, since
javascript variables do work for must things, but your persistent database still
has to be on the server.

g) No threading. I recently tried making a javascript -> d caller. In D, this
would be trivial: opDispatch means no code needs to be written, and if it runs in
a different thread from the rest of the UI, it can make sync calls to the server
without freezing everything up, thus letting it be written in a linear style.

Now a set of linear calls to a network server might not be desirable anyway, but
sometimes it simplifies things a lot without a significant slowdown; it'd be nice
to have it as an option.

But no can do in javascript. If you make a sync ajax request, the *entire browser*
freezes up waiting on the response. Even if it is brief, this is really annoying
to the user.

Even with async calls, if you spend much time processing any one event, the whole
thing grinds to a halt. It won't fire other events while waiting on you to finish
the one, since the js environment is all one thread.


It's not too bad in practice most the time, but in those cases where I want to
just process in the background, it sucks hard.



I'll spare the list of Javascript mistakes, since quite a few of them could be
fixed in the library, except, ironically enough, loading that library yourself.
Wouldn't it be great to have an #include? Best you can do is check for some global
to be defined, and if not, write a <script> element... which loads slowly so you
have to wait for it, which is a pain thanks to (g). Most libraries just seem to
require the user write the <script> tag himself in the html. So much for
encapsulating your dependencies.

But every lib that does this needs to carry those functions with it. Aargh.


Conclusion:
If the web were used as a document sharing system, most of these things would be
features rather than bugs. Who doesn't hate websites with sound anyway? But if you
want to do applications on it, they are severe limitations.

Which brings me back to my first post in the thread: if you are doing a serious
application, 9/10 times you have to do all your real work on the server anyway,
with the client being just for simple display and input. External service
interaction is done on the server. The database interaction is done on the server.
Any background tasks you want to run is done on the server. Sensitive data tends
to be handled on the server.


In the end, with so much work done on the server, there's very little left to do
on the client, so there's not much benefit from being able to choose a different
client side language.

And in those rare cases where you are doing a lot of client side work, it is so
brutally slow that if you start piling other runtimes on top of it, you'll often
be left with an unusable mess anyway!