6 ms·

A re-introduction to JavaScript

149 points by rajesht 16y ago

andrew-bor 16y ago
Despite hundreds of thousands of search results in Google when you're looking for "Javascript tutorial" this one is by far the best one for a beginner.
- commandar 16y ago
  Provided you have some familiarity with C like languages. I'm skimming through this now, and it really is quite well-written, but I'd be totally lost if I didn't have some experience with C/C++ in school years ago since it does make a number of assumptions that you'll just 'get it' -- e.g., the section on for loops pretty much says "they work like in C." :)
aborovoy 16y ago
Question to JavaScript gurus: how would i know if my code works in various browserless environments like Reeno and V8? Is there a compatibility table of various JS features is isn't browser-centric? Thanks!
- geuis 16y ago
  Don't down vote this fellow's question, its perfectly valid and interesting. First, you have to make a distinction between Javascript(ECMAScript) the language, and the API's that an environment makes available to it. A good example of this is document.getElementById(). This is universally found in browsers, but you won't find this in Node.js (a server-side javascript environment using V8). Conversely, Node makes available Buffers which you won't find in any browser. I think the best way to answer your question is to identify in the respective environments which version of ECMAScript they claim to support. Various versions of each browser support different versions of ECMAScript, or such as Internet Explorer where earlier versions supported a variant called JScript that didn't always tie directly to the published standards. The wikipedia page is a good place to start, http://en.wikipedia.org/wiki/ECMAScript http://en.wikipedia.org/wiki/ECMAScript.
- tlrobinson 16y ago
  Get "JavaScript: The Definitive Guide" and look at the API reference, it's split into two sections, one for APIs provided with every JavaScript implemetation, and one for APIs provided by browsers. Currently there's not much compatibility between server-side JavaScript platforms (beyond the minimal set of APIs provided by the language implementations), something we're trying to solve with CommonJS, but that effort has been inhibited by node.js's sudden rise in popularity and refusal to work with CommonJS...
  - micrypt 16y ago
    "refusal to work with CommonJS..." I thought this was a thing of past. Node.js is listed on the CommonJS website: http://www.commonjs.org/impl/ http://www.commonjs.org/impl/
    - tlrobinson 16y ago
      Node has CommonJS modules, which is a good start, but that's it.
- pdelgallego 16y ago
  The best option is to avoid everything that is not part ECMAScript 262, and even programming according to the spec you maybe at some point some inconsistencies. Check out the sputnik test project[1] to see what is working in the different VM. An easy example of inconsistency : If you read the specs you will find that FunctionDeclarations are only allowed to appear in Program or FunctionBody. Syntactically, they can not appear in Block s. But because the specs allowed extensions you can find that Mozilla/rhino/spidermonkey implement a different way that Webkit/V8 run this code in firebug and in the inspector a you will see that produce two difference. <code><pre> if (true) { function foo(){ return 1; } } else { function foo(){ return 2; } } foo(); </pre><code> Indeed things are not that bad, because is easy to avoid it. var foo; if (true) { foo = function foo(){ return 1; }; } else { foo = function foo() { return 2; }; } [1]sputnik.googlelabs.com/
  - pdelgallego 16y ago
    I mean === if (true) { function foo(){ return 1; } } else { function foo(){ return 2; } } foo(); === if (true) { foo = function (){ return 1; } } else { foo = function (){ return 2; } } foo();
- zwetan 16y ago
  tests for those environments Sure sticking to ECMA-262 can help http://www.ecma-international.org/publications/standards/Ecma-262.htm http://www.ecma-international.org/publications/standards/Ecm... you can read, re-read, etc. the spec to get a good feel of the language but at the end of the day, some hosts could implement things a bit differently, especially on the "blurry" parts of the spec. For example, two engines could support regexp but have a slightly different implementation and be both valid ECMA-262 edition 3, idem for number precisions, etc. So if your main concern is to avoid browser-centric JS features, test with the engine of those browsers http://en.wikipedia.org/wiki/JavaScript_engine http://en.wikipedia.org/wiki/JavaScript_engine * Chrome => V8 * Firefox => SpiderMonkey / TraceMonkey * Internet Explorer => IE JScript / Chakra * Safari => JavaScriptCore / SquirrelFish * etc. most of the browsers will provide their engine as a command line tool ex: https://developer.mozilla.org/en/Building_only_SpiderMonkey https://developer.mozilla.org/en/Building_only_SpiderMonkey (for IE you can use Windows Script Host). and simply put, you can run your JS code base on those tools to find the common denominator and/or limitations, imho it is simpler to run tests on the command line than in the browser itself. If already your library work with all the engines you're in pretty good shape. Another way to be in "good shape" is to simply re-use one of the popular JS libraries, like JQuery, as those are pretty well tested. But to be honest it depends on how far you want to go, most likely testing only the JS engine will not be enough if you deal a lot with the browser DOM, you will have to test in the browsers anyway, and there that's where the fun begin, because as much as you can find slight difference of implementations in JS engine, you can find bigger differences in browser implementations, yep even if all that is supposed to be "standard". here few links that may help http://www.quirksmode.org/js/support.html http://www.quirksmode.org/js/support.html http://www.quirksmode.org/compatibility.html http://www.quirksmode.org/compatibility.html http://www.quirksmode.org/js/introevents.html http://www.quirksmode.org/js/introevents.html http://ejohn.org/blog/building-a-javascript-library/ http://ejohn.org/blog/building-a-javascript-library/ http://code.google.com/speed/articles/optimizing-javascript.html http://code.google.com/speed/articles/optimizing-javascript....
csallen 16y ago
Just a heads up, article was last significantly edited in March '06.
- banuelios 16y ago
  Look a few lines down: Page last modified 10:04, 30 Jun 2010 by user01
  - edd 16y ago
    No really it was last significantly edited in 2006. Look at the contents of the revisions for the past 3 1/2 years: https://developer.mozilla.org/index.php?title=en/JavaScript/A_re-introduction_to_JavaScript&action=diff&revision=57&diff=77 https://developer.mozilla.org/index.php?title=en/JavaScript/...
- tlrobinson 16y ago
  Fortunately (unfortunately?) the language hasn't significantly changed either.
- sloniks 16y ago
  What has changed since then?
  - jackmoore 16y ago
    My only qualm is that it gives advice on how to use arguments.callee, which was depreciated in ECMAScript 5, for recursive anonymous functions. Since they already give an example of how to use a named function recursively, the arguments.callee example could just simply be removed.
AlexMuir 16y ago
I've been using Javascript for years and never really 'learned it'. It's just something I've dipped into to solve a particular problem - largely through just grabbing other code/dissecting existing stuff. Then I got hold of jQuery and never learned about the underlying language. This was great to catch up on the basics.
llaxsll 16y ago
This article has a good description of closures, which is very important to brush up on if one is developing a heavy dhtml site. Thanks.
- AlexMuir 16y ago
  DHTML - That's a blast from the past. Don't see that acronym any more.
  - llaxsll 16y ago
    What would you call it, Mr. AlexMuir ? :)
    - AlexMuir 16y ago
      I'm not saying it's the wrong term, just that I've not seen it for ages. I think people just sort of take it for granted nowadays that HTML probably includes Javascript, rendering the D for dynamic a bit redundant.
jckarter 16y ago
An introduction really shouldn't encourage things like "for (var i = 0, item; item = a[i]; i++)". Someone's going to cut-and-paste that because it looks cute, and their code will break when their array suddenly needs to contain null values. Fuzzy boolean semantics are bad enough without spreading stuff like this around (speaking from experience with || abuse in Perl).
- freakwit 16y ago
  To be fair, they do note this shortcoming. "Note that this trick should only be used for arrays which you know do not contain "falsy" values (arrays of objects or DOM nodes for example). If you are iterating over numeric data that might include a 0 or string data that might include the empty string you should use the i, j idiom instead."
  - WilliamLP 16y ago
    So it should be used approximately never in real code.
- jackmoore 16y ago
  Agreed. But what is the point of declaring the item variable? Wouldn't "for (var i = 0; a[i]; i++)" mean the same thing, but more concise?
- jackmoore 16y ago
  I also think it should discourage modifying built-in objects. Unlike their for loop, the following line comes with no warning or disclaimer: "Interestingly, you can also add things to the prototype of built-in JavaScript objects."
jasonjohnson 16y ago
Not a bad guide, old as it may be. Chuckled a bit when I read, "JavaScript has a tertiary operator for one-line conditional statements..." - been in there since the original version. http://en.wikipedia.org/wiki/Ternary_operation http://en.wikipedia.org/wiki/Ternary_operation
- WilliamLP 16y ago
  That could be worked into a great programming language misappropriation-based comedy routine! Also the one about the guy who said "overriding" when he meant "overloading" is usually good for a laugh.
ams6110 16y ago
Glad to see they linked Crockford's site. I discovered his site probably four years ago or so and it really opened my eyes to the capabilities of the language. I think anyone who wants to learn more about JavaScript should definitely include Crockford in his studies.
michaeltwofish 16y ago
This article provided my "aha!" moment for prototypes.
limist 16y ago
If you like this article, you'll love the book "Javascript: The Good Parts": http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockford/dp/0596517742 http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor...

149 points by rajesht 16y ago

Despite hundreds of thousands of search results in Google when you're looking for "Javascript tutorial" this one is by far the best one for a beginner.

commandar 16y ago
Provided you have some familiarity with C like languages. I'm skimming through this now, and it really is quite well-written, but I'd be totally lost if I didn't have some experience with C/C++ in school years ago since it does make a number of assumptions that you'll just 'get it' -- e.g., the section on for loops pretty much says "they work like in C." :)

aborovoy 16y ago

Question to JavaScript gurus: how would i know if my code works in various browserless environments like Reeno and V8? Is there a compatibility table of various JS features is isn't browser-centric? Thanks!

geuis 16y ago
Don't down vote this fellow's question, its perfectly valid and interesting. First, you have to make a distinction between Javascript(ECMAScript) the language, and the API's that an environment makes available to it. A good example of this is document.getElementById(). This is universally found in browsers, but you won't find this in Node.js (a server-side javascript environment using V8). Conversely, Node makes available Buffers which you won't find in any browser. I think the best way to answer your question is to identify in the respective environments which version of ECMAScript they claim to support. Various versions of each browser support different versions of ECMAScript, or such as Internet Explorer where earlier versions supported a variant called JScript that didn't always tie directly to the published standards. The wikipedia page is a good place to start, http://en.wikipedia.org/wiki/ECMAScript http://en.wikipedia.org/wiki/ECMAScript.
tlrobinson 16y ago
Get "JavaScript: The Definitive Guide" and look at the API reference, it's split into two sections, one for APIs provided with every JavaScript implemetation, and one for APIs provided by browsers. Currently there's not much compatibility between server-side JavaScript platforms (beyond the minimal set of APIs provided by the language implementations), something we're trying to solve with CommonJS, but that effort has been inhibited by node.js's sudden rise in popularity and refusal to work with CommonJS...
- micrypt 16y ago
  "refusal to work with CommonJS..." I thought this was a thing of past. Node.js is listed on the CommonJS website: http://www.commonjs.org/impl/ http://www.commonjs.org/impl/
  - tlrobinson 16y ago
    Node has CommonJS modules, which is a good start, but that's it.
pdelgallego 16y ago
The best option is to avoid everything that is not part ECMAScript 262, and even programming according to the spec you maybe at some point some inconsistencies. Check out the sputnik test project[1] to see what is working in the different VM. An easy example of inconsistency : If you read the specs you will find that FunctionDeclarations are only allowed to appear in Program or FunctionBody. Syntactically, they can not appear in Block s. But because the specs allowed extensions you can find that Mozilla/rhino/spidermonkey implement a different way that Webkit/V8 run this code in firebug and in the inspector a you will see that produce two difference. <code><pre> if (true) { function foo(){ return 1; } } else { function foo(){ return 2; } } foo(); </pre><code> Indeed things are not that bad, because is easy to avoid it. var foo; if (true) { foo = function foo(){ return 1; }; } else { foo = function foo() { return 2; }; } [1]sputnik.googlelabs.com/
- pdelgallego 16y ago
  I mean === if (true) { function foo(){ return 1; } } else { function foo(){ return 2; } } foo(); === if (true) { foo = function (){ return 1; } } else { foo = function (){ return 2; } } foo();
zwetan 16y ago
tests for those environments Sure sticking to ECMA-262 can help http://www.ecma-international.org/publications/standards/Ecma-262.htm http://www.ecma-international.org/publications/standards/Ecm... you can read, re-read, etc. the spec to get a good feel of the language but at the end of the day, some hosts could implement things a bit differently, especially on the "blurry" parts of the spec. For example, two engines could support regexp but have a slightly different implementation and be both valid ECMA-262 edition 3, idem for number precisions, etc. So if your main concern is to avoid browser-centric JS features, test with the engine of those browsers http://en.wikipedia.org/wiki/JavaScript_engine http://en.wikipedia.org/wiki/JavaScript_engine * Chrome => V8 * Firefox => SpiderMonkey / TraceMonkey * Internet Explorer => IE JScript / Chakra * Safari => JavaScriptCore / SquirrelFish * etc. most of the browsers will provide their engine as a command line tool ex: https://developer.mozilla.org/en/Building_only_SpiderMonkey https://developer.mozilla.org/en/Building_only_SpiderMonkey (for IE you can use Windows Script Host). and simply put, you can run your JS code base on those tools to find the common denominator and/or limitations, imho it is simpler to run tests on the command line than in the browser itself. If already your library work with all the engines you're in pretty good shape. Another way to be in "good shape" is to simply re-use one of the popular JS libraries, like JQuery, as those are pretty well tested. But to be honest it depends on how far you want to go, most likely testing only the JS engine will not be enough if you deal a lot with the browser DOM, you will have to test in the browsers anyway, and there that's where the fun begin, because as much as you can find slight difference of implementations in JS engine, you can find bigger differences in browser implementations, yep even if all that is supposed to be "standard". here few links that may help http://www.quirksmode.org/js/support.html http://www.quirksmode.org/js/support.html http://www.quirksmode.org/compatibility.html http://www.quirksmode.org/compatibility.html http://www.quirksmode.org/js/introevents.html http://www.quirksmode.org/js/introevents.html http://ejohn.org/blog/building-a-javascript-library/ http://ejohn.org/blog/building-a-javascript-library/ http://code.google.com/speed/articles/optimizing-javascript.html http://code.google.com/speed/articles/optimizing-javascript....

csallen 16y ago

Just a heads up, article was last significantly edited in March '06.

banuelios 16y ago
Look a few lines down: Page last modified 10:04, 30 Jun 2010 by user01
- edd 16y ago
  No really it was last significantly edited in 2006. Look at the contents of the revisions for the past 3 1/2 years: https://developer.mozilla.org/index.php?title=en/JavaScript/A_re-introduction_to_JavaScript&action=diff&revision=57&diff=77 https://developer.mozilla.org/index.php?title=en/JavaScript/...
tlrobinson 16y ago
Fortunately (unfortunately?) the language hasn't significantly changed either.
sloniks 16y ago
What has changed since then?
- jackmoore 16y ago
  My only qualm is that it gives advice on how to use arguments.callee, which was depreciated in ECMAScript 5, for recursive anonymous functions. Since they already give an example of how to use a named function recursively, the arguments.callee example could just simply be removed.

AlexMuir 16y ago

I've been using Javascript for years and never really 'learned it'. It's just something I've dipped into to solve a particular problem - largely through just grabbing other code/dissecting existing stuff. Then I got hold of jQuery and never learned about the underlying language. This was great to catch up on the basics.

llaxsll 16y ago

This article has a good description of closures, which is very important to brush up on if one is developing a heavy dhtml site. Thanks.

AlexMuir 16y ago
DHTML - That's a blast from the past. Don't see that acronym any more.
- llaxsll 16y ago
  What would you call it, Mr. AlexMuir ? :)
  - AlexMuir 16y ago
    I'm not saying it's the wrong term, just that I've not seen it for ages. I think people just sort of take it for granted nowadays that HTML probably includes Javascript, rendering the D for dynamic a bit redundant.

jckarter 16y ago

An introduction really shouldn't encourage things like "for (var i = 0, item; item = a[i]; i++)". Someone's going to cut-and-paste that because it looks cute, and their code will break when their array suddenly needs to contain null values. Fuzzy boolean semantics are bad enough without spreading stuff like this around (speaking from experience with || abuse in Perl).

freakwit 16y ago
To be fair, they do note this shortcoming. "Note that this trick should only be used for arrays which you know do not contain "falsy" values (arrays of objects or DOM nodes for example). If you are iterating over numeric data that might include a 0 or string data that might include the empty string you should use the i, j idiom instead."
- WilliamLP 16y ago
  So it should be used approximately never in real code.
jackmoore 16y ago
Agreed. But what is the point of declaring the item variable? Wouldn't "for (var i = 0; a[i]; i++)" mean the same thing, but more concise?
jackmoore 16y ago
I also think it should discourage modifying built-in objects. Unlike their for loop, the following line comes with no warning or disclaimer: "Interestingly, you can also add things to the prototype of built-in JavaScript objects."

jasonjohnson 16y ago

Not a bad guide, old as it may be. Chuckled a bit when I read, "JavaScript has a tertiary operator for one-line conditional statements..." - been in there since the original version. http://en.wikipedia.org/wiki/Ternary_operation http://en.wikipedia.org/wiki/Ternary_operation

WilliamLP 16y ago
That could be worked into a great programming language misappropriation-based comedy routine! Also the one about the guy who said "overriding" when he meant "overloading" is usually good for a laugh.

ams6110 16y ago

Glad to see they linked Crockford's site. I discovered his site probably four years ago or so and it really opened my eyes to the capabilities of the language. I think anyone who wants to learn more about JavaScript should definitely include Crockford in his studies.

michaeltwofish 16y ago

This article provided my "aha!" moment for prototypes.

limist 16y ago

If you like this article, you'll love the book "Javascript: The Good Parts": http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockford/dp/0596517742 http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor...