Future standard GUI library

[Chris Angelico]

On Sat, Jun 15, 2013 at 10:25 PM, Wolfgang Keller <feliphil at gmx.net> wrote:
>> Okay... how long does a round-trip cost?
>
> With a protocol that wasn't made for the purpose (such as HTTP) and all
> that HTML to "render" (not to mention javascript that's required for
> even the most trivial issues) - way too long.

You keep saying this. I have yet to see actual timings from you.

>> Considering that usability guidelines generally permit ~100ms for
>> direct interaction,
>
> 100ms is definitely a noticeable lag. Even I feel that and I don't use
> touch-typing to use the GUI. 50ms might not be noticeable, but I don't
> have the skills myself to test that.

Okay, so let's talk 50ms then. We can handle this.

>> That's the entire round-trip cost. The queries from Sikorsky to
>> Yosemite involve three computers (the client, the server, and the file
>> server), and is completed in under 30 milliseconds.
>
> I am talking about applications that actually do something. In my case,
> database applications. A PostgreSQL transaction is supposed to take at
> most 25ms to complete (anything above is generally considered an issue
> that needs to be solved, such as bad SQL), *server-side*. That leaves
> you another 25ms for the entire network protocol (the pgsql protocol,
> whatever it is, was designed for the purpose, unlike HTTP) *and* the
> client-side application logic, including the GUI "rendering".

No problem. Again taking *actual real figures*, I got roughly 35-40tps
in PostgreSQL across a LAN. That's around about the 25ms figure you're
working with, so let's use that as a baseline. My benchmark was
actually a durability test from work, which was done on two laptops on
a gigabit LAN, with the database server brutally powered down in the
middle of the test. Each transaction updates a minimum of two rows in
a minimum of one table (transaction content is randomized some). So
that's 25ms for the database, leaving us 25ms for the rest.

> 25ms for client-server (pgsql) network protocol, client-side
> application logic *and* GUI.
>
> With a "web" application that would have to include "application
> server"-side application logic, *and* generation of HTML (and
> javascript), *and* HTTP protocol *and* HTML "rendering" *and*
> client-side javascript.
>
> Won't work.

I've demonstrated already that with basic hardware and a simple Python
HTTP server, network, application logic, and generation of HTML, all
take a total of 8ms. That leaves 17ms for rendering HTML. Now, getting
figures for the rendering of HTML is not easy; I've just spent fifteen
minutes researching on Google and playing with the Firebug-like
feature of Chrome, and haven't come up with an answer; so it may well
be that 17ms isn't enough for a full page load. However, I would say
that the matter is sufficiently borderline (bearing in mind that you
can always use a tiny bit of JS and a DOM change) that it cannot be
called as "Won't work"; it's what Mythbusters would dub "Plausible".

Of course, if you're trying to support MS IE, there's no way you'll
guarantee <50ms response time. This is all predicated on having at
least reasonably decent hardware and software. But using either the
100ms figure from common usability guidelines [1] [2] [3] or your more
stringent 50ms requirement [4], it's certainly entirely possible to
achieve immediate response using AJAX.

I've worked with real figures, hard numbers. You keep coming back with
vague FUD that it "won't work". Where are your numbers? And like Sir
Ruthven Murgatroyd, I fail to see how you can call this impossible in
the face of the fact that I have done it.

ChrisA

[1] http://www.nngroup.com/articles/response-times-3-important-limits/
[2] http://usabilitygeek.com/14-guidelines-for-web-site-tabs-usability/#attachment_719
[3] http://calendar.perfplanet.com/2011/how-response-times-impact-business/
[4] Can you provide a link to any study anywhere that recommends 50ms?