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

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

30 Years Of JavaScript

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

Contents

  30 Years Of JavaScript Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-24 01:52 +0000
    Re: 30 Years Of JavaScript Mikko <mikko.levanto@iki.fi> - 2026-07-13 16:12 +0300
      Re: 30 Years Of JavaScript Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-13 22:31 +0000
        Re: 30 Years Of JavaScript Mikko <mikko.levanto@iki.fi> - 2026-07-14 09:59 +0300
          Re: 30 Years Of JavaScript Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-14 07:27 +0000
          Re: 30 Years Of JavaScript Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2026-07-18 04:51 +0200
      Re: 30 Years Of JavaScript John Harris <niam@jghnorth.org.uk.invalid> - 2026-07-14 10:50 +0100
        Re: 30 Years Of JavaScript Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-14 22:12 +0000
          Re: 30 Years Of JavaScript John Harris <niam@jghnorth.org.uk.invalid> - 2026-07-15 11:01 +0100
      Re: 30 Years Of JavaScript Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2026-07-18 04:46 +0200
        Re: 30 Years Of JavaScript Mikko <mikko.levanto@iki.fi> - 2026-07-19 11:40 +0300
          Re: 30 Years Of JavaScript Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-19 23:29 +0000
            Re: 30 Years Of JavaScript Mikko <mikko.levanto@iki.fi> - 2026-07-20 09:42 +0300
              Re: 30 Years Of JavaScript Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-20 08:08 +0000
                Re: 30 Years Of JavaScript Mikko <mikko.levanto@iki.fi> - 2026-07-21 08:57 +0300
                  Re: 30 Years Of JavaScript Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-21 23:08 +0000
                    Re: 30 Years Of JavaScript Mikko <mikko.levanto@iki.fi> - 2026-07-22 09:39 +0300
              Re: 30 Years Of JavaScript Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2026-07-27 14:20 +0200
          Re: 30 Years Of JavaScript Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2026-07-27 14:19 +0200
    Re: 30 Years Of JavaScript Jon Ribbens <jon+usenet@unequivocal.eu> - 2026-07-13 14:46 +0000

#124392 — 30 Years Of JavaScript

OK, so the actual anniversary was back in March. But I just
(re)discovered the InfoWorld site, and was surprised to discover it
has become such a software-development-focused place (was it before?).

This article
<https://www.infoworld.com/article/3836901/10-things-developers-love-about-javascript-and-10-things-they-dont.html>
goes over some of the things the author(s) love about JavaScript, and
some things they don’t.

In terms of punctuation, didn’t they know semicolons (at least as
statement terminators) are optional in JavaScript? Yes, the rule is a
bit more subtle than in Python, but even I, a Python programmer, was
able to figure it out.

Type conversion: this I do not love. Being able to compare integers
and reals is natural and reasonably safe, bringing strings into the
mix is not. There’s a reason why Python is able to get away with not
needing a “===” operator, while JavaScript and PHP are not.

Truthiness: yes, this is a pitfall, too. Languages should just take
the Pascal route and insist that conditions be of Boolean type.

[toc] | [next] | [standalone]

#124437

On 24/04/2025 04:52, Lawrence D'Oliveiro wrote:
> OK, so the actual anniversary was back in March. But I just
> (re)discovered the InfoWorld site, and was surprised to discover it
> has become such a software-development-focused place (was it before?).
> 
> This article
> <https://www.infoworld.com/article/3836901/10-things-developers-love-about-javascript-and-10-things-they-dont.html>
> goes over some of the things the author(s) love about JavaScript, and
> some things they don’t.
> 
> In terms of punctuation, didn’t they know semicolons (at least as
> statement terminators) are optional in JavaScript? Yes, the rule is a
> bit more subtle than in Python, but even I, a Python programmer, was
> able to figure it out.

I would like to have the semicolons mandatory. They should also be
required after a '}' if the statement the block is part of endt there
(no 'else' or 'until' follows).

> Type conversion: this I do not love. Being able to compare integers
> and reals is natural and reasonably safe, bringing strings into the
> mix is not. There’s a reason why Python is able to get away with not
> needing a “===” operator, while JavaScript and PHP are not.

At least '===' and '!==' are there so there is no need to use '=='
or '!=' when one doesn't want.

> Truthiness: yes, this is a pitfall, too. Languages should just take
> the Pascal route and insist that conditions be of Boolean type.

Fortunatly conditions are usually in contexts that marks them as
conditions.

One problem with many program languages is that the program does not
identify the revision of the standard. This would be important with
Javascript as the same program is intended for a large variety of
implementations that are not updated to the latest revision or are
aleady updated to a revision that is published after the publication
of the program.

In Javascript there is the pragma "use strict". A similar pragma could
be used to identify the revision expected to be supported. In addition
there should be a global constant or constants or function that tells
the revision acutally supported so that program can adapt to what is
available.

The subject line means that Javascript already existed 30 years ago.
In some sense that is false: the Javascript that we know today is
not the same as the Javascript 30 years ago. But it is true as much
of what Javascript was 30 years ago is still present in the moders
Javascript.

-- 
Mikko

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

#124439

On Mon, 13 Jul 2026 16:12:42 +0300, Mikko wrote:

> I would like to have the semicolons mandatory.

So would I. But given that they’re not, we have to work with the
language as it is specified.

> At least '===' and '!==' are there so there is no need to use '=='
> or '!=' when one doesn't want.

Think about why a language like Python doesn’t need “===” and “!==”.
It’s because it eschews the more error-prone automatic type
conversions, so it doesn’t need a way to turn them off.

> Fortunatly conditions are usually in contexts that marks them as
> conditions.

And if an expression returns certain values, the result of
(mis)interpreting them as booleans can be ... interesting.

> One problem with many program languages is that the program does not
> identify the revision of the standard. This would be important with
> Javascript as the same program is intended for a large variety of
> implementations that are not updated to the latest revision or are
> aleady updated to a revision that is published after the publication
> of the program.

HTML used to have “<script language=javascript>” versus “<script
language=javascript1.2>” etc. For some reason that was considered more
trouble than it was worth.

> The subject line means that Javascript already existed 30 years ago.
> In some sense that is false: the Javascript that we know today is
> not the same as the Javascript 30 years ago.

So when did today’s JavaScript come into being? How old would you say
it really was, if not 30 years?

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

#124440

On 14/07/2026 01:31, Lawrence D’Oliveiro wrote:
> On Mon, 13 Jul 2026 16:12:42 +0300, Mikko wrote:

>> The subject line means that Javascript already existed 30 years ago.
>> In some sense that is false: the Javascript that we know today is
>> not the same as the Javascript 30 years ago.
> 
> So when did today’s JavaScript come into being? How old would you say
> it really was, if not 30 years?

One can say that every time the standard is updated it creates a new
lanugage. But often it is reasonable to say otherwise.

-- 
Mikko

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

#124441

On Tue, 14 Jul 2026 09:59:35 +0300, Mikko wrote:

> On 14/07/2026 01:31, Lawrence D’Oliveiro wrote:
>>
>> On Mon, 13 Jul 2026 16:12:42 +0300, Mikko wrote:
>
>>> The subject line means that Javascript already existed 30 years
>>> ago. In some sense that is false: the Javascript that we know
>>> today is not the same as the Javascript 30 years ago.
>>
>> So when did today’s JavaScript come into being? How old would you
>> say it really was, if not 30 years?
>
> One can say that every time the standard is updated it creates a new
> lanugage. But often it is reasonable to say otherwise.

So how old is it really?

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

#124446

Mikko wrote:
> On 14/07/2026 01:31, Lawrence D’Oliveiro wrote:
>> On Mon, 13 Jul 2026 16:12:42 +0300, Mikko wrote:
>>> The subject line means that Javascript already existed 30 years ago.
>>> In some sense that is false: the Javascript that we know today is
>>> not the same as the Javascript 30 years ago.
>>
>> So when did today’s JavaScript come into being? How old would you say
>> it really was, if not 30 years?
> 
> One can say that every time the standard is updated it creates a new
> lanugage.

That is simply not so.

> But often it is reasonable to say otherwise.

It is always reasonable to say otherwise.

-- 
PointedEars

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

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

#124442

On 13/07/2026 14:12, Mikko wrote:
> On 24/04/2025 04:52, Lawrence D'Oliveiro wrote:
>> OK, so the actual anniversary was back in March. But I just
>> (re)discovered the InfoWorld site, and was surprised to discover it
>> has become such a software-development-focused place (was it before?).
>>
>> This article
>> <https://www.infoworld.com/article/3836901/10-things-developers-love- 
>> about-javascript-and-10-things-they-dont.html>
>> goes over some of the things the author(s) love about JavaScript, and
>> some things they don’t.
>>
>> In terms of punctuation, didn’t they know semicolons (at least as
>> statement terminators) are optional in JavaScript? Yes, the rule is a
>> bit more subtle than in Python, but even I, a Python programmer, was
>> able to figure it out.
> 
> I would like to have the semicolons mandatory. They should also be
> required after a '}' if the statement the block is part of endt there
> (no 'else' or 'until' follows).
This is a statement :
   { }
and so is this :
   ;
Therefore
   { } ;
is two statements.
The way to solve the Dangling Else problem is to end every if statement 
with :
   endif
but that's unlikely to happen.

Incidentally, the history of semicolons in javascript is that a lot of 
people scream loudly if semicolons aren't used, and just as many scream 
loudly if they are. :-(


   John

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

#124443

On Tue, 14 Jul 2026 10:50:33 +0100, John Harris wrote:

> Incidentally, the history of semicolons in javascript is that a lot
> of people scream loudly if semicolons aren't used, and just as many
> scream loudly if they are. :-(

I think there are more that scream loudly if they aren’t ...

function add_element(parent, name, objattrs, tagattrs, children = null)
  /* general routine for creating a new HTMLElement, initializing
    attributes, and attaching it to a parent element and attaching
    child elements, if specified. */
  /* I think objattrs and tagattrs are largely interchangeable ... */
  {
    const result = document.createElement(name)
    if (objattrs !== null)
      {
        for (const [name, value] of Object.entries(objattrs))
          {
            result[name] = value
          } /*for*/
      } /*if*/
    if (tagattrs !== null && tagattrs !== undefined)
      {
        for (const [name, value] of Object.entries(tagattrs))
          {
            const attr = document.createAttribute(name)
            attr.value = value
            result.attributes.setNamedItem(attr)
          } /*for*/
      } /*if*/
    if (children !== null)
      {
        for (const child of children)
          {
            result.appendChild(child)
          } /*for*/
      } /*if*/
    if (parent !== null)
      {
        parent.appendChild(result)
      } /*if*/
    return result
  } /*add_element*/

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

#124444

On 14/07/2026 23:12, Lawrence D’Oliveiro wrote:
> On Tue, 14 Jul 2026 10:50:33 +0100, John Harris wrote:
> 
>> Incidentally, the history of semicolons in javascript is that a lot
>> of people scream loudly if semicolons aren't used, and just as many
>> scream loudly if they are. :-(
> 
> I think there are more that scream loudly if they aren’t ...
> 
> function add_element(parent, name, objattrs, tagattrs, children = null)
>    /* general routine for creating a new HTMLElement, initializing
>      attributes, and attaching it to a parent element and attaching
>      child elements, if specified. */
>    /* I think objattrs and tagattrs are largely interchangeable ... */
>    {
>      const result = document.createElement(name)
>      if (objattrs !== null)
>        {
>          for (const [name, value] of Object.entries(objattrs))
>            {
>              result[name] = value
>            } /*for*/
>        } /*if*/
>      if (tagattrs !== null && tagattrs !== undefined)
>        {
>          for (const [name, value] of Object.entries(tagattrs))
>            {
>              const attr = document.createAttribute(name)
>              attr.value = value
>              result.attributes.setNamedItem(attr)
>            } /*for*/
>        } /*if*/
>      if (children !== null)
>        {
>          for (const child of children)
>            {
>              result.appendChild(child)
>            } /*for*/
>        } /*if*/
>      if (parent !== null)
>        {
>          parent.appendChild(result)
>        } /*if*/
>      return result
>    } /*add_element*/


The people who loudly want semicolons want :-
   a = 3;
   b = "Yes";  // No semicolon would be a syntax error
   c = 42;

   John

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

#124445

Mikko wrote:
> On 24/04/2025 04:52, Lawrence D'Oliveiro wrote:
>> Truthiness: yes, this is a pitfall, too. Languages should just take
>> the Pascal route and insist that conditions be of Boolean type.
> 
> Fortunatly conditions are usually in contexts that marks them as
> conditions.
> 
> One problem with many program languages is that the program does not
> identify the revision of the standard. 

What do you mean by that?

> This would be important with Javascript

There (still) is no "Javascript": <http://PointedEars.de/es-matrix>

[Granted, the feature list is not up-to-date anymore, and I am not sure if I
will manage to update it -- I have so much else to deal with right now; but
the basic argument that I presented there is still correct.]

> as the same program is intended for a large variety of
> implementations that are not updated to the latest revision or are
> aleady updated to a revision that is published after the publication
> of the program.
> 
> In Javascript there is the pragma "use strict".

In ECMAScript Ed. 5 and later, therefore in implementations of that.

> A similar pragma could be used to identify the revision expected to
> be supported.

I think that you have a major misconception about ECMAScript and the
landscape of ECMAScript implementations.

> In addition there should be a global constant or constants or function
> that tells the revision acutally supported so that program can adapt to
> what is available.

This is pointless because there is no implementtion that is fully compliant
with any Edition of ECMAScript, and there are so many features that it is
impossible to keep track of them.  It is better to test the features that
one actually uses.  And eventually one has to decide which syntactical
constructs one uses, considering that every syntactical construct sacrifices
a bit of backwards compatibility.

> The subject line means that Javascript already existed 30 years ago.

Not "Javascript", but (Netscape) JavaScript, literally.

> In some sense that is false: the Javascript that we know today is
> not the same as the Javascript 30 years ago.

You are the one who started with this false equivalence in the first place.

> But it is true as much of what Javascript was 30 years ago

30 years ago the nonsensical term "Javascript" that was introduced by people
who were either too lazy or too uninformed did not exist yet.

> is still present in the moders Javascript.

You do not know what you are talking about.  That probably comes from
reading books by people who also do not know what they are talking about but
present themselves as "gurus", like John Resig.

-- 
PointedEars

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

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

#124447

On 18/07/2026 05:46, Thomas 'PointedEars' Lahn wrote:
> Mikko wrote:
>> On 24/04/2025 04:52, Lawrence D'Oliveiro wrote:
>>> Truthiness: yes, this is a pitfall, too. Languages should just take
>>> the Pascal route and insist that conditions be of Boolean type.
>>
>> Fortunatly conditions are usually in contexts that marks them as
>> conditions.
>>
>> One problem with many program languages is that the program does not
>> identify the revision of the standard.
> 
> What do you mean by that?

That reading the program text does not reveal what revision of the
standard did the programmer or programmer's or tester's compiler
or interpreter use.

>> This would be important with Javascript
> 
> There (still) is no "Javascript": <http://PointedEars.de/es-matrix>
> 
> [Granted, the feature list is not up-to-date anymore, and I am not sure if I
> will manage to update it -- I have so much else to deal with right now; but
> the basic argument that I presented there is still correct.]
> 
>> as the same program is intended for a large variety of
>> implementations that are not updated to the latest revision or are
>> aleady updated to a revision that is published after the publication
>> of the program.
>>
>> In Javascript there is the pragma "use strict".
> 
> In ECMAScript Ed. 5 and later, therefore in implementations of that.
> 
>> A similar pragma could be used to identify the revision expected to
>> be supported.
> 
> I think that you have a major misconception about ECMAScript and the
> landscape of ECMAScript implementations.
> 
>> In addition there should be a global constant or constants or function
>> that tells the revision acutally supported so that program can adapt to
>> what is available.
> 
> This is pointless because there is no implementtion that is fully compliant
> with any Edition of ECMAScript, and there are so many features that it is
> impossible to keep track of them.  It is better to test the features that
> one actually uses.  And eventually one has to decide which syntactical
> constructs one uses, considering that every syntactical construct sacrifices
> a bit of backwards compatibility.
> 
>> The subject line means that Javascript already existed 30 years ago.
> 
> Not "Javascript", but (Netscape) JavaScript, literally.

That's false, the subject line did not say "Netscape JavaScript".

>> In some sense that is false: the Javascript that we know today is
>> not the same as the Javascript 30 years ago.
> 
> You are the one who started with this false equivalence in the first place.

No, it already was on the subject line.

>> But it is true as much of what Javascript was 30 years ago
> 
> 30 years ago the nonsensical term "Javascript" that was introduced by people
> who were either too lazy or too uninformed did not exist yet.

The name was introduced with the release of Netsace Navigator in
December 1995.

>> is still present in the moders Javascript.
> 
> You do not know what you are talking about.  That probably comes from
> reading books by people who also do not know what they are talking about but
> present themselves as "gurus", like John Resig.

Much of what I said above is based on my experiences with various
programming languages, including old and new Javascript.

-- 
Mikko

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

#124448

On Sun, 19 Jul 2026 11:40:07 +0300, Mikko wrote:

> Much of what I said above is based on my experiences with various
> programming languages, including old and new Javascript.

You still haven’t said what you consider to be “old” versus “new”
JavaScript.

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

#124449

On 20/07/2026 02:29, Lawrence D’Oliveiro wrote:
> On Sun, 19 Jul 2026 11:40:07 +0300, Mikko wrote:
> 
>> Much of what I said above is based on my experiences with various
>> programming languages, including old and new Javascript.
> 
> You still haven’t said what you consider to be “old” versus “new”
> JavaScript.

What was released 30 years ago is old. The current standard is new,
at least until the next revison.

-- 
Mikko

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

#124450

On Mon, 20 Jul 2026 09:42:55 +0300, Mikko wrote:

> On 20/07/2026 02:29, Lawrence D’Oliveiro wrote:
>>
>> On Sun, 19 Jul 2026 11:40:07 +0300, Mikko wrote:
>>
>>> Much of what I said above is based on my experiences with various
>>> programming languages, including old and new Javascript.
>>
>> You still haven’t said what you consider to be “old” versus “new”
>> JavaScript.
>
> What was released 30 years ago is old. The current standard is new,
> at least until the next revison.

If I understand you correctly, are you saying that everything prior to
the latest version (16th edition, from June 2025 as of this writing),
is “old”?

So your idea of “new” JavaScript can never be much more than about a
year old?

That’s fine. The rest of us will continue to refer to “30 years of
JavaScript”. You do you.

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

#124452

On 20/07/2026 11:08, Lawrence D’Oliveiro wrote:
> On Mon, 20 Jul 2026 09:42:55 +0300, Mikko wrote:
> 
>> On 20/07/2026 02:29, Lawrence D’Oliveiro wrote:
>>>
>>> On Sun, 19 Jul 2026 11:40:07 +0300, Mikko wrote:
>>>
>>>> Much of what I said above is based on my experiences with various
>>>> programming languages, including old and new Javascript.
>>>
>>> You still haven’t said what you consider to be “old” versus “new”
>>> JavaScript.
>>
>> What was released 30 years ago is old. The current standard is new,
>> at least until the next revison.
> 
> If I understand you correctly, are you saying that everything prior to
> the latest version (16th edition, from June 2025 as of this writing),
> is “old”?

Depends on what you are doing. For some pusposes it is best to use the
latest standard but often it is better to avoid the need to upgrade
customer's equipment.

> So your idea of “new” JavaScript can never be much more than about a
> year old?

Sometimes old enough means at least ten years old.

> That’s fine. The rest of us will continue to refer to “30 years of
> JavaScript”. You do you.

Others may count the years. I con't care.

-- 
Mikko

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

#124453

On Tue, 21 Jul 2026 08:57:57 +0300, Mikko wrote:

> On 20/07/2026 11:08, Lawrence D’Oliveiro wrote:
>>
>> On Mon, 20 Jul 2026 09:42:55 +0300, Mikko wrote:
>>
>>> What was released 30 years ago is old. The current standard is
>>> new, at least until the next revison.
>>
>> If I understand you correctly, are you saying that everything prior
>> to the latest version (16th edition, from June 2025 as of this
>> writing), is “old”?
>
> Depends on what you are doing.

That’s not what you said above. You said “the current standard is
new”, and nothing else was.

>> That’s fine. The rest of us will continue to refer to “30 years of
>> JavaScript”. You do you.
>
> Others may count the years. I con't care.

Funny, didn’t you do exactly the same thing?

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

#124454

On 22/07/2026 02:08, Lawrence D’Oliveiro wrote:
> On Tue, 21 Jul 2026 08:57:57 +0300, Mikko wrote:
> 
>> On 20/07/2026 11:08, Lawrence D’Oliveiro wrote:
>>>
>>> On Mon, 20 Jul 2026 09:42:55 +0300, Mikko wrote:
>>>
>>>> What was released 30 years ago is old. The current standard is
>>>> new, at least until the next revison.
>>>
>>> If I understand you correctly, are you saying that everything prior
>>> to the latest version (16th edition, from June 2025 as of this
>>> writing), is “old”?
>>
>> Depends on what you are doing.
> 
> That’s not what you said above. You said “the current standard is
> new”, and nothing else was.

The current standard is the newest there is. But I did not say that
nothing else was, I said that 30 years old is not.

>>> That’s fine. The rest of us will continue to refer to “30 years of
>>> JavaScript”. You do you.
>>
>> Others may count the years. I con't care.
> 
> Funny, didn’t you do exactly the same thing?


-- 
Mikko

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

#124459

Mikko wrote:
> On 20/07/2026 02:29, Lawrence D’Oliveiro wrote:
>> On Sun, 19 Jul 2026 11:40:07 +0300, Mikko wrote:
>>> Much of what I said above is based on my experiences with various
>>> programming languages, including old and new Javascript.
>>
>> You still haven’t said what you consider to be “old” versus “new”
>> JavaScript.
> 
> What was released 30 years ago is old. The current standard is new,
> at least until the next revison.

Utter nonsense.

-- 
PointedEars

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

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

#124458

Mikko wrote:
^^^^^
Your full name belongs there.

> On 18/07/2026 05:46, Thomas 'PointedEars' Lahn wrote:
>> Mikko wrote:
>>> On 24/04/2025 04:52, Lawrence D'Oliveiro wrote:
>>>> Truthiness: yes, this is a pitfall, too. Languages should just take
>>>> the Pascal route and insist that conditions be of Boolean type.
>>>
>>> Fortunatly conditions are usually in contexts that marks them as
>>> conditions.
>>>
>>> One problem with many program languages is that the program does not
>>> identify the revision of the standard.
>>
>> What do you mean by that?
> 
> That reading the program text does not reveal what revision of the
> standard did the programmer or programmer's or tester's compiler
> or interpreter use.

[Source code written in ECMAScript implementations is _always_ compiled
first, but it is compiled JIT most of the time.]

It does to the well-educated and those who can use linters (when put to the
test, ESLint is good at least at telling code that uses ES6+ syntactical
features apart from code that does not; it is my preferred linter).  For
example, to the well-educated, the arrow function syntax cries out
"implementation of ECMAScript Ed. 6 and later".  So does an array literal
*left-hand side*.

However, I agree that it is becoming increasingly difficult to tell.  Based
on my ECMAScript Support Matrix, I have been working on, but never finished,
a tool that, given a piece of source code, can make an educated guess; but,
as I indicated, it is difficult to keep track now given that there is a new
Edition of ECMAScript every year, and that one has to keep track of both new
syntactical constructs and new built-in objects and properties.

However, as I have pointed out, it would be of little use to declare the
Edition of the ECMAScript in the source code by a syntactical construct
because to my knowledge there is no full standards compliance in any
implementation, and I doubt anybody is still able to keep track of it in
their head anyway.  The tag would need to be constantly updated, and it
would be difficult to get it right (see above), but to the average developer
it would mean nothing.

As it is, if ECMAScript-based source code does not even compile in an
implementation, but compiles in another, chances are is that it is using
syntactical features that did not exist yet in the Edition of ECMAScript
that the compiler is based on (at least), and you can see that in the
compiler output (in Web browsers: in the Developer Console).

> [irrelevant quotes]

You ought to trim your quotes to the relevant minimum.

>>> The subject line means that Javascript already existed 30 years ago.
>> Not "Javascript", but (Netscape) JavaScript, literally.
> 
> That's false, the subject line did not say "Netscape JavaScript".

Context is important.  To the well-educated the "JavaScript" in "30 Years Of
JavaScript" *means* Netscape JavaScript because there was no other
programming language whose name contained that string of characters 30 years
ago.  This language, Netscape JavaScript 1.0, was not even an ECMAScript
implementation yet because ECMAScript did not exist yet, as you can read in
my thesis and on my Web site:

<http://PointedEars.de/es-matrix/#ecmascript>

>>> In some sense that is false: the Javascript that we know today is
>>> not the same as the Javascript 30 years ago.
>> You are the one who started with this false equivalence in the first place.
> 
> No, it already was on the subject line.

Identifiers in ECMAScript implementations are case-sensitive ;-)

>>> But it is true as much of what Javascript was 30 years ago
>>
>> 30 years ago the nonsensical term "Javascript" that was introduced by people
>> who were either too lazy or too uninformed did not exist yet.
> 
> The name was introduced with the release of Netsace Navigator in
> December 1995.

Netscape _JavaScript_ 1.0 was actually introduced with the release of
_Netscape_ Navigator _2.0_ in _March 1996_.

[I have been *there*, kid.  Have you read my thesis/Web site yet?]

>>> is still present in the moders Javascript.
>>
>> You do not know what you are talking about.  That probably comes from
>> reading books by people who also do not know what they are talking about but
>> present themselves as "gurus", like John Resig.
> 
> Much of what I said above is based on my experiences with various
> programming languages, including old and new Javascript.

You are living in a convenient fantasy world where there is an "old and new
Javascript" (sic).  There is no hope for you until you snap out of this
wannabe-induced fever dream, and learn to appreciate both the chaos and the
diversity of ECMAScript implementations :'-)

-- 
PointedEars

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

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

#124438

On 2025-04-24, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> Truthiness: yes, this is a pitfall, too. Languages should just take
> the Pascal route and insist that conditions be of Boolean type.

Absolutely not. While getting "truthiness" wrong is a flaw in some
programming languages, and while JavaScript doesn't quite get it 100%
right (although some of this is probably down to the way JavaScript
objects work), going to the other extreme of saying that only literal
'true' is true and only literal 'false' is false is also an error.

It's incredibly useful to say:

    if (x)

and not to have to write something like:

    if (x !== undefined && x !== null && x !== '')

and the former is, if anything, *more* readable - in any language
with a sensible "truthiness" definition anyway.

[toc] | [prev] | [standalone]

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

csiph-web