Sadly this is only valid if the js jobs you do are non-threaded and do not use workers, rather than being a matter of logic.
But the speed gain by using javascript in the browser is often only due to multi-threading. We don't have always control about all parts of a js library. We can't "split" then into non-threaded jobs. Usually one has to work really hard with promises. The sums that BR mentioned for doing synchronous communication are pretty much appropriate. We should collect for the (most expensive) offer of the core-team relating the borwser widget. > Jonathan Lynch wrote: > I just wanted to explain my view on why callbacks are not as horrible > as they seem at first, if one structures the script logically. > > The below code explains: > > On LCcontrolScript pcommand,pdata > > If pcommand = empty then > Put "step1();" into tJS > Do tJS in widget "my browser" > > Else if pcommand = "return from step 1" then > -- process pdata > Put "step2();" into tJS > Do tJS in widget "my browser" > > Else if pcommand = "return from step 2" then > --process pdata > Put "step3();" into tJS > Do tJS in widget "my browser > > Else if pcommand = "return from step 3" then > --process pdata > --Finish doing whatever it needs and enjoy a great JavaScript display > End if > > End LCcontrolScript _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
