n00b considering Java Script

[Marek Novotny]

I know absolutely NOTHING about Java Script. If I wanted to get started
learning on some n00b basic level would there be a book or online course
you'd recommend?

--
Marek Novotny
https://github.com/marek-novotny

[WaltS]

On 09/25/2016 10:09 AM, Marek Novotny wrote:
> I know absolutely NOTHING about Java Script. If I wanted to get started
> learning on some n00b basic level would there be a book or online course
> you'd recommend?
>

I've started learning JavaScript using Beginning JavaScript 5th Edition,
several times.

<http://www.wiley.com/WileyCDA/WileyTitle/productCd-1118903331.html>

[Marek Novotny]

Using up to date modern practices?

[Thomas 'PointedEars' Lahn]

WaltS wrote:
^^^^^
This is Usenet. Your “From” header field value should contain your *real*
name.

<http://media.wiley.com/product_data/excerpt/31/11189033/1118903331-15.pdf>

Page 1:

| 1 Introduction to JavaScript and the Web
|
| […]
| JavaScript is an interpreted language rather than a compiled language.

Wrong.

| What is meant by the terms “interpreted” and “compiled”?
| Well, to let you in on a secret, your computer doesn’t really understand
| JavaScript at all. It needs something to interpret the JavaScript code and
| convert it into something that it understands; hence it is an interpreted
| language. Computers understand only machine code, which is essentially a
| string of binary numbers (that is, a string of zeros and ones). As the
| browser goes through the JavaScript, it passes it to a special program
| called an interpreter, which converts the JavaScript to the machine
| code your computer understands.

No, it does not. Instead, source code is passed to a software component
called a script engine, by which it is compiled (just-in-time) to bytecode
to be executed by a platform-independent virtual machine (e.g. by Mozilla
SpiderMonkey) or to machine-specific code (e.g., by Google V8).

Page 2:

| What is JavaScript?
| […]
| In 1997, JavaScript was standardized by Ecma International, a membership‐
| based non‐profit organization, and renamed to ECMAScript.

Wrong. “ECMAScript is based on several originating technologies, the most
well-known being JavaScript (Netscape) and JScript (Microsoft).” (This true
sentence can be found in *every* Edition of the ECMAScript Language
Specification.)

| JavaScript support among today’s browsers is certainly more unifi ed than
| it has ever been, but as you see in future chapters, developers still have
| to cope with older, and in many cases non‐standard, JavaScript
| implementations.

Wrong. Those programming languages are not “JavaScript implementations”,
but _ECMAScript_ implementations, and *the standard allows conforming
implementations extensions to the language*:

‘2 Conformance

A conforming implementation of ECMAScript may provide additional types,
values, objects, properties, and functions beyond those described in this
specification. In particular, a conforming implementation of ECMAScript may
provide properties not described in this specification, and values for those
properties, for objects that are described in this specification.

A conforming implementation of ECMAScript may support program and regular
expression syntax not described in this specification. In particular, a
conforming implementation of ECMAScript may support program syntax that
makes use of the “future reserved words” listed in subclause 11.6.2.2 of
this specification.’

(to be found in *every* Edition of the ECMAScript Language Specification)

Page 3:

| JavaScript and the Web
|
| […]
| The organization that sets the standards for web pages is the World Wide
| Web Consortium (W3C). It not only sets standards for HTML and CSS, but
| also for how JavaScript interacts with web pages inside a web browser.

Utter nonsense. The W3C specifies the Document Object Model (DOM), a
standard of *language-independent* interfaces for interacting with documents
written in markup languages like HTML, which are the primary focus of the
W3C. ECMAScript implementations like JavaScript, among other programming
languages, can then be used to access implementations of those interfaces
and interact with DOM objects.


Those are only the first three pages of that book and they are already full
of common misconceptions about “JavaScript”. From that, I doubt that the
author(s) have the slightest idea what they are talking about. I strongly
recommend against reading this book, much less buying it.

The amount of nonsense you will have to unlearn after reading it will be
greater than what you can learn correctly elsewhere, including this
newsgroup. Read its FAQ instead; alas, it is not up-to-date either, but
still better than this book because the latter was written by
*professionals* who make a living by using the language(s) every day; not by
some wannabe author/publishing house who wants to make a quick buck and a
name for themselves by writing down/publishing hearsay and their purely
theoretical understanding/misconceptions of the topic.

BTW:

<http://catb.org/esr/faqs/smart-questions.html#writewell>
<http://catb.org/esr/faqs/smart-questions.html#idm45835691819312>

--
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[WaltS]

On 09/25/2016 12:23 PM, Thomas 'PointedEars' Lahn wrote:
> This is Usenet. Your “From” header field value should contain your *real*
> name.

It legally is.

[WaltS]

Modern practices change daily, so probably not. :)

[Thomas 'PointedEars' Lahn]

That is a bold lie. Then again, what other social conduct to expect from
someone who is an address munger, too. *PLONK*

[WaltS]

On 09/25/2016 02:36 PM, Tim Streater wrote:
> In article <8_SFz.5949$Yk1....@fx43.iad>, WaltS

> PointyHead is a troll, a pedant, and an arsehole. You may safely ignore
> him.
>

I've noticed that from its previous posts. I had to pull its chain though.

Pointed head to go with those ears?

[Gregor Kofler]

Am 2016-09-25 um 16:09 schrieb Marek Novotny:
> I know absolutely NOTHING about Java Script. If I wanted to get started
> learning on some n00b basic level would there be a book or online course
> you'd recommend?
>

Depends.

Codecadamy offers a really slow step-by-step interactive course.
https://www.codecademy.com/learn/learn-javascript

MDN offers a lot of tutorials and reference guides
https://developer.mozilla.org/en-US/docs/Web/JavaScript

Gregor

[Scott Sauyet]

Marek Novotny wrote:

> I know absolutely NOTHING about Java Script. If I wanted to get started
> learning on some n00b basic level would there be a book or online course
> you'd recommend?

There are a few I would recommend.

(Usually I would look up URLs for these, but I'm in a bit of a hurry
now. A quick web search should find any of them.)

The best all-around beginner book I know of is Marijn Haverbeke's
_Eloquent JavaScript_.

It may be a bit dated now, but I found Stoyan Stefanov's _JavaScript
Patterns_ worth reading, and a good follow-up to Haverbeke. (Do check
the author; there is another book with the same title that I don't find
at all worthwhile.)

A more advanced book worth reading is Dave Herman's _Effective
JavaScript_.

Douglas Crockford's _JavaScript: The Good Parts_ helped redefine the way
people thing about the languages. It is worth a read, but don't take his
suggestions as definitive.

The undoubted best reference guide is David Flanagan's _JavaScript: The
Definitive Guide_.

There are two books that I would suggest for those looking to use
Javascript as a functional language (as opposed to imperative or object-
oriented.) The first is Reginald Braithewaite's _JavaScript Allongé_.
(I believe the first edition is in some ways superior to the second, ES6-
directed one. It is more focused and somewhat more engaging. But the
code written in the ES6 version is so much more appealing because of the
language changes.) This book, while not SICP, is one of the very best
programming books I've ever read.

The other is Brian Lonsdorf's, _Mostly Adequate Guide to Functional
Programming._ I was asked by a publisher if I would consider writing a
book myself. I was considering it, but when this one came out, I said
no: this book did everything I wanted to do. This is not casual reading,
and if he ever finishes the more advanced chapters, it could get really
dense. But it is already an incredible _tour de force_.

-- Scott

[Marek Novotny]

Thanks Scott,

That is awesome that a book is being written in Git. I will check that
out.

--
Marek Novotny
-----------------------------------
email: marek....@marspolar.com
Git: https://github.com/marek-novotny
GnuPG: https://www.dropbox.com/s/ey9h0bovmok5ph8/marek.novotny_pub.asc?dl=0

[John Harris]

On Sun, 25 Sep 2016 18:23:44 +0200, Thomas 'PointedEars' Lahn
<Point...@web.de> wrote:

>WaltS wrote:
>^^^^^
>This is Usenet. Your “From” header field value should contain your *real*
>name.

<snip>

I wonder what the Pope's "real" name is? What would Thomas say?

John

[John Harris]

On Sun, 25 Sep 2016 21:23:16 +0200, Thomas 'PointedEars' Lahn
<Point...@web.de> wrote:

>WaltS wrote:
>
>> On 09/25/2016 12:23 PM, Thomas 'PointedEars' Lahn wrote:
>>> This is Usenet. Your “From” header field value should contain your
>>> *real* name.
>>
>> It legally is.
>
>That is a bold lie.

<snip>

I see. We are expected to deduce that Thomas is an expert on the law
of every country in the world and also knows which country WaltS is a
citizen of.

John

PS Ending a sentence with a preposition is legal, even if some people
prefer not to do it.

[Andreas Bergmaier]

Thomas 'PointedEars' Lahn wrote:

> <http://media.wiley.com/product_data/excerpt/31/11189033/1118903331-15.pdf>

> Page 3:
>
> | JavaScript and the Web
> |
> | […]
> | The organization that sets the standards for web pages is the World Wide
> | Web Consortium (W3C). It not only sets standards for HTML and CSS, but
> | also for how JavaScript interacts with web pages inside a web browser.
>
> Utter nonsense. The W3C specifies the Document Object Model (DOM), a
> standard of *language-independent* interfaces for interacting with documents
> written in markup languages like HTML, which are the primary focus of the
> W3C. ECMAScript implementations like JavaScript, among other programming
> languages, can then be used to access implementations of those interfaces
> and interact with DOM objects.

As you like to put it: *wrong!*.

In addition to the DOM itself, the W3 also specifies how the DOM
interfaces are to be implemented in ECMAScript:
<https://www.w3.org/TR/DOM-Level-3-Core/ecma-script-binding.html>

Of course, the cited section still seems to be dated, as the standards
are set by the WHATWG nowadays, not the W3. The HTML(5) spec
<https://html.spec.whatwg.org> is much more tightly integrated with
JavaScript, being the lingua franca of the web there is not much concern
for interoperability with other languages.

| Some parts of the language described by this specification only
| support JavaScript as the underlying scripting language. [JAVASCRIPT]
|
| Note: The term "JavaScript" is used to refer to ECMA-262, rather than
| the official term ECMAScript, since the term JavaScript is more
| widely known. Similarly, the MIME type used to refer to JavaScript in
| this specification is text/javascript, since that is the most
| commonly used type, despite it being an officially obsoleted type
| according to RFC 4329. [RFC4329]

- Bergi

[Andreas Bergmaier]

Scott Sauyet wrote:

> The undoubted best reference guide is David Flanagan's _JavaScript: The
> Definitive Guide_.

Actually I was quite disappointed when I got my hands on it. Maybe it
was just an old edition, but it did describe in detail APIs that are
completely outdated now and gave examples that would be considered a bad
practice today.

When looking for a reference guide, MDN
<https://developer.mozilla.org/en-US/docs/Web> rarely fails me (though
it does occasionally contain mistakes, being a wiki). It's not a printed
reference of course, but I'd question the usefulness of such anyway in a
world with fast-moving standards.

- Bergi

[Thomas 'PointedEars' Lahn]

Andreas Bergmaier wrote:

> Thomas 'PointedEars' Lahn wrote:
>>
<http://media.wiley.com/product_data/excerpt/31/11189033/1118903331-15.pdf>
>> Page 3:
>>
>> | JavaScript and the Web
>> |
>> | […]
>> | The organization that sets the standards for web pages is the World
>> | Wide Web Consortium (W3C). It not only sets standards for HTML and CSS,
>> | but also for how JavaScript interacts with web pages inside a web
>> | browser.
>>
>> Utter nonsense. The W3C specifies the Document Object Model (DOM), a
>> standard of *language-independent* interfaces for interacting with
>> documents written in markup languages like HTML, which are the primary
>> focus of the W3C. ECMAScript implementations like JavaScript, among
>> other programming languages, can then be used to access implementations
>> of those interfaces and interact with DOM objects.
>
> As you like to put it: *wrong!*.

I have never written “wrong!”.

> In addition to the DOM itself, the W3 also specifies how the DOM
> interfaces are to be implemented in ECMAScript:
> <https://www.w3.org/TR/DOM-Level-3-Core/ecma-script-binding.html>

First of all, you would be well-advised to check the “javascript”
newsgroups’ records [1], and read the ECMAScript Support Matrix (signature).
I, for one, am well aware of (DOM Level 2 and 3) ECMAScript *language
binding*, the history and its current status; including HTML5 and its
ecosystem.

Second, (AISB) ECMAScript is _not_ JavaScript, so your counter-argument is
invalid in that regard, too.

Third, this part of the DOM Level 3 Core Specification says how objects that
can *be used with* ECMAScript (implementations) and *implement* these
interfaces are supposed to work; it does _not_ say *which* objects should
implement these interfaces. For example, it does _not_ say that the object
referred to by the “document” property of the object referred to by the
host-defined “window” property of the ECMAScript global object should
implement the Document interface (as it is done). And it certainly does not
make the DOM interfaces language-dependent:

,-<https://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/
|
| Abstract
|
| This specification defines the Document Object Model Core Level 3, a
| platform- and language-neutral interface that allows programs and scripts
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| to dynamically access and update the content, structure and style of
| documents. […]

(Where I said “language-independent”, the W3C uses “language-neutral” which
is synonymous.)

Two common examples for that:

<https://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/java-binding.html>
<http://php.net/dom>

Fourth, DOM Level 2/3 Core applies to, but is insufficient for working with,
HTML. Therefore, ECMAScript *language binding* is also specified in DOM
Level 2 HTML for HTML 4.01 and XHTML 1.0 documents:

<https://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/ecma-script-binding.html>

Again, this is not limited to ECMAScript and its implementations:

,-<https://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/>
|
| Abstract
|
| This specification defines the Document Object Model Level 2 HTML, a
| platform- and language-neutral interface that allows programs and scripts
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| to dynamically access and update the content and structure of [HTML 4.01]
| and [XHTML 1.0] documents.

Example:

<https://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/java-binding.html>

Fifth, as far as HTML5 is concerned, the ECMAScript language binding in the
W3C DOM Level 2 HTML Specification has been superseded by the interface
specifications in the HTML5 Specification, which are based on DOM4:

<https://www.w3.org/TR/2014/REC-html5-20141028/infrastructure.html#common-dom-interfaces>
→ <https://www.w3.org/TR/2014/REC-html5-20141028/infrastructure.html#domtokenlist>
→ <https://www.w3.org/TR/2014/REC-html5-20141028/references.html#refsDOM>
→ <https://www.w3.org/TR/dom/>
currently equivalent to <https://www.w3.org/TR/2015/REC-dom-20151119/>

_______
[1] <news:1753248.o...@PointedEars.de>

> Of course, the cited section still seems to be dated,
> as the standards are set by the WHATWG nowadays, not the W3.

Utter nonsense.

> The HTML(5) spec
> <https://html.spec.whatwg.org> is much more tightly integrated with
> JavaScript, being the lingua franca of the web there is not much concern
> for interoperability with other languages.

No, as I explained several times before here, especially this year, HTML5
and the WHATWG HTML “Living Standard” (so-called) are two separate
specifications. HTML5 is developed by the W3C, WHATWG HTML by the WHATWG.

As their public communications shows, the WHATWG is a bunch of (mentally)
adolescent wannabes who can hardly be reasoned with. Unfortunately, through
their employment they have strong relations with browser vendors, so, given
the deadlock in the previous W3C HTML Working Group (WG), and the failure of
the W3C XHTML2 WG to produce a working standard, and pressure from browser
vendors increasing to renew HTML, the W3C had no choice but to give in, and
close the XHTML2 WG; so the new HTML WG uses snapshots of the WHATWG “Living
Standards” as the basis for HTML5 and its ecosystem. Were it not for the
W3C, we would be back in proprietary chaos, because that is what the WHATWG
really wants (read their manifesto carefully: they say browsers drive
standards instead of the other way around (which is true); but what they
really mean is that *their* browsers should drive standards).

,-<https://www.w3.org/TR/2014/REC-html5-20141028/>
|
| Status of This Document
|
| […]
| Work on this specification is also done at the WHATWG. The W3C HTML
| working group actively pursues convergence of the HTML specification with
| the WHATWG living standard, within the bounds of the W3C HTML working
| group charter. There are various ways to follow this work at the WHATWG:
|
| […]

> | Some parts of the language described by this specification only
> | support JavaScript as the underlying scripting language. [JAVASCRIPT]
> |
> | Note: The term "JavaScript" is used to refer to ECMA-262, rather than
> | the official term ECMAScript, since the term JavaScript is more
> | widely known.
>
> | Similarly, the MIME type used to refer to JavaScript in
> | this specification is text/javascript, since that is the most
> | commonly used type, despite it being an officially obsoleted type
> | according to RFC 4329. [RFC4329]

Which does _not_ mean, if you read more carefully, that the W3C would
specify any part of JavaScript or ECMAScript or by which objects the
interfaces are to be implemented when accessible using JavaScript (or other
ECMAScript implementations).

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:

> Andreas Bergmaier wrote:
>> | Some parts of the language described by this specification only
>> | support JavaScript as the underlying scripting language. [JAVASCRIPT]
>> |
>> | Note: The term "JavaScript" is used to refer to ECMA-262, rather than
>> | the official term ECMAScript, since the term JavaScript is more
>> | widely known.
>>
>> | Similarly, the MIME type used to refer to JavaScript in
>> | this specification is text/javascript, since that is the most
>> | commonly used type, despite it being an officially obsoleted type
>> | according to RFC 4329. [RFC4329]
>
> Which does _not_ mean, if you read more carefully, that the W3C would
> specify any part of JavaScript or ECMAScript or by which objects the
> interfaces are to be implemented when accessible using JavaScript (or
> other ECMAScript implementations).

To make it abundantly clear:

*The* *DOM* *is* *_not_* *a* *part* *of* *JavaScript/ECMAScript*.

[Thomas 'PointedEars' Lahn]

Andreas Bergmaier wrote:

> Scott Sauyet wrote:
>> The undoubted best reference guide is David Flanagan's _JavaScript: The
>> Definitive Guide_.
>
> Actually I was quite disappointed when I got my hands on it. Maybe it
> was just an old edition, but it did describe in detail APIs that are
> completely outdated now and gave examples that would be considered a bad
> practice today.

,-<http://PointedEars.de/scripts/faq/cljs/#books>
|
| 3.1 What books are recommended for javascript?
|
| Most javascript books have been found to contain so many technical errors
| that consensus recommendations have not emerged from the group.
|
| The following books have been considered to have value by some individuals
| on c.l.js. The reviews of these books are provided: […]

(I inherited this section verbatim from the previous FAQ.)

<https://ssearch.oreilly.com/?q=javascript+definitive+guide> finds only
<http://shop.oreilly.com/product/9780596805531.do>, so the current and
apparently final 6th edition was released in 2011-04 (CE).

Not only is that hopelessly outdated now given that ECMAScript Edition 5.1
was released in 2011-06 (and so that book cannot possibly cover the
corrections in Ed. 5.1; although it does cover Edition 5 of 2009-12), 6.0 in
2015-06, and 7.0 in 2016-06. It also *still* does not clearly distinguish
between the programming language and the language-neutral interfaces that
can be accessed with it. The knowing reader is forced to read:

<https://library.oreilly.com/book/9780596805531/javascript-the-definitive-guide/242.xhtml?ref=toc>
|
| Part II. Client-Side JavaScript
|
| This part of the book, Chapters 13 through 22, documents JavaScript as it
| is implemented in web browsers. These chapters introduce a variety of
| scriptable objects that represent web browser windows, documents and
| document content. They also explain important web application APIs for
| networking, storing and retrieving data, and drawing graphics: […]

It has inherited this, which now must be considered a *gross mistake*, from
its previous editions starting in 1996, when there *was* “Client-side
JavaScript” (1.0 to 1.3) in Netscape Navigator/Communicator 2.0 to 4.8.
However, with JavaScript 1.4 for Netscape Enterprise Server, Netscape made
the split and there was no more “Client-side JavaScript” in the official
reference as of Mozilla JavaScript 1.5 (2000-09) when Netscape 6.x, based on
Mozilla.org code, implemented W3C DOM Level 1 (1998-10) and shortly after,
Level 2 (2000-11). So in that sense, the book is 16 years out of date now.

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

In Flanagan’s defense, he has added a chapter describing the DOM:

<https://library.oreilly.com/book/9780596805531/javascript-the-definitive-guide/287.xhtml?ref=toc>

But he does not make clear that “Client-side JavaScript” is now actually
using *any* implementation of ECMAScript to access the language-independent
interfaces, and that *“window”* *and* *the* *rest* *of* *the* *DOM* *are*
*not* *parts* *of* *JavaScript/ECMAScript*.

And a distinction between the various differing implementations of
ECMAScript and their use in different runtime environments (*including* Web
browsers) is *still* absent, purporting the common misconception that there
is only one programming language with browser-specific “dialects” and
“bugs”, giving rise to the previous FAQ’s mistake (inherited by the current
FAQ, but at least commented on there) of talking about a convenient,
fairytale “javascript” language. There is no mention of Mozilla JavaScript
in XUL applications; V8 JavaScript in Chromium, with Node.js, and in
MongoDB; of Microsoft JScript in IE, and JScript.NET and TypeScript in VS
(Code) and for IIS/.NET Core, and JavaScript in Adobe Reader, to name just a
few.

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

Apparently the 6th edition corrected some of the more obvious blunders like
listing “[]” as an “array operator” in the “Operator Overview” section,
found and criticized by Richard Cornford here in a review of the 5th edition
in 2007. But how many of those blunders remain uncorrected is uncertain
until a full review. Back then, Richard *randomly* opened pages in that
edition and every one of them contained obvious blunders (to read it, see
above).

> When looking for a reference guide, MDN
> <https://developer.mozilla.org/en-US/docs/Web> rarely fails me (though
> it does occasionally contain mistakes, being a wiki). It's not a printed
> reference of course, but I'd question the usefulness of such anyway in a
> world with fast-moving standards.

ACK.

[John Harris]

On Tue, 27 Sep 2016 08:18:10 +0200, Thomas 'PointedEars' Lahn
<Point...@web.de> wrote:

<snip>

>giving rise to the previous FAQ’s mistake (inherited by the current
>FAQ, but at least commented on there) of talking about a convenient,
>fairytale “javascript” language.

<snip>

'For historical reasons, the term "javascript" is used herein as a
shorthand for "ECMAScript-based programming languages".'

I've read this sentence in the newFAQ several times. I cannot see how
any sane person can say it describes a fairytale “javascript”
language.

John

[Scott Sauyet]

Absolutely.

I should have said "the best printed reference guide".

There are numerous mistakes in both the decisions of what to include and
and to exclude and in details. But it gets closer than any of the
handful of other books I've read that also try to be JS reference guides.

But it doesn't come close to MDN in scope or in accuracy, and usually not
even in readability.

-- Scott