What should every JavaScript programmer know?

Question

Is there a set of things that every JavaScript programmer should know to be able to say "I know JavaScript"?

Answer 1

jQuery would be my best recommendation. Not just for the code itself, it's the idiom, the style, the thinking behind it that's most worthy of emulation.

Answer 2

Javascript objects and function as first-class citizen, callbacks, not to forget about events and then JQuery.

Answer 3

JSLint http://www.JSLint.com/

Answer 4

That JavaScript is much more different than other languages than you might think. Watch this great Google Tech Talk to get an impression: http://www.youtube.com/watch?v=hQVTIJBZook

Answer 5

How to use the good parts, and how to avoid the awful parts.

Answer 6

..that javascript is not java :)

Many, many people starting with website development have told me javascript is just simple java!

Answer 7

1. Familiarize yourself with atleast one Javascript library ( Jquery, Prototype, etc ).

2. Learn how to use the debugging tools of the major browsers ( MSIE 7-8, Firefox, Chrome, Safari )

3. Read up on the industry: Douglas Crockford's website is a treasure trove while Ajaxian.com is a good blog to keep up on new, interesting, and or odd ideas for Javascript. There are a number of other resources but those are the ones that helped me the most.

Answer 8

Understanding the stuff written in Crockford's Javascript: The Good Parts is a pretty good assumption that a person is a decent JS programmer.

You can pretty much know how to use a good library like JQuery and still not know the hidden parts of Javascript.

Another note is Debugging tools on various browsers. A JS programmer should know how to debug his code in different browsers.

Oh! And knowing JSLint will totally hurt your feelings!!

Answer 9

For knowing that Javascript was originally called LiveScript and the 'Java' prefix was attached for marketing purposes not because Java and Javascript are related (which they are not).

Oh and for owning any version of David Flanagan's 'Javascript: The Definitive Guide' (this information is on page 2).

... and for appreciating those that have gone before in trying to obfuscate Internet Explorer 4's document.all[] and Netscape Navigator 4's document.layers[] before the likes of Jquery took away the pain.

EDIT:

As @Kinopiko points out JavaScript was called project Mocha originally (some sources also reckon it was called project LiveWire) but it is generally accepted that the language (written by Brendan Eich) was slated to be released as LiveScript before the Java prefix was adopted on release in early 1996.

Answer 10

Since JS is a functional language, a decent JS programmer must be able to write Y-combinator and explain how it works off the top of head.

Answer 11

That javascript is the most widely deployed language in the world. (Probably)

Answer 12

That it can be disabled.

Answer 13

Not jQuery. Not YUI. Not (etc. etc.)

Frameworks may be useful, but they are often hiding the sometimes-ugly details of how JavaScript and the DOM actually work from you. If your aim is to be able to say “I know JavaScript”, then investing a lot of time in a framework is opposed to that.

Here are some JavaScript language features that you should know to grok what it's doing and not get caught out, but which aren't immediately obvious to many people:

• That object.prop and object['prop'] are the same thing (so can you please stop using eval, thanks); that object properties are always strings (even for arrays); what for...in is for (and what it isn't).

• Property-sniffing; what undefined is (and why it smells); why the seemingly-little-known in operator is beneficial and different from typeof/undefined checks; hasOwnProperty; the purpose of delete.

• That the Number datatype is really a float; the language-independent difficulties of using floats; avoiding the parseInt octal trap.

• Nested function scoping; the necessity of using var in the scope you want to avoid accidental globals; how scopes can be used for closures; the [closure loop problem][7].

• How global variables and window properties collide; how global variables and document elements shouldn't collide but do in IE; the necessity of using var in global scope too to avoid this.

• How the function statement acts to ‘hoist’ a definition before code preceding it; the difference between function statements and function expressions; why named function expressions should not be used.

• How constructor functions, the prototype property and the new operator really work; methods of exploiting this to create the normal class/subclass/instance system you actually wanted; when you might want to use closure-based objects instead of prototyping. (Most JS tutorial material is absolutely terrible on this; it took me years to get it straight in my head.)

• How this is determined at call-time, not bound; how consequently method-passing doesn't work like you expect from other languages; how closures or Function#bind may be used to get around that.

• Other ECMAScript Fifth Edition features like indexOf, forEach and the functional-programming methods on Array; how to fix up older browsers to ensure you can use them; using them with inline anonymous function expressions to get compact, readable code.

• The flow of control between the browser and user code; synchronous and asynchronous execution; events that fire inside the flow of control (eg. focus) vs. events and timeouts that occur when control returns; how calling a supposedly-synchronous builtin like alert can end up causing potentially-disastrous re-entrancy.

• How cross-window scripting affects instanceof; how cross-window scripting affects the control flow across different documents; how postMessage will hopefully fix this.

Most of all, you should be viewing JavaScript critically, acknowledging that it is for historical reasons an imperfect language (even more than most languages), and avoiding its worst troublespots. Crockford's work on this front is definitely worth reading (although I don't 100% agree with him on which the “Good Parts” are).

[7]: http://stackoverflow.com/questions/2568966/how-do-i-pass-the-value-not-the-reference-of-a-js-variable-to-a-function f

Answer 14

object literals because they are so nice to write.

Answer 15

If you want to be a true JavaScript ninja, you should know the answers to every question in the Perfection kills JavaScript Quiz.

An example to whet your appetite:

(function f(f){ 
  return typeof f(); 
})(function(){ return 1; });

What does this expression return?

• “number”
• “undefined”
• “function”
• Error

Answer 16

You know JavaScript if the following statements return true:

1. You know the fundamentals of JavaScript, such as objects are in fact hashes, the language is functional and prototype based. And that JavaScript's official name is ECMAScript.
2. You must have at least read 2 books regarding the subject and understand the code that's inside that book. If you could answer a bunch of answers here on SO regarding JavaScript, it helps too.
3. You should understand the language as is, that frameworks/libraries only increase your productivity. In case of web development, you should understand it works most of the time client-side (unless you have a server side technology such as JAXER) and how it access the DOM.
4. The understanding of the Event Model.
5. If you could change a statical website into an AJAX-driven or dynamical website without a sweat, you can pretty much say you know JavaScript.

Gotta say though, knowing something doesn't make you an expert of the subject.

Answer 17

One should be aware about the following to say "I Know JavaScript":

1. JavaScript is good but DOM is pain point
2. Cross browser issues can make you go crazy
3. Unless code is tested on least 4 different good browsers you can't say its bug free
4. Closure.............. Must know
5. Its prototype based ........... Nice one its fun to learn this
6. debugger keyword ..... Helps in crisis

Answer 18

... about Google Web Toolkit, which means that your javascript project probably could be developed in a much more conveniant way.

Answer 19

I strongly recommend to read Javascript: The Good Parts

Answer 20

Variables are global unless declared to be local!!

Bad (DoSomething() is only called 10 times):

function CountToTen()
{
  for(i=0; i< 10; i++)
  {
    DoSomething(i);
  }
}

function countToFive()
{
  for(i=0; i<5; i++)
  {
    CountToTen();
  }
}

CountToFive();

Good (DoSomething() is called 50 times as intended):

function CountToTen()
{
  var i;
  for(i=0; i< 10; i++)
  {
    DoSomething(i);
  }
}

function countToFive()
{
  var i;
  for(i=0; i<5; i++)
  {
    CountToTen();
  }
}

CountToFive();

Answer 21

The following things are also important:

1) Variable hoisting. 2) Scope chains and activation objects.

and then things like these: :)

3) wtfjs.com

4)

Answer 22

Having read all the above, it's also perfectly fine to learn Javascript by using a framework like jQuery. The truth is it's the first way a lot of folks picked JS up in the first place. No shame in that.

Answer 23

You don't know JavaScript if you don't know:

1. Closures
2. Prototype-based inheritance
3. The module pattern
4. The W3C-DOM
5. How events work

Answer 24

What every javascript coder should know?

How about, I can turn off your efforts with 2 clicks. So provide a fallback if possible.

Answer 25

That Javascript is not something which can be learnt in an hour!

Answer 26

You know javascript if you can use Array, Number, String, Date and Object effectively. Plus points for Math and RegExp. You should be able to write functions and use variables (in correct scope, i.e. as 'methods' of an object).

I see some comments about knowing closures, extravagant function syntax, blabla. All that is quite irrelevant for this question. That's like saying you are a runner if you can run the 100m dash under 11 seconds.

I say it takes maybe a couple of weeks to become proficient in javascript. After that it takes years and dozens of books and thousands of lines of programming to become an expert, a ninja, etc.

But that wasn't the question.

Oh, and the DOM is not a part of javascript, and neither is jQuery. So I think both are equally irrelevant to the question too.

Answer 27

1. Knowing that there is a life with and without with() and where to draw the line.
2. You can create custom errors with the throw statement to purposely stop the javascript runtime.

Answer 28

In Javascript, Performance matters.

There is not an intelligent compiler to optimize your code so You should be more careful while you are writing javascript code than languages like C#, Java...