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

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

Re: Attributes containing JavaScript

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Attributes containing JavaScript JJ <jj4public@vfemail.net> - 2019-02-07 02:41 +0700
    Re: Attributes containing JavaScript Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-02-06 22:01 +0100
    Re: Attributes containing JavaScript "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2019-02-07 17:43 +0100
      Re: Attributes containing JavaScript Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-07 20:42 +0000
        Re: Attributes containing JavaScript Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-07 21:57 +0000
        Re: Attributes containing JavaScript Julio Di Egidio <julio@diegidio.name> - 2019-02-07 23:14 -0800
          Re: Attributes containing JavaScript "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2019-02-08 09:13 +0100
            Re: Attributes containing JavaScript Julio Di Egidio <julio@diegidio.name> - 2019-02-08 00:20 -0800
          Re: Attributes containing JavaScript Julio Di Egidio <julio@diegidio.name> - 2019-02-08 00:45 -0800
          Re: Attributes containing JavaScript Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-08 13:27 +0000

#35983 — Re: Attributes containing JavaScript

On 5 Feb 2019 12:05:38 GMT, Stefan Ram wrote:
>   From the point of programming style, how do you assess the
>   following two approaches to add a click-handler?
> 
>   1.) Add the handler in JavaScript
> 
> <span id="span">
> ...
> incrementSpan = () => span.innerHTML = +span.innerHTML + 1;
> span.addEventListener( "click", incrementSpan );
> 
>   2.) Add the handler in HTML
> 
> <span id="span" onclick="span.innerHTML = +span.innerHTML + 1">0</span>
> 
>   (end of "2.)")
> 
>   What are the advantages and disadvantages of each approach?

Style? The first one is the new style. The second one is the old style.

The first one allows grouping of JavaScript code into one place, and it can
be more space efficient when setting up a handler for multiple elements. It
also allows multiple handlers on the same element, for the same event. The
disadvantage is that it's less space efficient if it's used just for one
element.

The second one is space efficient, but this only applies to one or two
elements. Any more than that would not be less efficient. Since there can
only be one (effective) `onclick` attribute in an element, an element can
only have one (inline) handler for a specific event. When it's used for
multiple elements, changing the handler functionality requires changing each
`onclick` attribute in all of the elements. And since this is an old style,
it may eventually be made obsolete in the future.

[toc] | [next] | [standalone]

#35985

JJ wrote:
> On 5 Feb 2019 12:05:38 GMT, Stefan Ram wrote:
>>   From the point of programming style, how do you assess the
>>   following two approaches to add a click-handler?
>>
>>   1.) Add the handler in JavaScript
>>
>> <span id="span">
>> ...
>> incrementSpan = () => span.innerHTML = +span.innerHTML + 1;
>> span.addEventListener( "click", incrementSpan );
>>
>>   2.) Add the handler in HTML
>>
>> <span id="span" onclick="span.innerHTML = +span.innerHTML + 1">0</span>
>>
>>   (end of "2.)")
>>
>>   What are the advantages and disadvantages of each approach?
> 
> Style? The first one is the new style. The second one is the old style.

Utter nonsense.

<https://www.w3.org/TR/2017/REC-html52-20171214/webappapis.html#webappapis-scripting>

<https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Building_blocks/Events>

-- 
PointedEars

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

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

#35990

ram@zedat.fu-berlin.de (Stefan Ram) wrote on 07 Feb 2019 in 
comp.lang.javascript:

> Edsge Dijkstra

Not "Edsge" but "Edsger".

Edsger Wybe Dijkstra 
[Rotterdam, 11 May 1930 – Nuenen, 6 August 2002]

He was primarily concerned, as I understand it,
that by programming with the "GoTo" command,
as was the norm in BASIC at that time, 
like the only available conditional:

If condition GoTo linenumber

making a complete mess of any complex code, and he visualized the necessity 
of **recursive** and later compact modular coding as we think is common use 
nowadays.

BASIC and other languages evolved due to his harsh comments and ideas,
[and he was the voice of others too, ofcourse].

<http://www.dijkstrascry.com/node/4>

<https://en.wikipedia.org/wiki/Edsger_W._Dijkstra>

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

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

#35991

"Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:

> ram@zedat.fu-berlin.de (Stefan Ram) wrote on 07 Feb 2019 in 
> comp.lang.javascript:
>
>> Edsge Dijkstra
>
> Not "Edsge" but "Edsger".
>
> Edsger Wybe Dijkstra 
> [Rotterdam, 11 May 1930 – Nuenen, 6 August 2002]
>
> He was primarily concerned, as I understand it,
> that by programming with the "GoTo" command,
> as was the norm in BASIC at that time, 

EWD's critique of go to makes no mention of BASIC, probably because it
was new and very much a niche language.  At the time (1968) COBOL,
FORTRAN, Algol, PL/I and so on where more significant players.

He made a considerable number of significant contributions in areas as
diverse as compilers (he invented the shunting yard algorithm),
concurrency (he invented semaphores), and networks (Dijkstra's
algorithm), but I think it would be fair to say that his was concerned
above all else with program correctness.  He considered programs to be
mathematical texts about which one could (and should) reason.  His book,
The Discipline of Programming, should be required reading for all
aspiring programmers.  It changed the way I programmed forever.

<snip>
-- 
Ben.

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

#35993

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>"Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:
>>>Not "Edsge" but "Edsger".
>>The Discipline of Programming, should be required reading for all
>
>   Not "The", but "A".

Ah, thanks.  I should have looked it up!

-- 
Ben.

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

#35994

On Thursday, 7 February 2019 21:42:42 UTC+1, Ben Bacarisse  wrote:

> [Dijkstra]
> above all else with program correctness.  He considered programs to be
> mathematical texts about which one could (and should) reason.

Conflating real programming (a subbranch of engineering) with computer
science (a subbranch of mathematics) is a disastrous mistake and the
origin of most (though not all) disasters in production.

> His book,
> The Discipline of Programming, should be required reading for all
> aspiring programmers.  It changed the way I programmed forever.

For the worst, apparently.

<< Beware of bugs in the above code,
   I have only proved it correct,
   not tested it." >>

Have you missed *that* lesson?

Julio

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

#35995

Julio Di Egidio <julio@diegidio.name> wrote on 08 Feb 2019 in 
comp.lang.javascript:

> Conflating real programming (a subbranch of engineering) with computer
> science (a subbranch of mathematics) is a disastrous mistake and the
> origin of most (though not all) disasters in production.

Just pronouncing something does not make an argument.

You are talking like religious fanatic,
thinking your kind of faith is real and true,
just because you define it as real and true.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

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

#35996

On Friday, 8 February 2019 09:14:00 UTC+1, Evertjan.  wrote:
> Julio Di Egidio <julio@diegidio.name> wrote on 08 Feb 2019 in 
> comp.lang.javascript:
> 
> > Conflating real programming (a subbranch of engineering) with computer
> > science (a subbranch of mathematics) is a disastrous mistake and the
> > origin of most (though not all) disasters in production.
> 
> Just pronouncing something does not make an argument.

I was objecting to something that you have simply snipped.

> You are talking like religious fanatic,

Just you are full of shit.

*Troll Alert*

Julio

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

#35997

On Friday, 8 February 2019 08:14:50 UTC+1, Julio Di Egidio  wrote:
> On Thursday, 7 February 2019 21:42:42 UTC+1, Ben Bacarisse  wrote:
> 
> > [Dijkstra]
> > above all else with program correctness.  He considered programs to be
> > mathematical texts about which one could (and should) reason.
> 
> Conflating real programming (a subbranch of engineering) with computer
> science (a subbranch of mathematics) is a disastrous mistake and the
> origin of most (though not all) disasters in production.
> 
> > His book,
> > The Discipline of Programming, should be required reading for all
> > aspiring programmers.  It changed the way I programmed forever.
> 
> For the worst, apparently.
> 
> << Beware of bugs in the above code,
>    I have only proved it correct,
>    not tested it." >>
> 
> Have you missed *that* lesson?

To be clear, as present day mythologies on testing are another can of worms:
*that* is still a lesson for the Computer Scientist!  It is NOT suggesting
to the Software Engineer that he should test, it is rather suggesting to the
Computer Scientist that engineering is NOT (i.e. not essentially) about
*formal* correctness and CS should NOT pontificate outside its own realm.
IOW, results in CS do NOT (directly) map to results in SE.

HTH,

Julio

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

#35998

Julio Di Egidio <julio@diegidio.name> writes:

> On Thursday, 7 February 2019 21:42:42 UTC+1, Ben Bacarisse  wrote:
>
>> [Dijkstra]
>> above all else with program correctness.  He considered programs to be
>> mathematical texts about which one could (and should) reason.
>
> Conflating real programming (a subbranch of engineering) with computer
> science (a subbranch of mathematics) is a disastrous mistake and the
> origin of most (though not all) disasters in production.
>
>> His book,
>> The Discipline of Programming, should be required reading for all
>> aspiring programmers.  It changed the way I programmed forever.
>
> For the worst, apparently.

What an extraordinary thing to claim to know about!

> << Beware of bugs in the above code,
>    I have only proved it correct,
>    not tested it." >>
>
> Have you missed *that* lesson?

Aphorisms are not lessons.  The roles played by testing and reasoning,
and the relationship between them, are not easy to sum up in a few
words.  They constitute many lessons.

-- 
Ben.

[toc] | [prev] | [standalone]

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

csiph-web