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

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

lazy loading

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

Contents

  lazy loading Andrew Poulos <ap_prog@hotmail.com> - 2013-01-17 15:38 +1100
    Re: lazy loading "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2013-01-16 23:50 -0800
    Re: lazy loading Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-01-17 17:00 +0100
      Re: lazy loading Andrew Poulos <ap_prog@hotmail.com> - 2013-01-18 07:24 +1100
        Re: lazy loading Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-01-17 22:00 +0100
          Re: lazy loading Osmo Saarikumpu <osmo@weppipakki.com> - 2013-01-21 09:49 +0200
            Re: lazy loading Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-01-21 11:54 +0100
    Re: lazy loading Danny <dann90038@gmail.com> - 2013-01-18 13:26 -0800
      Re: lazy loading Andrew Poulos <ap_prog@hotmail.com> - 2013-01-19 13:34 +1100
    Re: lazy loading Danny <dann90038@gmail.com> - 2013-01-19 11:12 -0800

#18119 — lazy loading

A job I recently considered applying for required a person knowledgeable 
about lazy loading.

Googling for "lazy loading" I found this page
   <http://ajaxpatterns.org/On-Demand_Javascript>
which claims:

"...because her new website requires lots of Javascript. She refactors 
the application, extracting out a few Javascript modules. The initial 
page load is now much faster, because only a bare-bones initialisation 
module is pulled down, with the other modules loaded only when they're 
needed."

I'm at a loss as to how this gives any real benefit to users.

If the goal is to increase the user's experience by shortening the 
apparent load time what happens when the user clicks a button that 
requires some javascript to be there and the user needs to wait for the 
javascript to be downloaded? Haven't you just moved the time delay from 
the page load?

Wouldn't it be better to have a, say, 5 second page delay for page load 
and to then have the page operate smoothly rather than five 1 second 
delays during the use of the page?

Andrew Poulos

[toc] | [next] | [standalone]

#18120

On Jan 16, 10:38 pm, Andrew Poulos <ap_p...@hotmail.com> wrote:
> A job I recently considered applying for required a person knowledgeable
> about lazy loading.
>
> Googling for "lazy loading" I found this page
>    <http://ajaxpatterns.org/On-Demand_Javascript>
> which claims:
>
> "...because her new website requires lots of Javascript. She refactors
> the application, extracting out a few Javascript modules. The initial
> page load is now much faster, because only a bare-bones initialisation
> module is pulled down, with the other modules loaded only when they're
> needed."
>
> I'm at a loss as to how this gives any real benefit to users.
>
> If the goal is to increase the user's experience by shortening the
> apparent load time what happens when the user clicks a button that
> requires some javascript to be there and the user needs to wait for the
> javascript to be downloaded? Haven't you just moved the time delay from
> the page load?
>
> Wouldn't it be better to have a, say, 5 second page delay for page load
> and to then have the page operate smoothly rather than five 1 second
> delays during the use of the page?

Once the minimum is available to display the page, the buttons and
other sub-controls could also be visible but have a disabled display.
It may take up to a second for the user to react after the see that
the page has "loaded" and by the time they get to the control in
question, the related code may have been loaded. If there was actually
a 5 second delay, I think lazy loading would not be my primary
concern. I would focus on reducing code footprint, min/gzipping, etc.

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

#18129

Andrew Poulos wrote:

> A job I recently considered applying for required a person knowledgeable
> about lazy loading.
> 
> Googling for "lazy loading" I found this page
>    <http://ajaxpatterns.org/On-Demand_Javascript>
> which claims:
> 
> "...because her new website requires lots of Javascript. She refactors
                                               ^^^^^^^^^^
> the application, extracting out a few Javascript modules. The initial
                                        ^^^^^^^^^^^^^^^^^^ wannabe alert
> page load is now much faster, because only a bare-bones initialisation
> module is pulled down, with the other modules loaded only when they're
> needed."
> 
> I'm at a loss as to how this gives any real benefit to users.
> 
> If the goal is to increase the user's experience by shortening the
> apparent load time what happens when the user clicks a button that
> requires some javascript to be there and the user needs to wait for the
> javascript to be downloaded? Haven't you just moved the time delay from
> the page load?
> 
> Wouldn't it be better to have a, say, 5 second page delay for page load
> and to then have the page operate smoothly rather than five 1 second
> delays during the use of the page?

It depends.  However, “lazy loading” as it is understood there is based on 
the misconception that you can fix the problem of bloat code by (AFAIK) not 
yet proven to be reliable execution of script code through deferred addition 
of script elements, instead of reducing the amount of bloat code by 
intelligent software engineering (more modular code) in the first place.

A feature that would actually help there would be the “defer” attribute of 
“script” elements, if it was universally implemented:

<http://caniuse.com/#search=defer> pp.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#18131

On 18/01/2013 3:00 AM, Thomas 'PointedEars' Lahn wrote:
>
> A feature that would actually help there would be the “defer” attribute of
> “script” elements, if it was universally implemented:
>
> <http://caniuse.com/#search=defer>

Interesting. IE, Firefox and Chrome have been supporting it since 
forever with Opera as the only holdout.

Andrew Poulos

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

#18132

Andrew Poulos wrote:

> On 18/01/2013 3:00 AM, Thomas 'PointedEars' Lahn wrote:
>> A feature that would actually help there would be the “defer” attribute
>> of “script” elements, if it was universally implemented:
>>
>> <http://caniuse.com/#search=defer>
> 
> Interesting. IE, Firefox and Chrome have been supporting it since
> forever with Opera as the only holdout.

Perhaps.  I am still not sure to what extent caniuse.com results can be 
trusted, and would suggest you do your own tests instead.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#18180

On 17.1.2013 23:00, Thomas 'PointedEars' Lahn wrote:

>> Andrew Poulos wrote:

>>> <http://caniuse.com/#search=defer>

>> Interesting. IE, Firefox and Chrome have been supporting it since
>> forever with Opera as the only holdout.

> Perhaps.  I am still not sure to what extent caniuse.com results can be 
> trusted, and would suggest you do your own tests instead.

Seems more reliable than W3Schools :), which includes the Opera logo and
says: "The defer attribute is supported in all major browsers."

(http://www.w3schools.com/tags/att_script_defer.asp)

Last week I downloaded Opera 12 [Opera/9.80 (Windows NT 5.1)
Presto/2.12.388 Version/12.12] and it does not pass the "Try it
yourself" example there

(http://www.w3schools.com/tags/tryit.asp?filename=tryhtml_script_defer)

nor my own defer test page.

-- 
Best wishes, Osmo

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

#18186

Osmo Saarikumpu wrote:

> On 17.1.2013 23:00, Thomas 'PointedEars' Lahn wrote:
>>> Andrew Poulos wrote:
>>>> <http://caniuse.com/#search=defer>
>>> Interesting. IE, Firefox and Chrome have been supporting it since
>>> forever with Opera as the only holdout.
>> Perhaps.  I am still not sure to what extent caniuse.com results can be
>> trusted, and would suggest you do your own tests instead.
> 
> Seems more reliable than W3Schools :),

Which appears not too hard to do, so it does not count in my book.

> which includes the Opera logo and
> says: "The defer attribute is supported in all major browsers."
> 
> (http://www.w3schools.com/tags/att_script_defer.asp)
> 
> Last week I downloaded Opera 12 [Opera/9.80 (Windows NT 5.1)
> Presto/2.12.388 Version/12.12] and it does not pass the "Try it
> yourself" example there
> 
> (http://www.w3schools.com/tags/tryit.asp?filename=tryhtml_script_defer)
> 
> nor my own defer test page.

ACK.

The problem of statements using a relation like ”is supported in” (IMHO 
better: by) with ranges like “*major* browsers” is that it is deferring (no 
pun intended) the truth value of that statement to a subjective definition 
for “major browser”, making the seemingly objective statement actually a 
subjective one.  The “all” quantifier of the relation then merely adds to 
the subjectivity of the statement.

If W3Schools.com would not consider Opera Browser a “major browser”, which 
would therefore not be an instance of the subclass of “major browsers” (and 
one can easily make a class definition based on the property of market share 
so that it would not apply to Opera Browser), there is a probability greater 
than zero that under *that* interpretation that statement is correct.

Therefore, arguments of that kind are informal fallacies:

<http://en.wikipedia.org/wiki/No_true_Scotsman>

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#18136

To Andrew

The benefit to the user is an 'instantaneous' interface to interact with.  Unfortunately if you were to load all 'libraries/modules' at once upon page load, depending on bandwidth it may not take 5secs as you'd expect, a page load can take 15secs or more, depending also on the webserver workload.  Once you add more than one page/click taking that long, it adds up for the user 'surfing experience' and can be not very user-friendly in the end.

Keeping in mind that, not everything that requires a .js processing will be called upon by the user interaction, [just because the page loaded doesn't mean they'll click on everything] than you can save page load by skipping some .js at first, that may not be called at all after all.

The 'surfing experience' is better enhanced by delaying the requested content as little as possible, once the page is loaded, people are more likely to bear with some extra seconds here and there, rather than to wait for extra 5secs or more on a blank loading page, or a progress bar.

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

#18138

On 19/01/2013 8:26 AM, Danny wrote:
> To Andrew
>
> The benefit to the user is an 'instantaneous' interface to interact
> with.  Unfortunately if you were to load all 'libraries/modules' at
> once upon page load, depending on bandwidth it may not take 5secs as
> you'd expect, a page load can take 15 secs or more, depending also on
> the web server workload.  Once you add more than one page/click taking
> that long, it adds up for the user 'surfing experience' and can be
> not very user-friendly in the end.
>
> Keeping in mind that, not everything that requires a .js processing
> will be called upon by the user interaction, [just because the page
> loaded doesn't mean they'll click on everything] than you can save
> page load by skipping some .js at first, that may not be called at
> all after all.
>
> The 'surfing experience' is better enhanced by delaying the requested
> content as little as possible, once the page is loaded, people are
> more likely to bear with some extra seconds here and there, rather
> than to wait for extra 5secs or more on a blank loading page, or a
> progress bar.

I sort of understand what you're saying but why is with non-web apps its 
common/expected practice that you get a "Please wait, loading" dialog 
that can take quite a while to disappear? When the dialog disappears you 
can use the app fully with no noticeable delays.

Do web developers believe that users leave a page that takes too long to 
load? Does providing loading progress feedback make any difference?

Andrew Poulos

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

#18147

To Andrew

Well, code that runs on local resources, so-called non-web apps, is bound to the same constraints and same user interaction affection, and their bottlenecks are FSB and peripherals speeds and optimizations, so the user reaction will be the same, depending on how fast the hardware and optimized code provides.  Of course, local resources moving over a motherboard bus [as opposed to over a LAN or WAN] will be faster than resources moving over many hops over distances.

However, the practice on both case is the same though, if you load say Adobe Photoshop, takes a while to load its resources, and runs smooth depending on what you use, if you were to call say a plugin, the plugins aren't loaded in full at startup, you'll notice they don't quite pop up instantaneously, but they load fast enough due to memory workload and availability.  When I run Quanta Plus(webdev IDE), it loads and everything runs, but if I use a plugin like 'kimagemapeditor' or when I 'firstly' change from a toolbar tab to another, I can see a bit of delay on the display, only the first time, all subsequent times is instantaneous because is already cached.  But all that is proper programming practice [I don't agree with the term 'lazy loading'], you load all that's essential for the functionality, and anything that may not be called with such a high level of frequency, probabilistically, you spare it from the system unless the user explicitly calls for it.

[toc] | [prev] | [standalone]

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

csiph-web