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

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

Importing multiple .js files

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

Contents

  Importing multiple .js files "Robert Crandal" <rcranz143101@gmail.com> - 2013-10-25 03:09 -0700
    Re: Importing multiple .js files Stefan Weiss <krewecherl@gmail.com> - 2013-10-25 13:06 +0200
      Re: Importing multiple .js files Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-10-25 22:18 +0200
        Re: Importing multiple .js files "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2013-10-26 00:05 +0300
          Re: Importing multiple .js files Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-10-25 23:54 +0200
            Re: Importing multiple .js files John Harris <niam@jghnorth.org.uk.invalid> - 2013-10-27 14:05 +0000
              Re: Importing multiple .js files Christoph Michael Becker <cmbecker69@arcor.de> - 2013-10-27 17:05 +0100
                Re: Importing multiple .js files John Harris <niam@jghnorth.org.uk.invalid> - 2013-10-28 15:40 +0000
                  Re: Importing multiple .js files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-10-28 15:49 +0000
                    Re: Importing multiple .js files John Harris <niam@jghnorth.org.uk.invalid> - 2013-10-29 16:29 +0000
                      Re: Importing multiple .js files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-10-29 20:41 +0000
                        Re: Importing multiple .js files John Harris <niam@jghnorth.org.uk.invalid> - 2013-10-31 09:31 +0000
                          Re: Importing multiple .js files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-10-31 13:30 +0000
                  Re: Importing multiple .js files Christoph Michael Becker <cmbecker69@arcor.de> - 2013-10-29 22:13 +0100
                    Re: Importing multiple .js files Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-10-30 00:50 +0100
                      Re: Importing multiple .js files John Harris <niam@jghnorth.org.uk.invalid> - 2013-10-31 15:52 +0000
                        Re: Importing multiple .js files Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-10-31 17:19 +0100
                          Re: Importing multiple .js files John Harris <niam@jghnorth.org.uk.invalid> - 2013-11-01 15:27 +0000
                        Re: Importing multiple .js files Christoph Michael Becker <cmbecker69@arcor.de> - 2013-10-31 18:34 +0100
                          Re: Importing multiple .js files "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2013-10-31 20:36 +0200
                            FAQ discussion (was: Importing multiple .js files) Christoph Michael Becker <cmbecker69@arcor.de> - 2013-10-31 20:33 +0100
                              Re: FAQ discussion Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-11-06 12:20 +0100
                                Re: FAQ discussion Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-11-06 14:33 +0100
                    Re: Importing multiple .js files John Harris <niam@jghnorth.org.uk.invalid> - 2013-11-01 15:12 +0000
                      "javascript" (was: Importing multiple .js files) Christoph Michael Becker <cmbecker69@arcor.de> - 2013-11-04 18:36 +0100
                        Re: "javascript" (was: Importing multiple .js files) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-11-05 02:41 +0100
      Re: Importing multiple .js files Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-10-27 00:30 +0200
        Re: Importing multiple .js files Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-10-27 00:58 +0200
          Re: Importing multiple .js files Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-10-27 01:27 +0200
            Re: Importing multiple .js files Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-10-27 02:37 +0200
              Re: Importing multiple .js files Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-10-27 09:49 +0100
                Re: Importing multiple .js files Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-10-27 15:38 +0100
                  Re: Importing multiple .js files Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-10-27 16:11 +0100
                    Re: Importing multiple .js files Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-10-27 20:16 +0100
        Re: Importing multiple .js files Stefan Weiss <krewecherl@gmail.com> - 2013-10-27 02:01 +0100
          Re: Importing multiple .js files danca <cyberdanny@tiscalinet.it> - 2013-10-27 11:30 +0100
    Re: Importing multiple .js files nappysoft <nappysoft@gmail.com> - 2013-11-21 05:53 -0800
      Re: Importing multiple .js files Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-11-21 16:15 +0100

Page 2 of 2 — ← Prev page 1 [2]

#21803 — FAQ discussion (was: Importing multiple .js files)

Jukka K. Korpela wrote:

> 2013-10-31 19:34, Christoph Michael Becker wrote:
> 
>> Thomas has mentioned and justified this change in
>> <2377471.k03CVt3Ec2@PointedEars.de>
> 
> Do you seriously think that Message-IDs are generally useful in 2013? Or
> don’t you just care?

Yes, I do think they are generally useful.  You may not be aware that
there are possibilities to look up the messages by their ID.[1]

> How does your posting address the question about “Importing multiple .s
> files”, the Subject line under which you are writing?

I have to apologize that I had not changed the subject line appropriately.

> These questions are rhetorical, of course (unlike the original question
> of this thread, one of the last real questions here). This group is
> almost dead, and your are contributing to making this final, with all
> this babbling about a FAQ that nobody reads and about various wannabe
> “FAQ maintainers”.

Well, I am reading the FAQ from time to time, and I always scan the
daily FAQ postings.  And I am quite confident that I am not the only one
who does.  However, it is sometimes distracting reading out-dated
information there.  This should change, shouldn't it?

> Answering questions, at the level they were asked, might keep the group
> alive for some purposes. Now it’s just a ridiculous forum for showing off.

[1] E.g. <http://al.howardknight.net/>

-- 
Christoph M. Becker

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

#21910 — Re: FAQ discussion

Christoph Michael Becker wrote:

> Jukka K. Korpela wrote:
>> 2013-10-31 19:34, Christoph Michael Becker wrote:
>>> Thomas has mentioned and justified this change in
>>> <2377471.k03CVt3Ec2@PointedEars.de>
>> 
>> Do you seriously think that Message-IDs are generally useful in 2013? Or
>> don’t you just care?
> 
> Yes, I do think they are generally useful.  You may not be aware that
> there are possibilities to look up the messages by their ID.[1]

Both newsreaders and Google Groups support news: URIs, so I suggest to use 
those: <news:2377471.k03CVt3Ec2@PointedEars.de>.  However, when having 
selected an archived Usenet newsgroup (and only then), even Google Groups 
still has a “Message-ID” field in its “Advanced Search” form.  (If only the 
Web interface was not so buggy and spammed, it could almost be a decent 
Usenet archive again.)

> […]
> [1] E.g. <http://al.howardknight.net/>
 
-- 
PointedEars

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

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

#21911 — Re: FAQ discussion

Thomas 'PointedEars' Lahn wrote:

> Christoph Michael Becker wrote:
>> Jukka K. Korpela wrote:
>>> 2013-10-31 19:34, Christoph Michael Becker wrote:
>>>> Thomas has mentioned and justified this change in
>>>> <2377471.k03CVt3Ec2@PointedEars.de>
>>> Do you seriously think that Message-IDs are generally useful in 2013? Or
>>> don’t you just care?
>> Yes, I do think they are generally useful.  You may not be aware that
>> there are possibilities to look up the messages by their ID.[1]
> 
> Both newsreaders and Google Groups support news: URIs, so I suggest to use
> those: <news:2377471.k03CVt3Ec2@PointedEars.de>.  […]

See also:

T. Berners-Lee, R. Fielding, L. Masinter (2005-01). “Uniform Resource 
Identifier (URI): Generic Syntax”. RFC 3986/STD 66 (Internet Standard).  
<http://tools.ietf.org/html/rfc3986>

F. Ellermann (2010-04). “The 'news' and 'nntp' URI Schemes”. RFC 5538 
(2013: Proposed Standard).  <http://tools.ietf.org/html/rfc5538>

:)
 
>> […]
>> [1] E.g. <http://al.howardknight.net/>

-- 
PointedEars

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

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

#21813

On Tue, 29 Oct 2013 22:13:24 +0100, Christoph Michael Becker
<cmbecker69@arcor.de> wrote:

>John Harris wrote:
>
>> On Sun, 27 Oct 2013 17:05:24 +0100, Christoph Michael Becker
>> <cmbecker69@arcor.de> wrote:
>> 
>>> John Harris wrote:
>>>>
>>>> On Fri, 25 Oct 2013 23:54:08 +0200, Thomas 'PointedEars' Lahn
>>>> <PointedEars@web.de> wrote:
>>>>
>>>>   <snip>
>>>>> There is no “javascript”, 
>>>>
>>>> javascript : A convenient name for the group of programming 
>>>> languages that use most of the syntax and semantics described in
>>>> ECMA 262.
>>>
>>> Is "javascript" actually more convenient a name than "ECMAScript"?
>> 
>> I don't know about convenient, but it's certainly more accurate.  As
>> soon as you start talking about a DOM or a Filestore object you are
>> outside ECMAScript. 
>
>Would you cover such APIs under the term "javascript"?  Then you should
>adjust the definition of "javascript" you gave above.
  <snip>

The DOM documents specify an ECMAScript binding, among other things.
This is a posh way of saying that your program can access the current
document using familiar ECMAScript syntax in the source file, as in
a.b and a.c().

Thus when I wrote "use most of the syntax" I was including DOM access
and anything similar.

I know Thomas says that DOM objects are not part of any language, but
then he goes very quiet when you ask about Date objects, and Function
objects.

  John

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

#21895 — "javascript" (was: Importing multiple .js files)

Am 01.11.2013 16:12, schrieb John Harris:
> On Tue, 29 Oct 2013 22:13:24 +0100, Christoph Michael Becker
> <cmbecker69@arcor.de> wrote:
> 
>> John Harris wrote:
>>
>>> On Sun, 27 Oct 2013 17:05:24 +0100, Christoph Michael Becker
>>> <cmbecker69@arcor.de> wrote:
>>>
>>>> John Harris wrote:
>>>>>
>>>>> On Fri, 25 Oct 2013 23:54:08 +0200, Thomas 'PointedEars' Lahn
>>>>> <PointedEars@web.de> wrote:
>>>>>
>>>>>   <snip>
>>>>>> There is no “javascript”, 
>>>>>
>>>>> javascript : A convenient name for the group of programming 
>>>>> languages that use most of the syntax and semantics described in
>>>>> ECMA 262.
>>>>
>>>> Is "javascript" actually more convenient a name than "ECMAScript"?
>>>
>>> I don't know about convenient, but it's certainly more accurate.  As
>>> soon as you start talking about a DOM or a Filestore object you are
>>> outside ECMAScript. 
>>
>> Would you cover such APIs under the term "javascript"?  Then you should
>> adjust the definition of "javascript" you gave above.
>   <snip>
> 
> The DOM documents specify an ECMAScript binding, among other things.
> This is a posh way of saying that your program can access the current
> document using familiar ECMAScript syntax in the source file, as in
> a.b and a.c().
> 
> Thus when I wrote "use most of the syntax" I was including DOM access
> and anything similar.

Well, such generalizations might easily cause confusion.  Consider, for
instance, the following hypothetical question:

  "How can I access my database with javascript."

Or, somewhat more related to the DOM (or not):

  "How can I access an element with javascript."

> I know Thomas says that DOM objects are not part of any language, but
> then he goes very quiet when you ask about Date objects, and Function
> objects.

Well, the DOM is not part of the ECMAScript Language Specification, but
Date and Functions objects are (at least since the third edition of
ECMA-262).

-- 
Christoph M. Becker

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

#21899 — Re: "javascript" (was: Importing multiple .js files)

Christoph Michael Becker wrote:

> Am 01.11.2013 16:12, schrieb John Harris:
>> I know Thomas says that DOM objects are not part of any language, but
>> then he goes very quiet when you ask about Date objects, and Function
>> objects.

Meditate on this if you can: DOM means “Document Object Model”.
 
> Well, the DOM is not part of the ECMAScript Language Specification, but
> Date and Functions objects are (at least since the third edition of
> ECMA-262).

Since the first one.

<http://PointedEars.de/es-matrix/?filter=Date%7CFunction>
 
-- 
PointedEars

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

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

#21740

Stefan Weiss <krewecherl@gmail.com> writes:

> On 2013-10-25 12:09, Robert Crandal wrote:

[loading multiple script files with static script elements]

> It's the most common way. As for "best", that depends on your usage
> pattern. If the included scripts are static and included on all of your
> pages, it would be more efficient to concatentate them into one large
> file and include that instead. Ten <script> elements means ten requests
> to the server. Requesting one large file is more efficient than
> requesting ten separate smaller ones.

IMNSHO there's a lot wrong with that concatenated picture.

1) What is 'large'? If you you have five script files between five and
ten KiB, go ahead. But is it more efficient to load 500 KiB (or more)
script synchronously before you can render anything at all instead of
loading what you need in order to render the initial view first and
lazy-load the rest?

2) Loading a really large file is usually much less efficient than
loading several smaller files dynamically in parallel in most (more or
less) contemporary browsers. This might depend on the precise values of
'several' and 'contemporary', of course.

3) If you happen to exclusively develop for UA's that already support
SPDY, you're just waisting time anyway (or rather, you're being
very productive shooting yourself in your foot).

4) If you change one character in a one MiB file, you have to serve one
MiB to propagate that change to the client. Most client-side code I've
seen can be at least be split into:

  - third party vendor code (very infrequently or never updated)
  - application core (updated when a bug has been found and fixed)
  - end user feature set (frequently updated)

and to me it makes sense to separate and aggressively cache all of them.

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

#21741

Eric Bednarz wrote:

> Stefan Weiss <krewecherl@gmail.com> writes:
>> On 2013-10-25 12:09, Robert Crandal wrote:
> 
> [loading multiple script files with static script elements]
> 
>> It's the most common way. As for "best", that depends on your usage
>> pattern. If the included scripts are static and included on all of your
>> pages, it would be more efficient to concatentate them into one large
>> file and include that instead. Ten <script> elements means ten requests
>> to the server. Requesting one large file is more efficient than
>> requesting ten separate smaller ones.
> 
> IMNSHO there's a lot wrong with that concatenated picture.

You might want to reconsider.
 
> 1) What is 'large'? If you you have five script files between five and
> ten KiB, go ahead. But is it more efficient to load 500 KiB (or more)
> script synchronously before you can render anything at all instead of
> loading what you need in order to render the initial view first and
> lazy-load the rest?

Lazy loading was not considered in the argument; therefore, ignoring that 
possibility: yes, one request is more efficient than several ones.  As for 
“500 KiB (or more)”, see below.
 
> 2) Loading a really large file is usually much less efficient than
> loading several smaller files dynamically in parallel in most (more or
> less) contemporary browsers. This might depend on the precise values of
> 'several' and 'contemporary', of course.

How did you get that idea?  You are also not considering that the number of 
parallel HTTP requests is limited, not only by HTTP/1.1 definitions, and 
that even if parallel download is possible, parallel parsing is not.
 
> 3) If you happen to exclusively develop for UA's that already support
> SPDY, you're just waisting time anyway (or rather, you're being
                    ^^^^^^^^
Big fat time? ;-)

> very productive shooting yourself in your foot).

Although true, the argument is fallacious here.  One cannot assume SPDY 
support.  To quote: “As of April 2013, approximately 1% of all websites 
support SPDY.[30] Some Google services (e.g. Google search, Gmail, and other 
SSL-enabled services) use SPDY when available.[31] Google's ads are also 
served from SPDY-enabled servers.[32]”

<https://en.wikipedia.org/wiki/SPDY>
 
> 4) If you change one character in a one MiB file, you have to serve one
> MiB to propagate that change to the client.

Not necessarily.  Besides, he who serves 1 MiB of script code has bigger 
problems than the one at hand; this is a fallacious argument.

-- 
PointedEars

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

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

#21743

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Eric Bednarz wrote:

>> 2) Loading a really large file is usually much less efficient than
>> loading several smaller files dynamically in parallel in most (more or
>> less) contemporary browsers. This might depend on the precise values of
>> 'several' and 'contemporary', of course.
>
> How did you get that idea?  You are also not considering that the number of 
> parallel HTTP requests is limited,

... to an average of 6 to 8 requests per hostname, these days. We were
talking about less than ten scripts. Map that to 'usually'.

> not only by HTTP/1.1 definitions,

But also by gut feeling. You're right, I didn't consider.

> and that even if parallel download is possible, parallel parsing is
> not.

As you would say, this is a fallacious argument. If you load /n/ scripts
in parallel in a non-blocking way and parse them sequentially, that's
usually faster because:

- one script can be parsed while another one downloads
- meanwhile, the DOM can be parsed, too

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

#21744

Eric Bednarz wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> Eric Bednarz wrote:
>>> 2) Loading a really large file is usually much less efficient than
>>> loading several smaller files dynamically in parallel in most (more or
>>> less) contemporary browsers. This might depend on the precise values of
>>> 'several' and 'contemporary', of course.
>>
>> How did you get that idea?  You are also not considering that the number
>> of parallel HTTP requests is limited,
> 
> ... to an average of 6 to 8 requests per hostname, these days.

How did you get that idea?

> We were talking about less than ten scripts.

Were we?

> Map that to 'usually'.

If we must go down that slippery road: unfortunately, the average script-
kiddie makes sure that “usually” means more than 9 by now.

>> not only by HTTP/1.1 definitions,
> 
> But also by gut feeling. You're right, I didn't consider.
> 
>> and that even if parallel download is possible, parallel parsing is
>> not.
> 
> As you would say, this is a fallacious argument. If you load /n/ scripts
> in parallel in a non-blocking way and parse them sequentially, that's
> usually faster because:
> 
> - one script can be parsed while another one downloads

No, in general it cannot.  As I have had to realize with regard to my code,

  /* part 1 */
  var f = function () {};

  /* part 2 */
  var f2 = (function () {
    /* function */
    var _f = f;

    return function () {
      return _f;
    };
  }());

has a different result than
  
  /* part 1 */
  var f2 = (function () {
    /* undefined */
    var _f = f;

    return function () {
      return _f;
    };
  }());

  /* part 2 */
  var f = function () {};

> - meanwhile, the DOM can be parsed, too

No, it (the _document_; the DOM is an *API* instead) cannot: Client-side 
scripts can modify the document while it is being parsed.  Therefore, it is 
BCP to put stylesheet references and stylesheets before client-side script 
references and client-side scripts (so that stylesheets can be applied while 
scripts are loaded and parsed), and to avoid document.write() in favor of 
.appendChild().  [The ES Matrix explicitly uses document.write() for 
backwards compatibility.]

There is one exception to this rule, and that is when the (formerly, 
proprietary) “defer” attribute is specified on the “script” element, *and* 
supported (but document.write() cannot be used there).

-- 
PointedEars

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

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

#21746

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Eric Bednarz wrote:
>
>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

>>> How did you get that idea?  You are also not considering that the number
>>> of parallel HTTP requests is limited,
>> 
>> ... to an average of 6 to 8 requests per hostname, these days.
>
> How did you get that idea?

Since you have namedropped Steve Souders at Jukka in this thread, there
you go:

http://www.browserscope.org/?category=network&v=top

>
>> We were talking about less than ten scripts.
>
> Were we?

If 'we' includes the OP, yes.

>> Map that to 'usually'.

>> - one script can be parsed while another one downloads
>
> No, in general it cannot.

Lazy parsers can, and do.

> As I have had to realize with regard to my code,
>
>   /* part 1 */
>   var f = function () {};
>
>   /* part 2 */
>   var f2 = (function () {
>     /* function */
>     var _f = f;
>
>     return function () {
>       return _f;
>     };
>   }());
>
> has a different result than
>   
>   /* part 1 */
>   var f2 = (function () {
>     /* undefined */

Try that in Chakra instead.

>     var _f = f;
>
>     return function () {
>       return _f;
>     };
>   }());
>
>   /* part 2 */
>   var f = function () {};

But even implementations that won't start producing the AST before all
pending scripts have been retrieved can benefit from parallel
loading. You have to take take care of correct execution order, of
course, but that's not difficult these days.

>> - meanwhile, the DOM can be parsed, too
>
> No, it (the _document_; the DOM is an *API* instead) cannot: Client-side 
> scripts can modify the document while it is being parsed.

Pardon? If you load script dynamically, the static document can be
incrementally rendered before the script has been retrieved and executed
(if your document is small enough, the injected scripts might even miss
the DOMContentLoaded event).

> There is one exception to this rule, and that is when the (formerly, 
> proprietary) “defer” attribute is specified on the “script” element, *and* 
> supported (but document.write() cannot be used there).

Ugh. Defer is utterly unsafe in Internet Explorer 9 and older if any but
the last deferred script modifies the DOM.

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

#21751

Eric Bednarz wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> Eric Bednarz wrote:
>>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>>> How did you get that idea?  You are also not considering that the
>>>> number of parallel HTTP requests is limited,
>>> ... to an average of 6 to 8 requests per hostname, these days.
>>
>> How did you get that idea?
> 
> Since you have namedropped Steve Souders at Jukka in this thread, there
> you go:
> 
> http://www.browserscope.org/?category=network&v=top

The test results are flawed.  Unsurpringly, that site is _not_ authored by 
Steve Souders who consciously speaks about *servers* (or hosts, if you 
prefer), _not_ host *names*.

>>> We were talking about less than ten scripts.
>>
>> Were we?
> 
> If 'we' includes the OP, yes.

,-<C76dnbrbpPTL3vfPnZ2dnUVZ5smdnZ2d@giganews.com>
| 
| I might want to import anywhere between 5-10 Javascript files (*.js) into
| one document.

As far as I am concerned, 10 is _not_ less 10.

>>> Map that to 'usually'.
>>> 
>>> - one script can be parsed while another one downloads
>> No, in general it cannot.
> 
> Lazy parsers can, and do.

How, and where?

>> As I have had to realize with regard to my code,
>>
>>   /* part 1 */
>>   var f = function () {};
>>
>>   /* part 2 */
>>   var f2 = (function () {
>>     /* function */
>>     var _f = f;
>>
>>     return function () {
>>       return _f;
>>     };
>>   }());
>>
>> has a different result than
>>   
>>   /* part 1 */
>>   var f2 = (function () {
>>     /* undefined */
> 
> Try that in Chakra instead.

Why should I, and in which version exactly?

>>     var _f = f;
>>
>>     return function () {
>>       return _f;
>>     };
>>   }());
>>
>>   /* part 2 */
>>   var f = function () {};
> 
> But even implementations that won't start producing the AST before all
> pending scripts have been retrieved can benefit from parallel
> loading.

No doubt about that.  It is, however, all based on the assumption that 
parallel loading of scripts can take place; that is, all the conditions that 
make this possible are met.  That is assuming a lot.

> You have to take take care of correct execution order,

*After* loading, yes.

> of course, but that's not difficult these days.

It never was.  The scripts must executed in HTML source code order unless 
“defer” is used.  Before that, all declarations in the global execution 
context have to be processed.

>>> - meanwhile, the DOM can be parsed, too
>>
>> No, it (the _document_; the DOM is an *API* instead) cannot: Client-side
>> scripts can modify the document while it is being parsed.
> 
> Pardon? If you load script dynamically, […]

You are confusing the issues here.
 
>> There is one exception to this rule, and that is when the (formerly,
>> proprietary) “defer” attribute is specified on the “script” element,
>> *and* supported (but document.write() cannot be used there).
> 
> Ugh. Defer is utterly unsafe in Internet Explorer 9 and older if any but
> the last deferred script modifies the DOM.

I believe I have said that.

-- 
PointedEars

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

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

#21753

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

>> http://www.browserscope.org/?category=network&v=top
                                         ^^^^^^^
> The test results are flawed.

Of course they are.

> Unsurpringly, that site is _not_ authored by 
> Steve Souders

| User:	stevesou...@gmail.com
| Role: Owner
| Duties:	
| * Lead by providing a project vision and roadmap
| * Have fun hacking and learn new stuff!
| * Component owner for "Network" tests
| Notes: Steve Souders

https://code.google.com/p/browserscope/people/detail?u=114676337053000557002

> who consciously speaks about *servers*

Ohhhhhhhhhhhhhm now I see. It's about *servers*, is it. So all you need
is a single hostname (or domain name, if you prefer) and a load balancer
to offload every request to a different *server*. And there you have it,
unlimited parallel connections.

> (or hosts, if you 
> prefer), _not_ host *names*.

Let's take a look in his latest blog post.

| You don’t need to setup different servers for each domain – just
| create CNAMEs. The browser doesn’t care about the final IP address –
| it only cares that the hostnames are different.

http://www.stevesouders.com/blog/2013/09/05/domain-sharding-revisited/

Constantly getting all this stuff wrong make me feel pretty exhausted,
I'll retire to my quarters now.

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

#21757

Eric Bednarz wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>> http://www.browserscope.org/?category=network&v=top
>                                          ^^^^^^^
>> The test results are flawed.
> 
> Of course they are.

Why “of course”?
 
>> Unsurpringly, that site is _not_ authored by Steve Souders
> 
> | User:	stevesou...@gmail.com
> | Role: Owner
> | Duties:
> | * Lead by providing a project vision and roadmap
> | * Have fun hacking and learn new stuff!
> | * Component owner for "Network" tests
> | Notes: Steve Souders
> 
> 
https://code.google.com/p/browserscope/people/detail?u=114676337053000557002

I stand corrected; but see below.
 
>> who consciously speaks about *servers*
> 
> Ohhhhhhhhhhhhhm now I see. It's about *servers*, is it. So all you need
> is a single hostname (or domain name, if you prefer) and a load balancer
> to offload every request to a different *server*. And there you have it,
> unlimited parallel connections.

You are not making sense.  Most certainly the number of HTTP connections an 
HTTP client can make is limited.
 
>> (or hosts, if you
>> prefer), _not_ host *names*.
> 
> Let's take a look in his latest blog post.
> 
> | You don’t need to setup different servers for each domain – just
> | create CNAMEs. The browser doesn’t care about the final IP address –
> | it only cares that the hostnames are different.
> 
> http://www.stevesouders.com/blog/2013/09/05/domain-sharding-revisited/

No rationale is being given there as to why HTTP connections should have 
anything to do with host names.  A few years earlier…

<http://www.stevesouders.com/blog/2008/03/20/roundup-on-parallel-connections/> pp.

| It’s likely that Firefox 3 will support 6 connections per server in an
| upcoming beta release, which means more discussion is expected.

| Section 8.1.4 of the HTTP/1.1 RFC says a “single-user client SHOULD NOT
| maintain more than 2 connections with any server or proxy.

| Opera and Safari hold that honor supporting 4 connections per server.

| The table below shows the number of connections per server supported by
| current browsers for HTTP/1.1 as well as HTTP/1.0.
| 
| Browser       HTTP/1.1  HTTP/1.0
| […]
| Opera 10.51+  8         ?

Compare that to the current table at BrowserScope:

| name      score  PerfTiming  Connections per Hostname
| Max Connections
| […]
| Opera 10  7/16   no          8
| 30

It is either the maximum number of connections per server/host or the 
maximum number of connections per hostname.  It cannot be both.

It is interesting, though, that there are two limits even per BrowserScope: 
the maximum number of connections “per Hostname” (or per _server_?) and the 
maximum number of (total) connections.

Whatever the numbers, we must assume that an HTTP connection is a scarce 
resource.  A developer should not use their users' resources needlessly.  
Wasting this resource in particular decreases the user experience because at 
some point other requests have to wait.

Therefore, in general it cannot be recommended to use many static script 
resources.  Which is why modular libraries usually come with a mechanism to 
avoid that, as Stefan has pointed out already.

-- 
PointedEars

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

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

#21745

On 2013-10-27 00:30, Eric Bednarz wrote:
> IMNSHO there's a lot wrong with that concatenated picture.
> 
> 1) What is 'large'? If you you have five script files between five and
> ten KiB, go ahead. But is it more efficient to load 500 KiB (or more)
> script synchronously before you can render anything at all instead of
> loading what you need in order to render the initial view first and
> lazy-load the rest?
> 
> 2) Loading a really large file is usually much less efficient than
> loading several smaller files dynamically in parallel in most (more or
> less) contemporary browsers. This might depend on the precise values of
> 'several' and 'contemporary', of course.
> 
> 3) If you happen to exclusively develop for UA's that already support
> SPDY, you're just waisting time anyway (or rather, you're being
> very productive shooting yourself in your foot).
> 
> 4) If you change one character in a one MiB file, you have to serve one
> MiB to propagate that change to the client. Most client-side code I've
> seen can be at least be split into:
> 
>   - third party vendor code (very infrequently or never updated)
>   - application core (updated when a bug has been found and fixed)
>   - end user feature set (frequently updated)
> 
> and to me it makes sense to separate and aggressively cache all of them.

I agree for the most part, I just didn't want to go into that much
detail in a reply to someone who's still learning the basics.

Performance tuning is an art. There is no one-fits-all solution, and
even if there was, it would become obsolete in a matter of months as new
technologies become available (like SPDY) and the balance of installed
user agents shifts (new iPhone, an OS end-of-lifing, etc).

There are just too many variables to give a generic recommendation. Are
the files large or small? Static or dynamic? Served from one host or
multiple hosts? Are we using public CDNs for popular libraries? What's
the chance that some of the files are already in the cache? How many
parallel script downloads does the average visitor's browser support?
How are the caches and proxies configured (on the server, the client, or
in between)? Are we serving over SSL? How many pages will the average
visitor load? Is there a class of visitors that should receive
preferential treatment? Is loading scripts even a noticable factor of
the overall site performance? Can we ignore certain legacy browsers?
When a script changes, how do we invalidate the client's cached version?
What's the expected network latency? Is this an intranet site? Or mostly
mobile? Is there a limit to the file size or number of files a client
will cache? What's the cost of a cache-related failure? Would it be
better to store some of the data in localStorage?

....and so on. That was just off the top of my head.

For high profile, high traffic sites, all of these questions (and more)
must be investigated and answered. Most sites (IMHO) can just to do
whatever they want and nobody will even notice.

All that said, I doubt that 10 separate script requests would really
perform better _on average_ than requesting one large file, large being
<200k. If the minified source code takes up more than that, we're
talking about a special case - or something perversely bloated, like
jQuery UI. Lazy-loading data is an option, of course, but also a special
case.
Even with client-side caching, the UA may periodically make requests,
and will likely get a 304 response, but those requests still takes time.
And it takes more time and bandwidth to make ten requests (plus headers)
than one. SPDY can definitely help here, but it's still a niche
protocol, mostly due to missing default server-side support.

Anecdote: Three years ago, I optimized the hell out of a site
(script-heavy, extranet, with ~20k unique visitors per month) as an
exercise. I read everything I found about the topic, including of course
the excellent books and articles by Steve Souders, and implemented what
I felt was the optimal solution at the time. It did have an effect, but
only if you were really paying attention. None of the users I talked to
noticed any significant difference with the optimizations enabled or
disabled. To make matters worse: a year later, the recommended "best"
solution was completely different.

Lesson learned: if it's fast enough, don't waste time micro-optimizing
it until someone complains. Until then, your time is better spent adding
features and eliminating bugs. With moderately current browsers and
hardware, and an acceptable internet connection, even the typical
non-optimized jQuery UI site with a zillion plugins will load fast enough.
If you suddenly "hit it big" with some project, there will be plenty of
time and funds to improve performance. But if you spend too much of your
time with premature optimization, the chances of hitting it big are small.


- stefan

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

#21747

Il 27/10/2013 02:01, Stefan Weiss ha scritto:

... a very nice post.
This is the kind of post a lurker like me enjoys mostly. An impartial 
view and some good hints coming through the personal direct experience.

Time ago, there was a debate here about asynchronous loading. I read all 
the posts but at the end of the tale was not able to extract much sense 
from that mess.
This clarifies a bit the picture.
Thanks Stefan
Dan

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

#22096

On Friday, October 25, 2013 3:09:54 AM UTC-7, Robert Crandal wrote:
> The "head" section of my HTML file imports multiple ".js" files
> 
> like this:
> 
> 
> 
> <head>
> 
> <script src="file1.js"></script>
> 
> <script src="file2.js"></script>
> 
> <script src="file3.js"></script>
> 
> '  ..... 
> 
> <script src="fileN.js"></script>
> 
> </head>
> 
> 
> 
> Is this the most common or best way to do this?  I might want
> 
> to import anywhere between 5-10 Javascript files (*.js) into
> 
> one document.
> 
> 
> 
> I'm just curious, because I'm still a newbie here.  Thank you!
> 
> 
> 
> Robert C.

If the scripts are static and loading the scripts is not conditional then you should combine as many of the scripts into a single file. Developing javascript for you web project using multiple files is a good way to keep things separate during the development phase. During deployment (imho) it is best to combine the scripts into single downloads.This also applies to CSS files also. 

mike.

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

#22099

nappysoft wrote:

> On Friday, October 25, 2013 3:09:54 AM UTC-7, Robert Crandal wrote:

Good morning, sunshine.

>> The "head" section of my HTML file imports multiple ".js" files
>> 
>> like this:
>> 
>> <head>
>> <script src="file1.js"></script>
>> <script src="file2.js"></script>
>> <script src="file3.js"></script>
>> '  .....
>> <script src="fileN.js"></script>
>> </head>
>> 
>> Is this the most common or best way to do this?  I might want
>> to import anywhere between 5-10 Javascript files (*.js) into
>> one document.
>> 
>> I'm just curious, because I'm still a newbie here.  Thank you!
> 
> If the scripts are static and loading the scripts is not conditional then
> you should combine as many of the scripts into a single file. Developing
> javascript for you web project using multiple files is a good way to keep
> things separate during the development phase. During deployment (imho) it
> is best to combine the scripts into single downloads.This also applies to
> CSS files also.

Caveat: Unfortunately, it is not Valid CSS (to the point of *not* *working*) 
for a stylesheet to have “@import” declarations that are not on the top.  
Any CSS compiler has to *parse* the stylesheets and take that into account.  
It is on the TODO list for my Resource Builder [1] already.

Spare us those interleaved empty lines, please.

_________
[1] <http://PointedEars.de/wsvn/JSX/builder.php>
-- 
PointedEars

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web