Well, first things first, you must be aware that JavaScript is a bad language, broken in many ways and mostly executed in a random fashion (i.e. almost no platform follows 100% ECMA, and even some ECMA directives are retarded, like ECMA4 didn't force chrome to return object properties in creation order by default, whereas ECMA5 fixes that to the default behavior we've always seen and expected).
In that sense, writing good JavaScript is like writing good PHP or good C++, it's a lot about avoiding the broken features (for both those languages, there are a lot of features one shouldn't use, it's even more true with js).
That means you should only learn from people who recognize how broken js is, and thus of course js: the good parts sounds like the right direction, whereas I think Resig is a religious zealot and shouldn't be listened to (the guy actually thinks broken js as a first language is a good idea).
Lastly, js is broken in many ways, don't use it when you don't have to, that means avoid node.js and use a good server side language instead.
tl;dr
js sucks, don't listen to people who don't ack that, learn to avoid the sucky parts instead.
And more downvotes from the zealots... HN is so predictable these days.
Dear Troll, I find you use of the word "zealot" to be amusing, ironic and predictable. In addition, during that entire rant you never once mentioned what you thought was a good language.
Now, to add to the real discussion. Aside from all the wonderful suggestions you received so for: once you have read all that you can and broken/learned first hand all you can, and if you are of the pattern persuasion I would look in to the functional language patterns. The Classical patterns, as found in most examples and resources these days, map poorly to JS. At least that is my opinion.
I haven't seen a perfect programming language yet, but the compromises offered by FORTRAN, C, Ada and lisp are really hard to beat, as the first three offer very competitive speed whereas the last one trades off about 50% speed for a lot of built-in metaprogramming.
It's really all about compromises, and JS fits no bill except "easy to learn for noobs", which imho is a non-issue for anyone considering long-term use.
(in case you didn't know, fortran has awesome arrays and awesome compilers, C has inline ASM and awesome compilers, Ada has increased execution security and lisp is lisp)
JavaScript is harder to learn for noobs, it's just easier to get "hello world" working than other languages. I don't think anyone with a good grasp of JS would ever recommend it to someone as a first language.
Well, this is an Ask HN thread and your answer boils down to "learn to avoid the sucky parts", which is good advice, but instead of further guidance on how to achieve this, the remainder of this post contains nothing but useless rants. (Useless for the OP, that is.)
Look at the top rated posts in the thread, all of them contain a ton of specific advice on avoiding the sucky parts.
Avoid the sucky parts by listening to people who recognize the suck.
And that's exactly why it is an addition to the existing answers, most of which do not focus on that core point, and some of which even advise to read documentation written by people who don't recognize the failures of JavaScript.
Comments
Well, first things first, you must be aware that JavaScript is a bad language, broken in many ways and mostly executed in a random fashion (i.e. almost no platform follows 100% ECMA, and even some ECMA directives are retarded, like ECMA4 didn't force chrome to return object properties in creation order by default, whereas ECMA5 fixes that to the default behavior we've always seen and expected).
In that sense, writing good JavaScript is like writing good PHP or good C++, it's a lot about avoiding the broken features (for both those languages, there are a lot of features one shouldn't use, it's even more true with js).
That means you should only learn from people who recognize how broken js is, and thus of course js: the good parts sounds like the right direction, whereas I think Resig is a religious zealot and shouldn't be listened to (the guy actually thinks broken js as a first language is a good idea).
Lastly, js is broken in many ways, don't use it when you don't have to, that means avoid node.js and use a good server side language instead.
tl;dr js sucks, don't listen to people who don't ack that, learn to avoid the sucky parts instead.
And more downvotes from the zealots... HN is so predictable these days.
Dear Troll, I find you use of the word "zealot" to be amusing, ironic and predictable. In addition, during that entire rant you never once mentioned what you thought was a good language.
Now, to add to the real discussion. Aside from all the wonderful suggestions you received so for: once you have read all that you can and broken/learned first hand all you can, and if you are of the pattern persuasion I would look in to the functional language patterns. The Classical patterns, as found in most examples and resources these days, map poorly to JS. At least that is my opinion.
Amusingly, his post is actually more or less what Crockford says in the opening page or so of JavaScript the Good Parts.
good for you.
I haven't seen a perfect programming language yet, but the compromises offered by FORTRAN, C, Ada and lisp are really hard to beat, as the first three offer very competitive speed whereas the last one trades off about 50% speed for a lot of built-in metaprogramming.
It's really all about compromises, and JS fits no bill except "easy to learn for noobs", which imho is a non-issue for anyone considering long-term use.
(in case you didn't know, fortran has awesome arrays and awesome compilers, C has inline ASM and awesome compilers, Ada has increased execution security and lisp is lisp)
JavaScript is harder to learn for noobs, it's just easier to get "hello world" working than other languages. I don't think anyone with a good grasp of JS would ever recommend it to someone as a first language.
Well, this is an Ask HN thread and your answer boils down to "learn to avoid the sucky parts", which is good advice, but instead of further guidance on how to achieve this, the remainder of this post contains nothing but useless rants. (Useless for the OP, that is.)
Look at the top rated posts in the thread, all of them contain a ton of specific advice on avoiding the sucky parts.
Actually my advice boils down to :
Avoid the sucky parts by listening to people who recognize the suck.
And that's exactly why it is an addition to the existing answers, most of which do not focus on that core point, and some of which even advise to read documentation written by people who don't recognize the failures of JavaScript.