Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #28866 > unrolled thread

JavaScript execution and threading

Back to article view | Back to comp.lang.javascript

Contents

  JavaScript execution and threading Philip Herlihy <thiswillbounceback@you.com> - 2015-11-01 13:52 +0000
    Re: JavaScript execution and threading Tim Streater <timstreater@greenbee.net> - 2015-11-01 15:17 +0000
      Re: JavaScript execution and threading Philip Herlihy <thiswillbounceback@you.com> - 2015-11-01 17:52 +0000
        Re: JavaScript execution and threading Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2015-11-04 06:57 -0200
          Re: JavaScript execution and threading Philip Herlihy <thiswillbounceback@you.com> - 2015-11-04 12:12 +0000
            Re: JavaScript execution and threading Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2015-11-04 13:19 +0100
              Re: JavaScript execution and threading Philip Herlihy <thiswillbounceback@you.com> - 2015-11-04 12:31 +0000

#28866 — JavaScript execution and threading

Not quite sure even what question to ask here!

I'm learning JavaScript - I have four textbooks, including one which 
provides 3,000 lines of tested code, so I can stand on someone's 
shoulders (Plug-in Javascript).  I'm an experienced coder, but new-ish 
to JavaScript.  I'm using the (surprisingly good) debugger built-in to 
Chrome, and I've also tried the (also good) one in IE.

Things don't happen quite when I expect them.  As I step over code which 
changes a CSS colour, or kicks off a routine to fade an image in or out, 
often nothing happens in the browser window.  When I trace execution I 
can see that messages get logged to the console as per directions, but 
the overall execution seems "loosely" connected to what I've written.

I have learned to be in awe of browsers (as I've long been of compilers) 
and I've tracked down articles that touch on asynchronous behaviour and 
all the things that a browser has to do as quickly as possible (download 
elements, parse HTML and CSS, render a bitmap and interpret JavaScript 
but I can't find a clear account of how to understand how to establish 
clear sequencing without overlap.  (Latest theory is I need to build 
callbacks into functions so that the next thing isn't started until the 
previous one really has finished.)  Any thoughts?  (Be gentle with me - 
I'm new to JavaScript!)

-- 

Phil, London

[toc] | [next] | [standalone]

#28867

In article <MPG.30a0296f71698746989695@news.eternal-september.org>,
Philip Herlihy <thiswillbounceback@you.com> wrote:

>Not quite sure even what question to ask here!
>
>I'm learning JavaScript - I have four textbooks, including one which 
>provides 3,000 lines of tested code, so I can stand on someone's 
>shoulders (Plug-in Javascript).  I'm an experienced coder, but new-ish 
>to JavaScript.  I'm using the (surprisingly good) debugger built-in to 
>Chrome, and I've also tried the (also good) one in IE.
>
>Things don't happen quite when I expect them.  As I step over code which 
>changes a CSS colour, or kicks off a routine to fade an image in or out, 
>often nothing happens in the browser window.  When I trace execution I 
>can see that messages get logged to the console as per directions, but 
>the overall execution seems "loosely" connected to what I've written.

It's going to depend on when the rendering takes place. I think one may
assume [1] that everything that you add, alter, move or whatever in
your javascript sequence won't happen until all your code has run. So
if some javascript is caused to be run because you click a button, in
effect the rendering only takes place after your code sequence has
completed.

I'm also guessing that different browsers may do things differently or
in different orders. The only exception I found to the "your code must
complete first" rule is that browsers may do what is apparently called
speculative downloading. If you write some html into, say, an iframe,
or if you replace the iframe's DOM with another, the browser might
start parsing that and downloading any images or other items it needs
*before* your javascript completes. In particular, this defeats any
attempt one might be making to (for example) sanitise the iframe's DOM.

[1] I'm making assumptions and guesses here based on observation only;
I'm presenting a hypothesis. I have no actual knowledge of how browsers
operate internally.

-- 
New Socialism consists essentially in being seen to have your heart in 
the right place whilst your head is in the clouds and your hand is in 
someone else's pocket.

[toc] | [prev] | [next] | [standalone]

#28868

In article <011120151517425502%timstreater@greenbee.net>, 
timstreater@greenbee.net says...
> 
> In article <MPG.30a0296f71698746989695@news.eternal-september.org>,
> Philip Herlihy <thiswillbounceback@you.com> wrote:
> 
> >Not quite sure even what question to ask here!
> >
> >I'm learning JavaScript - I have four textbooks, including one which 
> >provides 3,000 lines of tested code, so I can stand on someone's 
> >shoulders (Plug-in Javascript).  I'm an experienced coder, but new-ish 
> >to JavaScript.  I'm using the (surprisingly good) debugger built-in to 
> >Chrome, and I've also tried the (also good) one in IE.
> >
> >Things don't happen quite when I expect them.  As I step over code which 
> >changes a CSS colour, or kicks off a routine to fade an image in or out, 
> >often nothing happens in the browser window.  When I trace execution I 
> >can see that messages get logged to the console as per directions, but 
> >the overall execution seems "loosely" connected to what I've written.
> 
> It's going to depend on when the rendering takes place. I think one may
> assume [1] that everything that you add, alter, move or whatever in
> your javascript sequence won't happen until all your code has run. So
> if some javascript is caused to be run because you click a button, in
> effect the rendering only takes place after your code sequence has
> completed.
> 
> I'm also guessing that different browsers may do things differently or
> in different orders. The only exception I found to the "your code must
> complete first" rule is that browsers may do what is apparently called
> speculative downloading. If you write some html into, say, an iframe,
> or if you replace the iframe's DOM with another, the browser might
> start parsing that and downloading any images or other items it needs
> *before* your javascript completes. In particular, this defeats any
> attempt one might be making to (for example) sanitise the iframe's DOM.
> 
> [1] I'm making assumptions and guesses here based on observation only;
> I'm presenting a hypothesis. I have no actual knowledge of how browsers
> operate internally.

That does make sense.  I'll look for any evidence of this!

-- 

Phil, London

[toc] | [prev] | [next] | [standalone]

#28871

On 11/01/2015 03:52 PM, Philip Herlihy wrote:
> In article <011120151517425502%timstreater@greenbee.net>,
> timstreater@greenbee.net says...
>>
>> In article <MPG.30a0296f71698746989695@news.eternal-september.org>,
>> Philip Herlihy <thiswillbounceback@you.com> wrote:
>>
>>> Not quite sure even what question to ask here!
>>>
>>> I'm learning JavaScript - I have four textbooks, including one which
>>> provides 3,000 lines of tested code, so I can stand on someone's
>>> shoulders (Plug-in Javascript).  I'm an experienced coder, but new-ish
>>> to JavaScript.  I'm using the (surprisingly good) debugger built-in to
>>> Chrome, and I've also tried the (also good) one in IE.
>>>
>>> Things don't happen quite when I expect them.  As I step over code which
>>> changes a CSS colour, or kicks off a routine to fade an image in or out,
>>> often nothing happens in the browser window.  When I trace execution I
>>> can see that messages get logged to the console as per directions, but
>>> the overall execution seems "loosely" connected to what I've written.
>>
>> It's going to depend on when the rendering takes place. I think one may
>> assume [1] that everything that you add, alter, move or whatever in
>> your javascript sequence won't happen until all your code has run. So
>> if some javascript is caused to be run because you click a button, in
>> effect the rendering only takes place after your code sequence has
>> completed.
>>
>> I'm also guessing that different browsers may do things differently or
>> in different orders. The only exception I found to the "your code must
>> complete first" rule is that browsers may do what is apparently called
>> speculative downloading. If you write some html into, say, an iframe,
>> or if you replace the iframe's DOM with another, the browser might
>> start parsing that and downloading any images or other items it needs
>> *before* your javascript completes. In particular, this defeats any
>> attempt one might be making to (for example) sanitise the iframe's DOM.
>>
>> [1] I'm making assumptions and guesses here based on observation only;
>> I'm presenting a hypothesis. I have no actual knowledge of how browsers
>> operate internally.
>
> That does make sense.  I'll look for any evidence of this!
>

I hope this article will help to understand how browsers work:
<http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/>

-- 
Joao Rodrigues

[toc] | [prev] | [next] | [standalone]

#28872

In article <n1cha3$fm4$1@speranza.aioe.org>, groups_jr-1@yahoo.com.br 
says...
> 
> On 11/01/2015 03:52 PM, Philip Herlihy wrote:
> > In article <011120151517425502%timstreater@greenbee.net>,
> > timstreater@greenbee.net says...
> >>
> >> In article <MPG.30a0296f71698746989695@news.eternal-september.org>,
> >> Philip Herlihy <thiswillbounceback@you.com> wrote:
> >>
> >>> Not quite sure even what question to ask here!
> >>>
> >>> I'm learning JavaScript - I have four textbooks, including one which
> >>> provides 3,000 lines of tested code, so I can stand on someone's
> >>> shoulders (Plug-in Javascript).  I'm an experienced coder, but new-ish
> >>> to JavaScript.  I'm using the (surprisingly good) debugger built-in to
> >>> Chrome, and I've also tried the (also good) one in IE.
> >>>
> >>> Things don't happen quite when I expect them.  As I step over code which
> >>> changes a CSS colour, or kicks off a routine to fade an image in or out,
> >>> often nothing happens in the browser window.  When I trace execution I
> >>> can see that messages get logged to the console as per directions, but
> >>> the overall execution seems "loosely" connected to what I've written.
> >>

...> 
> I hope this article will help to understand how browsers work:
> <http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/>

Thanks - that's a very good article, which I read with great interest.  
I looked into compilers many (many) years ago, and some things haven't 
changed.

The article doesn't dwell on how scripts are handled.  I'm now working 
on the assumption that there is a great deal of "optimisation" going on, 
and that the script interpretation takes a very liberal approach to any 
sequencing that I imply in my coding.  Firstly, when stepping through 
lines of code in the Chrome debugger, there is not the expected line-by-
line correspndence between what a line of code directs and what happens 
in the display (which is rather disorienting).  I've also noticed that 
in this function:

function FadeBetween(id1, id2, msecs, interruptible, CB)
{
   FadeOut(id1, msecs, interruptible, CB)
   FadeIn( id2, msecs, interruptible, CB)
}

... the FadeOut and FadeIn (defined elsewhere in the code) are 
unambiguously operating in parallel, when "msecs" can be several 
seconds.  The author of the code I'm using (from the book "Plug-In 
JavaScript", by Robin Nixon, which I found very useful as a beginner) 
clearly anticipated a need for stricter sequencing, which is why he 
often includes a "CB" (CallBack) argument used to "Chain" function calls 
- although why this defeats the wily browser's evident propensity to 
parallelise activity isn't clear to me.  I guess that the "Parse; model;  
express" approach which the article emphasises does account for what 
I've observed.

Certainly, while I'm content (like most users!) to treat the browser as 
a rather clever "black box", my respect for those who've laboured to 
make them so reliable, and adept at making visual sense of my often-
clumsy coding, is unconstrained.

-- 

Phil, London

[toc] | [prev] | [next] | [standalone]

#28873

On Wed, 4 Nov 2015 12:12:24 -0000, Philip Herlihy wrote:

>function FadeBetween(id1, id2, msecs, interruptible, CB)
>{
>   FadeOut(id1, msecs, interruptible, CB)
>   FadeIn( id2, msecs, interruptible, CB)
>}
>
>... the FadeOut and FadeIn (defined elsewhere in the code) are 
>unambiguously operating in parallel, when "msecs" can be several 
>seconds.

Not necessarily. The two functions run quickly one after the
other, calling native functions of the browser, which may then
operate in parallel. This is not a Javascript question.

Hans-Georg

[toc] | [prev] | [next] | [standalone]

#28874

In article <kptj3b1f3tcriidud3c2u5icpsii4lvmcf@4ax.com>, hans-
georgNoEmailPlease@michna.com says...
> 
> On Wed, 4 Nov 2015 12:12:24 -0000, Philip Herlihy wrote:
> 
> >function FadeBetween(id1, id2, msecs, interruptible, CB)
> >{
> >   FadeOut(id1, msecs, interruptible, CB)
> >   FadeIn( id2, msecs, interruptible, CB)
> >}
> >
> >... the FadeOut and FadeIn (defined elsewhere in the code) are 
> >unambiguously operating in parallel, when "msecs" can be several 
> >seconds.
> 
> Not necessarily. The two functions run quickly one after the
> other, calling native functions of the browser, which may then
> operate in parallel. This is not a Javascript question.
> 
> Hans-Georg

Hmm... Interesting suggestion.  The call stack (which unsurprisingly 
relies on a Fade() function) makes many calls to a further function 
"Opacity()" which sets the CSS opacity to a value calculated previously 
from the number of 30ms steps needed for the fade duration.  The browser 
would have to consume all these calls to Opacity() and deliver the 
required effect over what is a very long time in computational terms  - 
the effect is still graceful over as many as six seconds, and the two 
images (id1 & id2) fade in and out precisely in parallel (taking just 
msecs to complete, rather than msecs*2), so there can be no suggestion 
that FadeIn is delayed until FadeOut is complete.  I certainly accept 
that this is not a language issue, but it is clearly of relevance and 
interest to those who write in JavaScript.

Meanwhile, those interested in the parsing process, state-machines, and 
all this may find this of interest too:  http://9gag.com/gag/azLmYrj

-- 

Phil, London

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web