HTML5 update: why it is slow?

Mark Waddingham mark at
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> 
>> wrote:
>> 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:
> <>

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:

on processThing
   put url "..." into tInput
   put revdb_query(..., "SELECT * FROM x WHERE y = %1", "tInput") into 
   doThingWithQueryResult line 1 of tQuery
end processThing

And (imagining the existence of certain things):

on processThing
   load url "..." with "processThing2"
end processThing

on processThing2 pUrlData
   revb_query_async("processThing3", ..., "SELECT * FROM x WHERE y = %1", 
end processThing2

on processThing3 pQueryData
   doThingWithQueryResult line 1 of pQueryData
end processThing3

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.

Warmest Regards,


Mark Waddingham ~ mark at ~
LiveCode: Everyone can create apps

More information about the Use-livecode mailing list