Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Importing multiple .js files
2,704 views
Skip to first unread message
Robert Crandal
Oct 25, 2013, 6:09:54 AM10/25/13
to
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.
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.
Stefan Weiss
Oct 25, 2013, 7:06:30 AM10/25/13
to
On 2013-10-25 12:09, 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.
It's the most common way. As for "best", that depends on your usage
> 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.
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.
Other common optimizations include source minification (see UglifyJS2
for an example) and a server configuration that allows these files to be
cached on the client between requests. Some libraries have build systems
to take care of the concatenation/minification for you.
- stefan
Thomas 'PointedEars' Lahn
Oct 25, 2013, 4:18:33 PM10/25/13
to
Stefan Weiss wrote:
> On 2013-10-25 12:09, 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.
>
> It's the most common way.
Unfortunately.
> On 2013-10-25 12:09, 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.
>
> 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.
assumed, loading scripts on an as-needed basis, such as with
jsx.importFrom() (blocking) or RequireJS-like approaches¹ (non-blocking,
with callback), is even more efficient. Even one large requested inline
script blocks parsing.
<http://PointedEars.de/wsvn/JSX/trunk/object.js>
<http://requirejs.org/>
_______
¹ not be misconstrued as an endorsement for RequireJS as such
> Other common optimizations include source minification (see UglifyJS2
> for an example) and a server configuration that allows these files to be
> cached on the client between requests. Some libraries have build systems
> to take care of the concatenation/minification for you.
ECMAScript code to be used with it. Default minimization is currently
limited to removing deactivating (single-line) and documentation comments
(but I have gotten a fair idea about removing unnecessary whitespace
automatically, maybe even without the full parser that I am writing for
JSdoc [I have a solution for HTML]), but that already reduces the size of
well-documented scripts down to 50%. Resource Builder is Free Software
and can be seen in action on my Web site.
<http://PointedEars.de/wsvn/JSX/trunk/builder.php>
--
PointedEars
Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
Jukka K. Korpela
Oct 25, 2013, 5:05:38 PM10/25/13
to
2013-10-25 23:18, the Lahn troll wrote:
> Unfortunately.
Without constructive advice, as usual.
> Exactly. However, if (and only if) a suitable target environment can be
> assumed,
Bla bla.
To address the question asked, there is no reason to worry about
referring to five javascript files if you need them. You might ask
yourself whether you really need them, but this is a different question.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
> Unfortunately.
Without constructive advice, as usual.
> Exactly. However, if (and only if) a suitable target environment can be
> assumed,
To address the question asked, there is no reason to worry about
referring to five javascript files if you need them. You might ask
yourself whether you really need them, but this is a different question.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Thomas 'PointedEars' Lahn
Oct 25, 2013, 5:54:08 PM10/25/13
to
Jukka K. Korpela wrote:
> 2013-10-25 23:18, the Lahn troll wrote:
>> Unfortunately.
>
> Without constructive advice, as usual.
Your reading problem is *your* problem.
> 2013-10-25 23:18, the Lahn troll wrote:
>> Unfortunately.
>
> Without constructive advice, as usual.
>> Exactly. However, if (and only if) a suitable target environment can be
>> assumed,
>
> Bla bla.
> To address the question asked, there is no reason to worry about
> referring to five javascript files if you need them.
their content and size, not number, is what matters.
> You might ask yourself whether you really need them, but this is a
> different question.
offer refund, do you not?
OTOH, he might instead want to listen to people who *really* know what they
are doing, *at least* in this respect; that includes Stefan, me, and for the
part relevant here, the authors of
<https://developers.google.com/speed/docs/best-practices/rules_intro>.
And, as an aspiring book author, you should also know your competition:
<http://stevesouders.com/>
IOW: Go away.
Eric Bednarz
Oct 26, 2013, 6:30:52 PM10/26/13
to
[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.
> 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.
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.
Thomas 'PointedEars' Lahn
Oct 26, 2013, 6:58:39 PM10/26/13
to
Eric Bednarz wrote:
> Stefan Weiss <krewe...@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.
> Stefan Weiss <krewe...@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?
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.
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).
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.
problems than the one at hand; this is a fallacious argument.
Eric Bednarz
Oct 26, 2013, 7:27:45 PM10/26/13
to
Thomas 'PointedEars' Lahn <Point...@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
> 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,
talking about less than ten scripts. Map that to 'usually'.
> not only by HTTP/1.1 definitions,
> and that even if parallel download is possible, parallel parsing is
> not.
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
Thomas 'PointedEars' Lahn
Oct 26, 2013, 8:37:37 PM10/26/13
to
Eric Bednarz wrote:
> Thomas 'PointedEars' Lahn <Point...@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?
> Thomas 'PointedEars' Lahn <Point...@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.
> Map that to 'usually'.
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
/* 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
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).
Stefan Weiss
Oct 26, 2013, 9:01:17 PM10/26/13
to
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
> 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.
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
Eric Bednarz
Oct 27, 2013, 4:49:26 AM10/27/13
to
Thomas 'PointedEars' Lahn <Point...@web.de> writes:
> Eric Bednarz wrote:
>
>> Thomas 'PointedEars' Lahn <Point...@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
> Eric Bednarz wrote:
>
>> Thomas 'PointedEars' Lahn <Point...@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?
you go:
http://www.browserscope.org/?category=network&v=top
>
>> We were talking about less than ten scripts.
>
> Were we?
>> Map that to 'usually'.
>> - one script can be parsed while another one downloads
>
> No, in general it cannot.
Lazy parsers can, and do.
>
> 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 () {};
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.
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).
the last deferred script modifies the DOM.
danca
Oct 27, 2013, 6:30:45 AM10/27/13
to
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
... 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
John Harris
Oct 27, 2013, 10:05:07 AM10/27/13
to
On Fri, 25 Oct 2013 23:54:08 +0200, Thomas 'PointedEars' Lahn
<Point...@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.
>and those are not files. They are resources, and
>their content and size, not number, is what matters.
Pascal defines a file to be a chunk of data that will be accessed
serially, regardless of how it's stored. That's what these chunks of
source code look like.
Of course, some resources are not files : the wood in the Black Forest
and the wind passing through a wind farm are resources but not files.
John
Thomas 'PointedEars' Lahn
Oct 27, 2013, 10:38:34 AM10/27/13
to
Eric Bednarz wrote:
> Thomas 'PointedEars' Lahn <Point...@web.de> writes:
>> Eric Bednarz wrote:
>>> Thomas 'PointedEars' Lahn <Point...@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
> Thomas 'PointedEars' Lahn <Point...@web.de> writes:
>> Eric Bednarz wrote:
>>> Thomas 'PointedEars' Lahn <Point...@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
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.
|
| 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.
| I might want to import anywhere between 5-10 Javascript files (*.js) into
| one document.
>>> 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.
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,
> of course, but that's not difficult these days.
“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.
>
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.
Eric Bednarz
Oct 27, 2013, 11:11:50 AM10/27/13
to
>> http://www.browserscope.org/?category=network&v=top
^^^^^^^
> 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.
^^^^^^^
> The test results are flawed.
Of course they are.
> Unsurpringly, that site is _not_ authored by
> Steve Souders
| 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*
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*.
| 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.
Christoph Michael Becker
Oct 27, 2013, 12:05:24 PM10/27/13
to
John Harris wrote:
>
> On Fri, 25 Oct 2013 23:54:08 +0200, Thomas 'PointedEars' Lahn
> <Point...@web.de> wrote:
>
> <snip>
>> There is no �javascript�,
>
> On Fri, 25 Oct 2013 23:54:08 +0200, Thomas 'PointedEars' Lahn
> <Point...@web.de> wrote:
>
> <snip>
>
> 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"?
> javascript : A convenient name for the group of programming
> languages that use most of the syntax and semantics described in
> ECMA 262.
>> and those are not files. They are resources, and
>> their content and size, not number, is what matters.
>
> <snip>
>
> Pascal defines a file to be a chunk of data that will be accessed
> serially, regardless of how it's stored.
However, Extended Pascal lifted that to cater for direct access.
> That's what these chunks of
> source code look like.
resource that is not stored as a file as such.
--
Christoph M. Becker
Thomas 'PointedEars' Lahn
Oct 27, 2013, 3:16:22 PM10/27/13
to
Eric Bednarz wrote:
> Thomas 'PointedEars' Lahn <Point...@web.de> writes:
>>> http://www.browserscope.org/?category=network&v=top
> ^^^^^^^
>> The test results are flawed.
>
> Of course they are.
Why “of course”?
> Thomas 'PointedEars' Lahn <Point...@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.
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/
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.
John Harris
Oct 28, 2013, 11:40:20 AM10/28/13
to
On Sun, 27 Oct 2013 17:05:24 +0100, Christoph Michael Becker
<cmbec...@arcor.de> wrote:
>John Harris wrote:
>>
>> On Fri, 25 Oct 2013 23:54:08 +0200, Thomas 'PointedEars' Lahn
>> <Point...@web.de> wrote:
>>
>> <snip>
>>> There is no “javascript”,
<cmbec...@arcor.de> wrote:
>John Harris wrote:
>>
>> On Fri, 25 Oct 2013 23:54:08 +0200, Thomas 'PointedEars' Lahn
>> <Point...@web.de> wrote:
>>
>> <snip>
>>
>> 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
>> 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"?
soon as you start talking about a DOM or a Filestore object you are
outside ECMAScript. And if you want to talk history you'll find
yourself talking about something which was current before ECMAScript
had a committee, let alone a published standard.
Also, at any one time there is only one ECMAScript, to wit the
language described in the *current* edition of ECMA 262. We talk about
many products with different implementations of different editions.
>>> and those are not files. They are resources, and
>>> their content and size, not number, is what matters.
>>
>> <snip>
>>
>> Pascal defines a file to be a chunk of data that will be accessed
>> serially, regardless of how it's stored.
>
>Indeed, this very limited definition is given by Standard Pascal.
>However, Extended Pascal lifted that to cater for direct access.
only how to supply the filenames that is limited.
>> That's what these chunks of
>> source code look like.
>Not necessarily. The src of a SCRIPT element may well point to a
>resource that is not stored as a file as such.
HTTP destination - it looks like a file, it walks like a file, and it
quacks like a file. There is nothing at all wrong about calling it a
file.
In a related context, people talk about documents, not about HTML
resources. Or do you want Document Object Model to be changed to HTML
Resource Object Model ?
John
Ben Bacarisse
Oct 28, 2013, 11:49:18 AM10/28/13
to
John Harris <ni...@jghnorth.org.uk.invalid> writes:
> On Sun, 27 Oct 2013 17:05:24 +0100, Christoph Michael Becker
> <cmbec...@arcor.de> wrote:
<snip>
> On Sun, 27 Oct 2013 17:05:24 +0100, Christoph Michael Becker
> <cmbec...@arcor.de> wrote:
>>Not necessarily. The src of a SCRIPT element may well point to a
>>resource that is not stored as a file as such.
>
> It doesn't matter what it is in the server. To the browser - or any
> HTTP destination - it looks like a file, it walks like a file, and it
> quacks like a file. There is nothing at all wrong about calling it a
> file.
It (the src of a script element) may have no existence on a server,
>>resource that is not stored as a file as such.
>
> It doesn't matter what it is in the server. To the browser - or any
> HTTP destination - it looks like a file, it walks like a file, and it
> quacks like a file. There is nothing at all wrong about calling it a
> file.
for example, if it's a data URI. For me, such a thing does not look,
walk or quack like a file, unless "file" becomes so general as to an
almost useless term.
> In a related context, people talk about documents, not about HTML
> resources. Or do you want Document Object Model to be changed to HTML
> Resource Object Model ?
distinction between the terms is a useful one. I admit it is one of
those distinctions that is in danger of vanishing, but that's not a
reason to hurry the process up!
--
Ben.
John Harris
Oct 29, 2013, 12:29:26 PM10/29/13
to
On Mon, 28 Oct 2013 15:49:18 +0000, Ben Bacarisse
<ben.u...@bsb.me.uk> wrote:
>John Harris <ni...@jghnorth.org.uk.invalid> writes:
>
>> On Sun, 27 Oct 2013 17:05:24 +0100, Christoph Michael Becker
>> <cmbec...@arcor.de> wrote:
><snip>
>>>Not necessarily. The src of a SCRIPT element may well point to a
>>>resource that is not stored as a file as such.
>>
>> It doesn't matter what it is in the server. To the browser - or any
>> HTTP destination - it looks like a file, it walks like a file, and it
>> quacks like a file. There is nothing at all wrong about calling it a
>> file.
>
>It (the src of a script element) may have no existence on a server,
>for example, if it's a data URI. For me, such a thing does not look,
>walk or quack like a file, unless "file" becomes so general as to an
>almost useless term.
In the server it can look like anything or nothing. In the object that
<ben.u...@bsb.me.uk> wrote:
>John Harris <ni...@jghnorth.org.uk.invalid> writes:
>
>> On Sun, 27 Oct 2013 17:05:24 +0100, Christoph Michael Becker
>> <cmbec...@arcor.de> wrote:
><snip>
>>>Not necessarily. The src of a SCRIPT element may well point to a
>>>resource that is not stored as a file as such.
>>
>> It doesn't matter what it is in the server. To the browser - or any
>> HTTP destination - it looks like a file, it walks like a file, and it
>> quacks like a file. There is nothing at all wrong about calling it a
>> file.
>
>It (the src of a script element) may have no existence on a server,
>for example, if it's a data URI. For me, such a thing does not look,
>walk or quack like a file, unless "file" becomes so general as to an
>almost useless term.
sent the URI what comes back is something that looks like a very
familiar data structure. You can choose to call it an array of bytes
if you like, but calling it a file is not wrong.
>> In a related context, people talk about documents, not about HTML
>> resources. Or do you want Document Object Model to be changed to HTML
>> Resource Object Model ?
>
>The resource generates a document inside a browser so, for me, the
>distinction between the terms is a useful one. I admit it is one of
>those distinctions that is in danger of vanishing, but that's not a
>reason to hurry the process up!
document, and it quacks like a document, so it's safe to call it a
document.
John
Ben Bacarisse
Oct 29, 2013, 4:41:08 PM10/29/13
to
John Harris <ni...@jghnorth.org.uk.invalid> writes:
> On Mon, 28 Oct 2013 15:49:18 +0000, Ben Bacarisse
> <ben.u...@bsb.me.uk> wrote:
>
>>John Harris <ni...@jghnorth.org.uk.invalid> writes:
<snip>
> On Mon, 28 Oct 2013 15:49:18 +0000, Ben Bacarisse
> <ben.u...@bsb.me.uk> wrote:
>
>>John Harris <ni...@jghnorth.org.uk.invalid> writes:
>>> It doesn't matter what it is in the server. To the browser - or any
>>> HTTP destination - it looks like a file, it walks like a file, and it
>>> quacks like a file. There is nothing at all wrong about calling it a
>>> file.
>>
>>It (the src of a script element) may have no existence on a server,
>>for example, if it's a data URI. For me, such a thing does not look,
>>walk or quack like a file, unless "file" becomes so general as to an
>>almost useless term.
>
> In the server it can look like anything or nothing. In the object that
> sent the URI what comes back is something that looks like a very
> familiar data structure. You can choose to call it an array of bytes
> if you like, but calling it a file is not wrong.
I don't understand "in the object that sent the URI" and "what comes
>>> HTTP destination - it looks like a file, it walks like a file, and it
>>> quacks like a file. There is nothing at all wrong about calling it a
>>> file.
>>
>>It (the src of a script element) may have no existence on a server,
>>for example, if it's a data URI. For me, such a thing does not look,
>>walk or quack like a file, unless "file" becomes so general as to an
>>almost useless term.
>
> In the server it can look like anything or nothing. In the object that
> sent the URI what comes back is something that looks like a very
> familiar data structure. You can choose to call it an array of bytes
> if you like, but calling it a file is not wrong.
back" so I'm not sure what you mean. In this example
<script src="data:,document.write('hi')"></script>
I think it is really stretching the meaning of the word to call the
resource a file (or, to use other terminology, to say that the URI
refers to a file).
>>> In a related context, people talk about documents, not about HTML
>>> resources. Or do you want Document Object Model to be changed to HTML
>>> Resource Object Model ?
>>
>>The resource generates a document inside a browser so, for me, the
>>distinction between the terms is a useful one. I admit it is one of
>>those distinctions that is in danger of vanishing, but that's not a
>>reason to hurry the process up!
>
> In other words, in your view it looks like a document, it walks like a
> document, and it quacks like a document, so it's safe to call it a
> document.
mean between the words -- the concepts remain very different. For one
thing, many resources are not documents in the HTML sense (at least,
that's how I understand the terms).
--
Ben.
Christoph Michael Becker
Oct 29, 2013, 5:13:24 PM10/29/13
to
John Harris wrote:
> On Sun, 27 Oct 2013 17:05:24 +0100, Christoph Michael Becker
> <cmbec...@arcor.de> wrote:
>
>> John Harris wrote:
>>>
>>> On Fri, 25 Oct 2013 23:54:08 +0200, Thomas 'PointedEars' Lahn
>>> <Point...@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
> On Sun, 27 Oct 2013 17:05:24 +0100, Christoph Michael Becker
> <cmbec...@arcor.de> wrote:
>
>> John Harris wrote:
>>>
>>> On Fri, 25 Oct 2013 23:54:08 +0200, Thomas 'PointedEars' Lahn
>>> <Point...@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.
adjust the definition of "javascript" you gave above.
Anyway, even this NG's FAQ gives a much more restricted definition of
the term "javascript"[1]:
| For historical reasons, the term “javascript” is used herein as a
| shorthand for “ECMAScript-based programming languages”.
> And if you want to talk history you'll find
> yourself talking about something which was current before ECMAScript
> had a committee, let alone a published standard.
>
> Also, at any one time there is only one ECMAScript, to wit the
> language described in the *current* edition of ECMA 262.
> We talk about
> many products with different implementations of different editions.
>
>
>>>> and those are not files. They are resources, and
>>>> their content and size, not number, is what matters.
>>>
>>> <snip>
>>>
>>> Pascal defines a file to be a chunk of data that will be accessed
>>> serially, regardless of how it's stored.
>>
>> Indeed, this very limited definition is given by Standard Pascal.
>> However, Extended Pascal lifted that to cater for direct access.
>
> Actually, Standard Pascal allows files to be outside the program. It's
> only how to supply the filenames that is limited.
Standard Pascal only defines sequential access, but not direct access[2]
(which seems to be a rather important concept).
>
>>> That's what these chunks of
>>> source code look like.
>
>> Not necessarily. The src of a SCRIPT element may well point to a
>> resource that is not stored as a file as such.
>
> It doesn't matter what it is in the server. To the browser - or any
> HTTP destination - it looks like a file, it walks like a file, and it
> quacks like a file. There is nothing at all wrong about calling it a
> file.
reading RFC 2616[4].
>
> In a related context, people talk about documents, not about HTML
> resources. Or do you want Document Object Model to be changed to HTML
> Resource Object Model ?
No, of course not. I am aware that the DOM is not restricted to HTML
> In a related context, people talk about documents, not about HTML
> resources. Or do you want Document Object Model to be changed to HTML
> Resource Object Model ?
documents, as well as "document" and "file" are different concepts (even
if a document can be stored in a file).
[1] <http://jibbering.com/faq/#ecma>
Actually taken from <http://pointedears.de/scripts/faq/cljs/#ecma>
as jibbering.com is currently down.
[2] <http://en.wikipedia.org/wiki/Random_access>
[3] <http://en.wikipedia.org/wiki/Computer_file>
[4] <http://www.ietf.org/rfc/rfc2616.txt>
--
Christoph M. Becker
Thomas 'PointedEars' Lahn
Oct 29, 2013, 7:50:09 PM10/29/13
to
Christoph Michael Becker wrote:
> John Harris wrote:
>> Christoph Michael Becker […] wrote:
>>> John Harris wrote:
hosted at my site, and edited by me with the support of contributors, “this
NG's FAQ”; for that is my goal. However, to be fair, this particular
paragraph is the result of my editing the misleading and with regard to some
original FAQ sections actually *wrong* definition in what some still
consider “this NG's FAQ” – even though it is flawed, three years outdated,
and has gone unmaintained for the same amount of time.
I have said so here a few weeks ago, and you can see it in the changelog.
Nevertheless, of all the definitions that people here could _not_ agree on
(and there is *none* that people here could agree on), this is the one
that – as I interpret it from the rest of the text – meets the intentions of
the original authors best. The times where DOM/AOM API features have been
part of any of the programming languages are long gone, and it is confusing
to beginners, not helpful, to insist that they have not.
> [1] <http://jibbering.com/faq/#ecma>
> Actually taken from <http://pointedears.de/scripts/faq/cljs/#ecma>
> as jibbering.com is currently down.
^^^^^^^^^^^^^^^^^
Once again, unfortunately. I am satisfied to report that downtimes of my
site, thus of the FAQ for comp.lang.javascript, have been few this year by
comparison (so far I am looking at a 97.5% connection success rate by
Googlebot – that amounts to only 9 days downtime within 360 days – and I am
hoping to increase that rate).
>> And if you want to talk history you'll find
>> yourself talking about something which was current before ECMAScript
>> had a committee, let alone a published standard.
>>
>> Also, at any one time there is only one ECMAScript, to wit the
>> language described in the *current* edition of ECMA 262.
>
> So at any one time there is only one Microsoft Windows?
Of course, most certainly there never will be only one ECMAScript; it is but
a standard, a set of formal rules for programming languages, designed to be
implemented in source code (in the same or another programming language).
As implementors will continue to compete, will have a different user base
and different systems whose “facilities” need to be “manipulate[d],
customise[d], and automate[d]” [1] with their implementation, there will
most certainly always be differences in the implementations, resulting in
different programming languages. Add to that the differences in object
models like the DOM, for the very same reasons.
Differences will be probably less than before (you can see a development
towards standardization), but I find it unlikely that they will disappear.
Some implementators will have ideas for new features that others are slow to
implement; for example, I have noted (in my thesis) that in Mozilla
JavaScript *only*, syntactical features known from Python have been added.
Finally, there is “Harmony” (ECMAScript Edition 6) to consider, and how all
that potential syntactic sugar is going to change the implementation
landscape *again*.
_________
[1] Ecma International (2011-06). ECMA-262, 5.1 Edition.
ECMAScript Language Specification. Section 4, “Overview”. p. 1.
> John Harris wrote:
>> Christoph Michael Becker […] wrote:
>>> John Harris wrote:
>>>> Thomas 'PointedEars' Lahn […] wrote:
>>>>> 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.
>
> Anyway, even this NG's FAQ gives a much more restricted definition of
> the term "javascript"[1]:
>
> | For historical reasons, the term “javascript” is used herein as a
> | shorthand for “ECMAScript-based programming languages”.
I appreciate that your already calling the FAQ for comp.lang.javascript
>>>>> 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.
>
> Anyway, even this NG's FAQ gives a much more restricted definition of
> the term "javascript"[1]:
>
> | For historical reasons, the term “javascript” is used herein as a
> | shorthand for “ECMAScript-based programming languages”.
hosted at my site, and edited by me with the support of contributors, “this
NG's FAQ”; for that is my goal. However, to be fair, this particular
paragraph is the result of my editing the misleading and with regard to some
original FAQ sections actually *wrong* definition in what some still
consider “this NG's FAQ” – even though it is flawed, three years outdated,
and has gone unmaintained for the same amount of time.
I have said so here a few weeks ago, and you can see it in the changelog.
Nevertheless, of all the definitions that people here could _not_ agree on
(and there is *none* that people here could agree on), this is the one
that – as I interpret it from the rest of the text – meets the intentions of
the original authors best. The times where DOM/AOM API features have been
part of any of the programming languages are long gone, and it is confusing
to beginners, not helpful, to insist that they have not.
> [1] <http://jibbering.com/faq/#ecma>
> Actually taken from <http://pointedears.de/scripts/faq/cljs/#ecma>
> as jibbering.com is currently down.
Once again, unfortunately. I am satisfied to report that downtimes of my
site, thus of the FAQ for comp.lang.javascript, have been few this year by
comparison (so far I am looking at a 97.5% connection success rate by
Googlebot – that amounts to only 9 days downtime within 360 days – and I am
hoping to increase that rate).
>> And if you want to talk history you'll find
>> yourself talking about something which was current before ECMAScript
>> had a committee, let alone a published standard.
>>
>> Also, at any one time there is only one ECMAScript, to wit the
>> language described in the *current* edition of ECMA 262.
>
> So at any one time there is only one Microsoft Windows?
a standard, a set of formal rules for programming languages, designed to be
implemented in source code (in the same or another programming language).
As implementors will continue to compete, will have a different user base
and different systems whose “facilities” need to be “manipulate[d],
customise[d], and automate[d]” [1] with their implementation, there will
most certainly always be differences in the implementations, resulting in
different programming languages. Add to that the differences in object
models like the DOM, for the very same reasons.
Differences will be probably less than before (you can see a development
towards standardization), but I find it unlikely that they will disappear.
Some implementators will have ideas for new features that others are slow to
implement; for example, I have noted (in my thesis) that in Mozilla
JavaScript *only*, syntactical features known from Python have been added.
Finally, there is “Harmony” (ECMAScript Edition 6) to consider, and how all
that potential syntactic sugar is going to change the implementation
landscape *again*.
_________
[1] Ecma International (2011-06). ECMA-262, 5.1 Edition.
ECMAScript Language Specification. Section 4, “Overview”. p. 1.
John Harris
Oct 31, 2013, 5:31:45 AM10/31/13
to
On Tue, 29 Oct 2013 20:41:08 +0000, Ben Bacarisse
data (if you're lucky).
For any other protocol you still have one thing sending a URI, and
another thing sending data back.
> <script src="data:,document.write('hi')"></script>
>
>I think it is really stretching the meaning of the word to call the
>resource a file (or, to use other terminology, to say that the URI
>refers to a file).
<snip>
Do you really think the parser can tell the difference? My guess is
that the parser is handed a stream and gets its characters from the
stream without knowing or caring how the characters got there. It is
an OOP world after all.
John
>> In the server it can look like anything or nothing. In the object that
>> sent the URI what comes back is something that looks like a very
>> familiar data structure. You can choose to call it an array of bytes
>> if you like, but calling it a file is not wrong.
>
>I don't understand "in the object that sent the URI" and "what comes
>back" so I'm not sure what you mean. In this example
In an HTTP connection one end sends a URI and the other end returns
>> sent the URI what comes back is something that looks like a very
>> familiar data structure. You can choose to call it an array of bytes
>> if you like, but calling it a file is not wrong.
>
>I don't understand "in the object that sent the URI" and "what comes
>back" so I'm not sure what you mean. In this example
data (if you're lucky).
For any other protocol you still have one thing sending a URI, and
another thing sending data back.
> <script src="data:,document.write('hi')"></script>
>
>I think it is really stretching the meaning of the word to call the
>resource a file (or, to use other terminology, to say that the URI
>refers to a file).
Do you really think the parser can tell the difference? My guess is
that the parser is handed a stream and gets its characters from the
stream without knowing or caring how the characters got there. It is
an OOP world after all.
John
Ben Bacarisse
Oct 31, 2013, 9:30:17 AM10/31/13
to
John Harris <ni...@jghnorth.org.uk.invalid> writes:
> On Tue, 29 Oct 2013 20:41:08 +0000, Ben Bacarisse
> <ben.u...@bsb.me.uk> wrote:
>
>>John Harris <ni...@jghnorth.org.uk.invalid> writes:
>
> <snip>
>>> In the server it can look like anything or nothing. In the object that
>>> sent the URI what comes back is something that looks like a very
>>> familiar data structure. You can choose to call it an array of bytes
>>> if you like, but calling it a file is not wrong.
>>
>>I don't understand "in the object that sent the URI" and "what comes
>>back" so I'm not sure what you mean. In this example
>
> In an HTTP connection one end sends a URI and the other end returns
> data (if you're lucky).
>
> For any other protocol you still have one thing sending a URI, and
> another thing sending data back.
Obviously I disagree. I don't think the terms "sending a URI" and
> On Tue, 29 Oct 2013 20:41:08 +0000, Ben Bacarisse
> <ben.u...@bsb.me.uk> wrote:
>
>>John Harris <ni...@jghnorth.org.uk.invalid> writes:
>
> <snip>
>>> In the server it can look like anything or nothing. In the object that
>>> sent the URI what comes back is something that looks like a very
>>> familiar data structure. You can choose to call it an array of bytes
>>> if you like, but calling it a file is not wrong.
>>
>>I don't understand "in the object that sent the URI" and "what comes
>>back" so I'm not sure what you mean. In this example
>
> In an HTTP connection one end sends a URI and the other end returns
> data (if you're lucky).
>
> For any other protocol you still have one thing sending a URI, and
> another thing sending data back.
"sending data back" make sense for a data URI or I would have understood
what you wrote first time round. To make that description fit, you have
to invent some entity to which to which the URI is sent, which just
complicates an otherwise simple model: a URI refers to a resource, and
the protocol part specifies how that resource is accessed.
But even if you take that view, in what sense is the resource a file?
Sure, a file can be viewed as a sequence of bytes, but that does not
mean it's helpful to call everything that can be viewed as a sequence of
bytes a file. Files have other properties that make them different from
strings and byte streams.
>> <script src="data:,document.write('hi')"></script>
>>
>>I think it is really stretching the meaning of the word to call the
>>resource a file (or, to use other terminology, to say that the URI
>>refers to a file).
> <snip>
>
> Do you really think the parser can tell the difference? My guess is
> that the parser is handed a stream and gets its characters from the
> stream without knowing or caring how the characters got there. It is
> an OOP world after all.
subset of operations between things different object types. It does not
make the things the same. The concept of a file is rather nebulous, but
it's more than "can have bytes pulled from it in sequence".
--
Ben.
John Harris
Oct 31, 2013, 11:52:16 AM10/31/13
to
On Wed, 30 Oct 2013 00:50:09 +0100, Thomas 'PointedEars' Lahn
<Point...@web.de> wrote:
>Christoph Michael Becker wrote:
<snip>
<Point...@web.de> wrote:
>Christoph Michael Becker wrote:
>> Anyway, even this NG's FAQ gives a much more restricted definition of
>> the term "javascript"[1]:
>>
>> | For historical reasons, the term “javascript” is used herein as a
>> | shorthand for “ECMAScript-based programming languages”.
>
>I appreciate that your already calling the FAQ for comp.lang.javascript
>hosted at my site, and edited by me with the support of contributors, “this
>NG's FAQ”; for that is my goal. However, to be fair, this particular
>paragraph is the result of my editing the misleading and with regard to some
>original FAQ sections actually *wrong* definition
<snip>
>> the term "javascript"[1]:
>>
>> | For historical reasons, the term “javascript” is used herein as a
>> | shorthand for “ECMAScript-based programming languages”.
>
>I appreciate that your already calling the FAQ for comp.lang.javascript
>hosted at my site, and edited by me with the support of contributors, “this
>NG's FAQ”; for that is my goal. However, to be fair, this particular
>paragraph is the result of my editing the misleading and with regard to some
>original FAQ sections actually *wrong* definition
...
Thomas did this change without posting a proposal for discussion in
this news group. No-one had an opportunity to disagree with the
change, or even agree with it. This does not bode well for the future.
John
Thomas 'PointedEars' Lahn
Oct 31, 2013, 12:19:40 PM10/31/13
to
Christoph Michael Becker
Oct 31, 2013, 1:34:40 PM10/31/13
to
<2377471.k...@PointedEars.de> (a discussion in which you have been
involved).
--
Christoph M. Becker
Jukka K. Korpela
Oct 31, 2013, 2:36:32 PM10/31/13
to
2013-10-31 19:34, Christoph Michael Becker wrote:
> Thomas has mentioned and justified this change in
> <2377471.k...@PointedEars.de>
Do you seriously think that Message-IDs are generally useful in 2013? Or
> Thomas has mentioned and justified this change in
> <2377471.k...@PointedEars.de>
don’t you just care?
How does your posting address the question about “Importing multiple .s
files”, the Subject line under which you are writing?
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”.
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.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Christoph Michael Becker
Oct 31, 2013, 3:33:21 PM10/31/13
to
Jukka K. Korpela wrote:
> 2013-10-31 19:34, Christoph Michael Becker wrote:
>
>> Thomas has mentioned and justified this change in
>> <2377471.k...@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
> 2013-10-31 19:34, Christoph Michael Becker wrote:
>
>> Thomas has mentioned and justified this change in
>> <2377471.k...@PointedEars.de>
>
> Do you seriously think that Message-IDs are generally useful in 2013? Or
> don’t you just care?
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?
> 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”.
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.
--
Christoph M. Becker
John Harris
Nov 1, 2013, 11:12:54 AM11/1/13
to
On Tue, 29 Oct 2013 22:13:24 +0100, Christoph Michael Becker
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
<cmbec...@arcor.de> wrote:
>John Harris wrote:
>
>> On Sun, 27 Oct 2013 17:05:24 +0100, Christoph Michael Becker
>> <cmbec...@arcor.de> wrote:
>>
>>> John Harris wrote:
>>>>
>>>> On Fri, 25 Oct 2013 23:54:08 +0200, Thomas 'PointedEars' Lahn
>>>> <Point...@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>
>John Harris wrote:
>
>> On Sun, 27 Oct 2013 17:05:24 +0100, Christoph Michael Becker
>> <cmbec...@arcor.de> wrote:
>>
>>> John Harris wrote:
>>>>
>>>> On Fri, 25 Oct 2013 23:54:08 +0200, Thomas 'PointedEars' Lahn
>>>> <Point...@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.
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
John Harris
Nov 1, 2013, 11:27:36 AM11/1/13
to
On Thu, 31 Oct 2013 17:19:40 +0100, Thomas 'PointedEars' Lahn
>>>> | shorthand for ?ECMAScript-based programming languages?.
I propose to replace
<quote>
by
<quote>
Comments invited.
did you? When, or which ID?
John
<Point...@web.de> wrote:
>John Harris wrote:
>
>> On Wed, 30 Oct 2013 00:50:09 +0100, Thomas 'PointedEars' Lahn
>> <Point...@web.de> wrote:
>>> Christoph Michael Becker wrote:
>> <snip>
>>>> Anyway, even this NG's FAQ gives a much more restricted definition of
>>>> the term "javascript"[1]:
>>>>
>>>> | For historical reasons, the term ?javascript? is used herein as a
>John Harris wrote:
>
>> On Wed, 30 Oct 2013 00:50:09 +0100, Thomas 'PointedEars' Lahn
>> <Point...@web.de> wrote:
>>> Christoph Michael Becker wrote:
>> <snip>
>>>> Anyway, even this NG's FAQ gives a much more restricted definition of
>>>> the term "javascript"[1]:
>>>>
>>>> | shorthand for ?ECMAScript-based programming languages?.
>>>
>>> I appreciate that your already calling the FAQ for comp.lang.javascript
>>> hosted at my site, and edited by me with the support of contributors,
>>> ?this NG's FAQ?; for that is my goal. However, to be fair, this
>>> I appreciate that your already calling the FAQ for comp.lang.javascript
>>> hosted at my site, and edited by me with the support of contributors,
>>> particular paragraph is the result of my editing the misleading and with
>>> regard to some original FAQ sections actually *wrong* definition
>> <snip>
>> ...
>>
>> Thomas did this change without posting a proposal for discussion in
>> this news group. No-one had an opportunity to disagree with the
>> change, or even agree with it. This does not bode well for the future.
>
>You are a master of selective perception.
So you posted an article to this news group saying something like
>>> regard to some original FAQ sections actually *wrong* definition
>> <snip>
>> ...
>>
>> Thomas did this change without posting a proposal for discussion in
>> this news group. No-one had an opportunity to disagree with the
>> change, or even agree with it. This does not bode well for the future.
>
>You are a master of selective perception.
I propose to replace
<quote>
by
<quote>
Comments invited.
did you? When, or which ID?
John
Christoph Michael Becker
Nov 4, 2013, 12:36:53 PM11/4/13
to
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.
Date and Functions objects are (at least since the third edition of
ECMA-262).
--
Christoph M. Becker
Thomas 'PointedEars' Lahn
Nov 4, 2013, 8:41:43 PM11/4/13
to
> 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).
<http://PointedEars.de/es-matrix/?filter=Date%7CFunction>
Thomas 'PointedEars' Lahn
Nov 6, 2013, 6:20:48 AM11/6/13
to
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.k...@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
> Jukka K. Korpela wrote:
>> 2013-10-31 19:34, Christoph Michael Becker wrote:
>>> Thomas has mentioned and justified this change in
>>> <2377471.k...@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]
those: <news:2377471.k...@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.)
> […]
Thomas 'PointedEars' Lahn
Nov 6, 2013, 8:33:56 AM11/6/13
to
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.k...@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.k...@PointedEars.de>. […]
> 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.k...@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
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>
:)
nappysoft
Nov 21, 2013, 8:53:28 AM11/21/13
to
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
>
>
>
> 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.
> 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!
> to import anywhere between 5-10 Javascript files (*.js) into
>
> one document.
>
>
>
>
>
>
> 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.
Thomas 'PointedEars' Lahn
Nov 21, 2013, 10:15:08 AM11/21/13
to
nappysoft wrote:
> On Friday, October 25, 2013 3:09:54 AM UTC-7, Robert Crandal wrote:
Good morning, sunshine.
> 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!
>
> 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*)
> 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.
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>
0 new messages