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 1 of 2  [1] 2  Next page →

#21723 — Importing multiple .js files

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.

[toc] | [next] | [standalone]

#21724

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.
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

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

#21728

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.

> 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.

No, that would be more efficient and advisable in any case, see below.

> Ten <script> elements means ten requests
> to the server. Requesting one large file is more efficient than
> requesting ten separate smaller ones.

Exactly.  However, if (and only if) a suitable target environment can be 
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.

JSX includes Resource Builder without requiring it, nor requiring JSX 
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.

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

#21730

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/

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

#21733

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.
 
>> Exactly.  However, if (and only if) a suitable target environment can be
>> assumed,
> 
> Bla bla.

My, are we eloquent tonight.
 
> To address the question asked, there is no reason to worry about
> referring to five javascript files if you need them.

There is no “javascript”, and those are not files.  They are resources, and 
their content and size, not number, is what matters.

> You might ask yourself whether you really need them, but this is a
> different question.

The OP will be happy to have your personal guarantee for it.  For you do 
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.

-- 
PointedEars

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

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

#21749

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.


>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. 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

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

#21755

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"?

>> 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.

>                                           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.

-- 
Christoph M. Becker

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

#21762

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. 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.


>>                                           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.

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

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

#21763

John Harris <niam@jghnorth.org.uk.invalid> writes:

> On Sun, 27 Oct 2013 17:05:24 +0100, Christoph Michael Becker
> <cmbecker69@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 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!

-- 
Ben.

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

#21777

On Mon, 28 Oct 2013 15:49:18 +0000, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:

>John Harris <niam@jghnorth.org.uk.invalid> writes:
>
>> On Sun, 27 Oct 2013 17:05:24 +0100, Christoph Michael Becker
>> <cmbecker69@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
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!

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.

  John

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

#21781

John Harris <niam@jghnorth.org.uk.invalid> writes:

> On Mon, 28 Oct 2013 15:49:18 +0000, Ben Bacarisse
> <ben.usenet@bsb.me.uk> wrote:
>
>>John Harris <niam@jghnorth.org.uk.invalid> writes:
<snip>
>>> 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
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.

No, I don't think so.  When I say that the distinction is vanishing, I
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.

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

#21796

On Tue, 29 Oct 2013 20:41:08 +0000, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:

>John Harris <niam@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.


>  <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

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

#21797

John Harris <niam@jghnorth.org.uk.invalid> writes:

> On Tue, 29 Oct 2013 20:41:08 +0000, Ben Bacarisse
> <ben.usenet@bsb.me.uk> wrote:
>
>>John Harris <niam@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
"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.

The purpose of a software design like that is to find a minimal common
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.

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

#21782

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.

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.

So at any one time there is only one Microsoft Windows?

>                                                           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.

I was talking about the restriction regarding the access to files.
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.

You may consider looking up a definition of "file" (e.g. [3]) and
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
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

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

#21783

Christoph Michael Becker wrote:

> 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 
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.
-- 
PointedEars

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

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

#21798

On Wed, 30 Oct 2013 00:50:09 +0100, Thomas 'PointedEars' Lahn
<PointedEars@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
>> | 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>
 ...

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

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

#21799

John Harris wrote:

> On Wed, 30 Oct 2013 00:50:09 +0100, Thomas 'PointedEars' Lahn
> <PointedEars@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
>>> | 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>
>  ...
> 
> 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.

-- 
PointedEars

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

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

#21814

On Thu, 31 Oct 2013 17:19:40 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>John Harris wrote:
>
>> On Wed, 30 Oct 2013 00:50:09 +0100, Thomas 'PointedEars' Lahn
>> <PointedEars@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
>>>> | 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>
>>  ...
>> 
>> 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

  I propose to replace
    <quote>
  by
    <quote>
  Comments invited.

did you? When, or which ID?

  John

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

#21800

John Harris wrote:

> On Wed, 30 Oct 2013 00:50:09 +0100, Thomas 'PointedEars' Lahn
> <PointedEars@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
>>> | 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>
>  ...
> 
> 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.

Thomas has mentioned and justified this change in
<2377471.k03CVt3Ec2@PointedEars.de> (a discussion in which you have been
involved).

-- 
Christoph M. Becker

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

#21801

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?

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/

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web