emscripten

[Andrew Wiley]

On Wed, Dec 15, 2010 at 11:24 AM, Andrew Wiley <debio264 at gmail.com> wrote:

> 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).
>

I should also note that every HTML5 feature I mentioned here except
WebSockets is also supported in Firefox 3.5. IE9 supports everything but
WebSockets and WebWorkers. (Apparently there's some trouble with the
WebSockets specification at the moment)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20101215/e86ac311/attachment.html>