HTML5 update: why it is slow?
mark at livecode.com
Fri Jan 8 04:52:47 EST 2016
On 2016-01-07 00:25, Monte Goulding wrote:
>> On 7 Jan 2016, at 9:01 am, Peter TB Brett <peter.brett at livecode.com>
>> It remains to be seen whether I can figure out how do that. ;-)
> Personally I’d rather you declare force majeure on wait for HTML5 and
> apply your considerable talents to implementing non-blocking versions
> of everything. Wait et al causes issues all over the place, is usually
> the least efficient way of doing things and the end result is almost
> always a poor user experience. Given the choice of a little bit of
> extra coding work implementing callbacks but with the side benefit
> that users won’t be sitting there wondering what’s going on and an
> engine that’s either 22x faster or half the size (both of which are
> critical issues for HTML5) what do you think people would choose?
> For reference: http://forums.livecode.com/viewtopic.php?f=66&t=18719
That actually is referring to *blocking wait* which is evil.
Non-blocking wait is entirely natural though. It is the difference
between being able to write code like:
put url "..." into tInput
put revdb_query(..., "SELECT * FROM x WHERE y = %1", "tInput") into
doThingWithQueryResult line 1 of tQuery
And (imagining the existence of certain things):
load url "..." with "processThing2"
on processThing2 pUrlData
revb_query_async("processThing3", ..., "SELECT * FROM x WHERE y = %1",
on processThing3 pQueryData
doThingWithQueryResult line 1 of pQueryData
Of course, the point you raise a good one - make sure you can everything
non-blocking first then try and make non-blocking wait work. At least
that way round some things become possible in the HTML5 engine, even if
you have to rewrite some code to make it so.
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
More information about the Use-livecode