emscripten

[Andrew Wiley]

On Wed, Dec 15, 2010 at 9:37 AM, Adam D. Ruppe <destructionator at gmail.com>wrote:
>
> 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!


Unless you're using the beta of the next IE, the beta of the next Opera, or
the current version of Chrome, in which case you'd find that client-side
work is becoming more and more feasible. Now, it's not there yet, but when a
C-ported-to-Java-compiled-to-Javascript version of Quake 2 can get 30FPS in
Google Chrome, I start thinking that performance probably won't be nearly as
bad as browsers move forward.

You don't have to like it, but there's a huge push in web development
towards doing more work on the client, and now that browsers are catching
up, it's going to change the way the web works.

As for the rest:
a) No real time networking
HTML 5 WebSockets, as you said

b) Cross domain communication requires ugly, inefficient hacks, or a proxy
on your server.
This is the one thing you've listed that's not going to change because it
poses a security risk.

c) No sounds (without flash anyway).
Included in HTML 5.

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.
In Chrome (even the version a year or so old that is installed on the lab
computer I'm using right now), there is no latency whatsoever. That's a
simple matter of javascript performance, which is dramatically improving.

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.
This is where frameworks can help. Now that Javascript performance is
barrelling ahead, frameworks start looking much more attractive. I've used
GWT (Java->Javascript) in the past, and input handling feels exactly like it
does in SWT or Swing (the leading Java UI frameworks).

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.
As you said, HTML5. My internet was down this morning, but I was still able
to read the batch of mail in GMail that I downloaded last night because
GMail is already taking advantage of Google Gears, which provides similar
functionality. I get the same thing with a few other web applications.

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.
HTML5 adds WebWorkers, which handle exactly this use case (among others).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20101215/74fe55db/attachment.html>