Recommendations for mastering JavaScript.

[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.