On Wed, Dec 15, 2010 at 11:24 AM, Andrew Wiley <debio...@gmail.com> wrote:
> On Wed, Dec 15, 2010 at 9:37 AM, Adam D. Ruppe > <destructiona...@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)
