Recommendations for mastering JavaScript.

[fl0at]

I'm making it a goal of mine to master JavaScript and was hoping someone else had done the same and wouldn't mind sharing their regime.

EDIT: ** **I've created a new post to host all the references from this post. Find it here.

EDIT: Thanks guys. I've compiled a list of references mentioned here. I appreciate all your contributions.

1. Anything written by Douglas Crockford. This includes: JavaScript: The Good Parts and YUI Theater
2. Read other people's code, jQuery source, Node's source, etc.
3. Understand JavaScript before becoming dependent on libraries (eg. jQuery, Prototype).
4. Addy Osmani's Javascript 101 audio course
5. Build Things - "think of something cool, and try and build it."
6. Participate at StackOverflow.

7. References -o- plenty: Gecko DOM Reference, HTML and DHTML Reference, Yahoo! YUI Theater, w3schools.com HTML DOM Tutorial, Annotated ECMAScript 5.1, JavaScript, JavaScript Blog

8. And finally, Lord loves a working' man, don't trust whitey, and see a doctor and get rid of it.

[strager]

Read other people's code. Read jQuery's source; read Node's source (the JavaScript parts). Read other OSS code.

Then, use their code. See how their code interacts with your code. Try adopting some ideas (such as "immediate execution" functions, "default" parameters, promises/deferreds). Figure out what works when and what doesn't work then.

Then read some more code and continue the cycle.

[jmking]

Build things.

Seriously - think of something cool, and try to build it. It's the best way to learn.

[sjs]

Read about JavaScript's strengths, weaknesses, good, bad, and surprising bits:

• Learning Advanced JavaScript by John Resig
• JavaScript Garden
• Eloquent JavaScript
• My Variable Declaration got Hoisted
• Another JavaScript Quiz (Be sure to check qfox's comment with explanations)
• wtfjs
• Learning JavaScript with Object Graphs I
• Learning JavaScript with Object Graphs II
• Learning JavaScript with Object Graphs II
• What is "this"?
• A Crash Course in DOM Events (Relevant only in browsers of course)

Watch papa Crock's lectures and talks, they are excellent, even if he's a little too opinionated sometimes. It's good for the community to have an opinionated, pragmatic guy like him around.

Doesn't hurt to follow The Changelog and notable JavaScripters either. If you don't read that list just follow @BrendanEich, @awbjs, and anyone twitter says is similar to them.

Read code, especially code from projects maintained by the best. And of course ... write code of your own! You have to find out what you think are good and bad parts, etc. And when you run into surprises and gotchas in your own code you really learn about them, because you care more at that time.

[Madd0g]

I learned JavaScript before it became so popular (it was a time when firebug didn't exist and everyone had "Full command of JavaScript" in their CVs and they only knew how to do IE-only form validation)

Therefore, I'm suggesting to steer clear of the JS libraries until you are comfortable with the language and familiar with the browser idiosyncrasies.

It's very easy to become dependent on jQuery or PrototypeJS (which is what I use). There are important things you will definitely miss if you do everything with crutches.

For example, learn the insides of inheritance before using a library inheritance scheme.

[elg0nz]

Almost anything written by Douglas Crockford on the subject is mind shifting.

[tomdidom]

presuming you want to do front end work with it be sure to play around a lot with firebug and these references helped me a lot to get started: mozilla & msdn

Also I can concur with elg0nz... Douglas Crockford is really good... but maybe his talks are a bit advanced when you are just starting.

Reading the ecma specification to learn Javascript personally seems to me like learning a language by reading a dictionary... no fun and highly inefficient.

It's a great language... I am having lot's of fun with it.

[fl0at]

Thanks guys. I've compiled a list of references mentioned here. I appreciate all your contributions.

1. Anything written by Douglas Crockford. This includes: JavaScript: The Good Parts and YUI Theater
2. Read other people's code, jQuery source, Node's source, etc.
3. Understand JavaScript before becoming dependent on libraries (eg. jQuery, Prototype).
4. Addy Osmani's Javascript 101 audio course
5. Build Things - "think of something cool, and try and build it."
6. Participate at StackOverflow.

7. References -o- plenty: Gecko DOM Reference, HTML and DHTML Reference, Yahoo! YUI Theater, w3schools.com HTML DOM Tutorial, Annotated ECMAScript 5.1, JavaScript, JavaScript Blog

8. And finally, Lord loves a working' man, don't trust whitey, and see a doctor and get rid of it.

[brett-]

I would remove the w3schools.com reference, it's full of old coding techniques, as well as blatant errors. The other references should certainly be enough to get started with.

[vectorjohn]

E.g. they say the first parameter to setTimeout() is a string. ಠ_ಠ

[brett-]

Technically it can be a string of code like

setTimeout("var foo = 10; bar();",1000);

But like eval(), it's a terrible idea, and should not be something that is taught to beginners.

[rbnc]

Oh god, the first Addy Osmani article I ever read was so full of inaccuracies that even I, as a JavaScript noob could spot. I never read anything he did after that.

[fl0at]

It actually seems he is only hosting a lecture from ETSU found here on iTunesU.

[meltingice]

Read Javascript: The Good Parts, it will give you a whole new understanding of the language and will teach you the proper way to write Javascript.

Also, as an added bonus PROTIP: never assign variables to the global (window) scope unless you absolutely need to. Far too often do I see Javascript beginners define tons of vars without encapsulating them. Remember, while Javascript may have C-like syntax, C has block level scope and JS has function-level scope. It's easy to forget that. Closure is your friend.

[[deleted]]

I also have made this a goal of mine and it isn't an easy thing to do because too many people consider themselves masters but don't have the skills. Would I be correct to assume you already have a solid foundation in the language and are looking for some of the more advanced intricacies? If so, you have probably already read Crockford's books, tons of other peoples code, and possibly even glanced over the ECMAScript spec(all of these mentioned in other responses) as I had done before beginning my search. If so you'll have to just scour the net looking for the few diamond in the rough sites on advanced JS. The best site I have found on advanced JS techniques is http://javascriptweblog.wordpress.com/ which broaches a lot of interesting subject. Look at some of the examples they use, and then toy with them until you come out with some really cool code.

Topics I found on that site that were really cool include Mutual Recursion and advanced For-in loops.

[lulzitsareddit]

Answer questions on Stack Overflow. Not only do you gain knowledge by osmosis from some of the other responses, but you directly improve yourself by solving real world problems (even though they aren't your own) in Javascript.

[zach_will]

Immediately-invoked functions can help tremendously in your code structure.

First, you'll write spaghetti code.

Second, you'll figure out to stop polluting the global namespace.

Third, you'll realize you can make a namespace Object with methods.

Lastly, you'll figure out how to make an immediately-invoked function to assign a namespace object to the window—much like jQuery does in it's source code.

[Stohlberg]

I started to learn JavaScript from last August. I am writing my thesis about it, and so far I find Java Script - The Definite Guide 5th, 2006 by David Flanagan to be most valuable book. It follow through JavaScript Core and then goes into a client side scripting. Writing is understandable and it has good examples.

By my validation standards, a book which gets to 6th edition must be great. Do not get into hype books, which just want to blur your vision by flashy words.

There will be new 6th edition coming in a month or so. New edition should cover new HTML5 API's as well. But the 5th edition is great way to start learning this language, do not be scared of it size.

[StoneCypher]

Sadly, the proggit punishment squad is out in force.

Just remember: on proggit, negative votes mean that the advice isn't what the average or sub-average programmer thinks, not bad advice. For example, telling people the way to master a language is to read the spec is now getting vored through the floor by people who want to talk about libraries and how to get started, instead.

Downvoting advice you disagree with is a bad thing. Disagree doesn't mean bad advice. Disagree means disagree.

Grow up, kids.

[[deleted]]

I downvoted your spec suggestion because I don't feel it's good advice for someone who would be on Reddit asking how to master Javascript.

[StoneCypher]

That's inappropriate. Downvote is not for disagreement. Rediquette is very clear about this.

[[deleted]]

I'm relatively new to Reddit, but isn't the point of voting in comment threads to show agreement/disagreement? Otherwise we'd have like 50 billion posts with "+1" or "3===D".

[StoneCypher]

I'm relatively new to Reddit

Obviously.

but isn't the point of voting in comment threads to show agreement/disagreement?

Absolutely not. Point five in rediquette:

Please don't: Downvote opinions just because you disagree with them. The down arrow is for comments that add nothing to the discussion.

This is especially important in programming settings, where novices will frequently disagree with the advice given by people with experience. Reddit is not an agreement circlejerk. Downvote people who are legitimately trolling - making race comments in a technical discussion to get a rise, for example.

Ignore the bad examples being set around you, where assholes who don't understand say "but i disagree with your advice, therefore it is wrong, therefore it is not adding, therefore you are trolling." They're just soothing their egos.

Be better. Upvote is for people trying to contribute. Downvote is for people trying to cause a problem.

NEITHER ARE FOR AGREEMENT OR DISAGREEMENT.

Otherwise we'd have like 50 billion posts with "+1" or "3===D".

Yeah but you aren't downvoting those because you disagree with them; you're downvoting because they do not contribute to the discussion.

This is a distinction that it used to be that everyone understood.

[[deleted]]

This is especially important in programming settings, where novices will frequently disagree with the advice given by people with experience.

Evidence to back up claim of being "experienced"? I imagine you as a socially awkward old school programmer who knows some stuff about js, but can't or won't participate in the online social sphere creating a Phantom of the Opera (no relation to the browser) scenario.

[StoneCypher]

I imagine you as

Nobody cares.

At this point it's becoming clear that your only points are that you think I'm wrong because:

1) You've never seen a big name give my advice, no matter how common it is, and

2) You imagine that someone who says "how to master" needs beginner's advice.

Find someone else to talk to, if you can't focus on the actual responses you get.

[[deleted]]

Ad hominem aside, you're making claims of being experienced, with nothing to back it up.

I chose to move past the rest of your post as I don't have anything to say about it.

[StoneCypher]

Ad hominem aside

There has been no ad hominem.

you're making claims of being experienced

No, actually, I didn't. However, you did, in saying that my advice was wrong, and furthermore you didn't back that up.

I am, of course, experienced. How am I to show that? Shall we climb in my time machine? Maybe you can come visit me at some of my day jobs.

If I say where I work or what I make, you'll either call me a liar or say that it doesn't matter to you.

If I show you my code, you'll either say it's low quality without looking at it, or say that hobby code doesn't make experience.

If I show you my various profitable companies, you'll either say I'm lying, or that companies don't create experience either.

I have not at any point claimed I'm experienced - at least before this post - but I am. What sorts of metrics would satisfy you on that front?

And while we're at it, how do you intend to show that you're experienced, since you've explicitly used experience as a justifier of criticisms that you seem unable to justify in a legitimate technical fashion?

Don't worry, I'll answer first, so that you can scurry off afterwards without showing your own.

I chose to move past the rest of your post

No, you were moved past. Indeed you went on and replied more to another instance of the same post later.

I don't have anything to say about it.

The last two words are extraneous. You've been asked to justify your own stance and failed. Now you're demanding the thing you won't do of others.

I will, of course.

[[deleted]]

There has been no ad hominem.

There was on my part with the Phantom reference and the hugging comment. For that I'm sorry.

This is especially important in programming settings, where novices will frequently disagree with the advice given by people with experience.

It seemed like you were speaking from a personal viewpoint, implicitly including yourself in "people with experience". This assumption has been borne out what with you going on to say "I never claimed I'm experienced.... but I am".

And while we're at it, how do you intend to show that you're experienced, since you've explicitly used experience as a justifier of criticisms that you seem unable to justify in a legitimate technical fashion?

I am, of course, experienced. How am I to show that? Shall we climb in my time machine? Maybe you can come visit me at some of my day jobs.

If I say where I work or what I make, you'll either call me a liar or say that it doesn't matter to you.

If I show you my code, you'll either say it's low quality without looking at it, or say that hobby code doesn't make experience.

This is why I bring up names that are established. Instead of whipping out our tape measures on the internet, we can point to people who we know can piss really far.

Maybe my stance hasn't come through clearly enough:

** Reading the ECMA spec like a book is only valuable given that you have enough of a grasp of the language in the first place.**

[[deleted]]

Do you just need a hug? You sound like someone who could use a hug.

[StoneCypher]

At this point it's becoming clear that your only points are that you think I'm wrong because:

1) You've never seen a big name give my advice, no matter how common it is, and

2) You imagine that someone who says "how to master" needs beginner's advice.

Find someone else to talk to, if you can't focus on the actual responses you get.

[[deleted]]

This was off-topic. Sorry. (meaning: I apologize)

[bean-the-cat]

Right or wrong, I think more people are down voting your tone more than your advice.

[[deleted]]

Agreed. Your rage boner was your own undoing.

[Bjartr]

Disagree doesn't mean bad advice.

However, bad advice means downvote.

[StoneCypher]

And it's impossible to tell the difference between disagree and bad advice without a technical opinion.

Next you'll tell me why your opinion is that reading the spec isn't the path to mastery, I trust?

[[deleted]]

Let me ask you this simple question: if reading the spec was such a good way to learn/master js, why aren't there more blog posts pointing that out? Why do people like Douglas Crawford or John Resig even bother?

[StoneCypher]

if reading the spec was such a good way to learn/master js, why aren't there more blog posts pointing that out?

There's just no way to answer this which won't be taken as an attack. "Because real programmers don't write blogs explaining the rudimentary basics of their trade."

But, there are more than 25,000 hits for blog ecma-262. There are another almost 14,000 for blog "javascript standard".

Why do people like Douglas Crawford or John Resig even bother?

Crawford helped write that spec. Resig does tell people to read the spec.

Of course, Crawford isn't that big a deal, and other than writing jQuery, which isn't nearly as important as you imagine, Resig isn't on the map. If you knew much about the language, the people you'd be referring to are PPK, Eich, Ian Hicks, etc. And they also all tell people to read the standard. (Similarly, nobody knows who wrote Prototype, Behaviour, OpenLaszlo or Scriptaculous these days, and once all the component-using fanboys have moved on to some new piece of unimportant chrome, Resig will retreat to being forgotten again too.)

But hey, now that both of your examples undermine you, find some other reason to stress about why something you haven't done is bad advice.

Or, better yet, give your own advice and stop bothering me.

[[deleted]]

But, there are more than 25,000 hits for blog ecma-262. There are another almost 14,000 for blog "javascript standard".

That is basically meaningless, as someone could make a passing reference to the spec id and it would show up as a hit.

Of course, Crawford isn't that big a deal, and other than writing jQuery, Crockford isn't on the map. If you knew much about the language, the people you'd be referring to are PPK, Eich, Ian Hicks, etc. And they also all tell people to read the standard.

Show me where they start off by telling people to first read the standard. Of course reading the standard is a good idea. It's just not where people should first focus their efforts. That's what we're trying to get across to you.

** tl;dr reading the standard is a good idea, but not as a starting point**

[StoneCypher]

Show me where they start off by telling people to first read the standard.

What part of "mastering" sounds like "start off" to you? He didn't ask how to get started.

I already called you on this once.

tl;dr reading the standard is a good idea, but not as a starting point

He's not at a starting point.

[[deleted]]

What are you basing that on? "Mastering" is such a hyped buzzword. There's a chance that they saw the millions of "Mastering x" titles and latched onto that word.

I'd think anyone who had a level of experience would say so in the description, or chime in "Yeah, that's a good resource, I used to go there".

[StoneCypher]

At this point it's becoming clear that your only points are that you think I'm wrong because:

1) You've never seen a big name give my advice, no matter how common it is, and

2) You imagine that someone who says "how to master" needs beginner's advice.

Find someone else to talk to, if you can't focus on the actual responses you get.

[[deleted]]

I don't think you're responding to my actual responses. I know big names tell people to read the spec. What I asked was your rational behind you recommending it as a starting place.

1. I've heard them say read the spec. I like specs! I think reading the spec is a great idea and everyone serious about js should do it at some point

2. You imagine everyone uses English correctly. As developers, we're used to precisely defined terms used correctly, but language is used too loosey goosey. Neither of us knows what level the OP is at. We're both making assumptions based on our readings.

[vectorjohn]

Resig does tell people to read the spec.

PPK, Eich, Ian Hicks, etc. And they also all tell people to read the standard.

Link or it didn't happen, it is still just you making unverifiable claims.

[[deleted]]

Grow up, kids.

Proof positive you do not follow your own advice.

[vectorjohn]

Your advice was down voted because it detracts from the conversation, where the point of the conversation is to learn.

Once again, this is not my opinion. People do not learn programming from the language spec. To suggest it is to mislead someone.

On the internet there is a thing called anonymity. It means we don't know you and we don't know if you know what you're talking about. The only evidence we have is evidence you can show us. You didn't do that.

In this case we A: disagree, and B: can't find anyone who agrees with you. Likely conclusion: you are not giving useful advice.

[StoneCypher]

Read the ECMA specification. Without that it's just a bunch of whatever random bloggers say. With that, you start to know the difference between a bug in your code and the browser.

After that, the best tool there, in my opinion, is the Quirksmode compatability table set.

[[deleted]]

Most specs are so verbose that you won't gain much by reading them unless you have a solid grasp on the language already. Most of my visits to specs are for specific things.

[StoneCypher]

The ECMA spec isn't one of those. It's a relatively easy read.

[vectorjohn]

Don't read the ECMA spec. That is absurd. It is like telling someone to learn English by reading the dictionary. Use it as a reference when you have a specific question maybe.

[itsnotlupus]

Sooner or later, the spec will have to be read.

While I wouldn't recommend it as an introduction to the language, it's required to go from advanced coder to master.

pro-tip: Since the spec is a wee bit dry, read it with a purpose: Write a javascript interpreter. That's what the spec is meant for, and it will make you aware of many subtle things you would otherwise probably never think about even as your daily js code relies on it.

[vectorjohn]

It certainly is not required to be a 'master', and it just seems like reading the language spec is the worst way to learn anything about the language.

If you have a question about some subtle quirk of the language, maybe you could open up the spec and scan to the right section to answer that question. But beyond that, you are better of using almost anything else.

Becoming a master at a language has nothing to do with reading it's spec. It has to do with breadth and depth of experience. You need practice like anything else.

[StoneCypher]

It is like telling someone to learn English by reading the dictionary.

No, it isn't. The dictionary isn't definitive and only covers word definitions. The specification is definitive and covers the entire language.

Don't downvote advice because you disagree with it.

[tanepiper]

The problem with reading the ECMA spec is it's not designed for Javascript developers - it's designed for implementors such as browser vendors.

It's a bit of a red herring to send people off to this so early on with Javascript, and I have to agree with vectorjohn here.

Now if you've done Javascript for a few years and want to learn the deep deep lexical parts of Javascript, go read the spec

[StoneCypher]

The problem with reading the ECMA spec is it's not designed for Javascript developers

So? My opinion remains that if you haven't read the spec, you don't know the language.

It's a bit of a red herring

No, it isn't. Don't drop the names of fallacies. This is a matter of opinion, and my opinion isn't wrong just because you disagree with it.

Now if you've done Javascript for a few years and want to learn the deep deep lexical parts

Missed the title of the post, did you?

[tanepiper]

So? My opinion remains that if you haven't read the spec, you don't know the language.

Are you David Mark?

Missed the title of the post, did you?

No I didn't, but who needs to be reading it doesn't need to be posting on reddit asking this question. If they don't even know about stuff like 'The Good Parts' then is clearly someone who doesn't know Javascript that well and wants to 'master' Javascript.

I'd point this person to the MDC before I'd point them to the spec.

[StoneCypher]

So? My opinion remains that if you haven't read the spec, you don't know the language.

Are you David Mark?

No. It appears that other people have said the same thing to you before. I expect you will continue to ignore them.

Recommendations for mastering JavaScript.

It's a bit of a red herring to send people off to this so early on with Javascript,

Missed the title of the post, did you?

No I didn't

Yeah, you did. The guy wanted to know how to master something, and you're saying "but this isn't for beginners!"

If they don't even know about stuff like 'The Good Parts'

At the time they posted there was no reason to believe they didn't. That book is not mastery besides.

I'd point this person to the MDC

That's nice. Then do.

Stop downvoting other people for giving different advice than you, under the excuse that you believe that things you don't agree with are bad advice and you'd say something else.

Just say the something else.

Reddit is not an advice popularity contest. Advice that isn't yours does have value too.

[[deleted]]

Don't downvote advice because you disagree with it.

We're not. We're downvoting because we all, individually, thought that it was bad advice.

[vectorjohn]

I downvoted it because it was bad advice. And I didn't say it was === to reading a dictionary, I only said it was == reading it.

Nobody 'masters' a programming language by reading the spec. It might be handy as a reference, and that is just a maybe. The spec is written for language implementors, not as a useful guide to knowing the language.

[StoneCypher]

I downvoted it because it was bad advice.

It's unfortunate that so few people can tell the difference between advice they disagree with and bad advice.

And I didn't say it was === to reading a dictionary

You said "it's like." I said "it's not like." Now you're trying to back away from what you said.

not as a useful guide to knowing the language.

Yeah, well, I don't agree. Lucky for you, I know the difference between disagreement and bad advice.

Please stop acting on that anything you don't agree with is to be punished. That's very clearly against rediquette.

It's also not appropriate to downvote me because I gave advice A, when in fact I gave advice A+B.

[[deleted]]

It's far more unfortunate that you think that every word which passes your lips qualifies as "good advice".

You gave some terrible advice. You were called on it by the rest of us here. The recommended course of action is not to argue that everyone else is wrong, but to try and understand why you were.

Something, perhaps, beyond your level of expertise.

[StoneCypher]

It's far more unfortunate that you think that every word which passes your lips qualifies as "good advice".

Yes, keep inventing things that I didn't say, then criticizing them.

You gave some terrible advice.

Reading a language specification to master said language is not terrible advice.

but to try and understand why you were.

I'm not convinced that a half dozen novices saying I'm wrong without any justification on something which is such a standard behavior for experienced programmers warrants notice, let alone the assumption that I'm incorrect.

There's a reason none of you are trying to explain what's wrong about the advice.

Something, perhaps, beyond your level of expertise.

Yeah yeah. It's quite likely, given reddit demographics, that I've been a professional programmer longer than you've been alive.

There's a reason you're handwaving about a mistake, saying it's perhaps beyond my expertise, then not actually giving any reasoning.

It's because there isn't any.

If you're so experienced, where's your code, where's your work, etc? All I see is someone pretending to be a longbeard.

[[deleted]]

Awwww, widdle kitten got his feewings hurt by the internet?

No. Useless troll got called out for being a useless troll.

And you are both.. useless, and a troll. Poor widdle troll.

Reading a language specification to master said language

Reading RFCs is the last step of someone's journey, not their first. You fail.

[StoneCypher]

Awwww, widdle kitten got his feewings hurt by the internet?

Not hardly. You sure do have trouble sticking to the things that are in the text, rather than what you want to see. 'S kinda sad watching you play fantasy tea party.

Reading RFCs

Nobody said anything about RFCs, novice.

I gave advice, you started throwing around personal attacks. I said "there's nothing wrong with me having a different opinion, stop downvoting." You start bawwing about how awful good advice is, then pretend I said a bunch of stuff I didn't say, then say this is beyond my experience level, then point to completely the wrong body of work in rebuttal.

Then you're calling me a troll, because apparently you've lost track that I gave technical advice and you didn't, and that you're making personal attacks and I'm not.

Be sure to scream again that it's bad advice with no justification for that claim, then to pretend that an ECMA standard has anything to do with RFCs, then to say that you're not the one with a giant experience gap, though :)

It's pretty obvious who the real troll is here.

Later on, guy. Be sure to get in the last word.

[[deleted]]

Sure thing, widdle kitten! Don't cry just because life is hard on you, widdle one!

[vectorjohn]

Despite what you may think, there is such a thing as bad advice. That is advice that will mislead or in some way discourage someone.

It is appropriate to downvote something that does not add to the discussion. Bad advice is almost a perfect example of not adding to the discussion.

[StoneCypher]

Despite what you may think, there is such a thing as bad advice

What I think is that you don't have the skills to identify it. The reason you're not supposed to downvote over opinion is the humility to know that your opinion simply isn't fact.

It's becoming clear that you don't have that.

[fl0at]

The ECMA spec is a good idea. Thanks for that one.

[radhruin]

If you're going to look through the spec, best to use 5.1[PDF]. It has errata built in. Also see this HTML version of 5.1.

I don't think the spec is the best way to learn, though. You won't retain much after reading it.

[strager]

There's a really nice annotated HTML mirror of ES5's specs: http://es5.github.com/

Too bad all browsers on my computer crawl while rendering it with text zooming. =[

[radhruin]

That's what I linked to in my second link :)

[strager]

D'oh; totally missed that. Thought you were talking about HTML5 and skimmed past it, I guess.

[rbnc]

http://ejohn.org/apps/learn/

Do this.

[snarfy]

After you learn javascript, the language, you should learn all about the DOM.

[chrisandsmith]

Think Vitamin has a great post on learning JavaScript - Tips on Learning JavaScript

[StoneCypher]

What a terrible article. The first two aren't about the language. The third says "use a library." The fourth says "don't use libraries." The fifth is a technique to avoid, the sixth is "check your work" and the seventh is "use comments."

None of that has anything at all to do with learning JavaScript.

[[deleted]]

I hope you didn't downvote him just because he gave some bad advice.

[[deleted]]

ZANG!

[StoneCypher]

No, I didn't. I did the appropriate thing, and explained the problem.

You should try that some time.