
How to Become a Great JavaScript Developer - ludwigvan
http://blog.ustunozgur.com/javascript/programming/books/videos/2015/06/17/how_to_be_a_great_javascript_software_developer.html
======
smlacy
No. Not this. Net even close to this. Let me illustrate:

How to become great at Sports: \- Read books about sports. \- Watch other
people play sports. \- Read in-depth analysis of past sports games.

How to become great at Playing Violin: \- Read books about playing violin. \-
Real sheet music by the great masters. \- Listen to many concerts.

It's inherently obvious that the above approaches are totally and completely
wrong. How do you become good at anything? You practice it. You do it. You
have a coach or teacher or mentor who can give you pointers, but lets you make
mistakes. You have someone who lets you get things wrong the first time, so
that you can see the consequences.

There is a time and place for theory, for reading, for analysis, and this is
too part of the learning process, but this is not at all the most important
tool for becoming great at something.

Theory, analysis, critique, history, and context all matter when learning any
skill, but first, you must build the fundamentals. First, you must do the
thing and once you reach a level where you really understand the thing, then
and only then can you begin the more introspective task of theory and
analysis. Even without these steps, the best way of becoming great is to DO.

~~~
o_____________o
Knowledge work is different.

How to become great at Chess: - Read books about chess. - Watch other people
play chess. - Read in-depth analysis of past chess games.

How to become great at Math: - Read books about math. - Watch other people
perform math. - Read in-depth analysis of math.

You also skipped a key assertion from the author: "Do exercises and try to
explain common JavaScript concepts such as inheritance in your own words."

But you're right, nothing beats digging in and creating something.

~~~
lacker
I don't think that's actually the best way to be great at chess, or math.

On chess, from a GM: "The key to their success is that they kept playing a
lot, and learning from stronger opponents. Don't get me wrong: I am not
suggesting stone age technologies in studying. Of course, you should take
advantage of the best modern learning methods. However, the most important
component of success (at least at weak GM and below level) is practice."

[http://www.chess.com/article/view/getting-better-in-chess-
cr...](http://www.chess.com/article/view/getting-better-in-chess-critical-
mistake-to-avoid)

Math is similar. You really have to do math. Reading books and watching other
people do math is not the critical part.

~~~
novaleaf
a lot of people out there don't have access to mentors, so I (unfortunately)
feel that the self-learning by books approach is still the most practical,
generally speaking.

~~~
moron4hire
This is a pattern of behavior I see in people, that they think they need a
"mentor" to get good at anything. I've even had people explicitly ask me to be
their mentor. Like, people here, on HN, reading my comments, contacting me
through my email address in my profile, asking me to be their mentor.

Frankly, now that I'm experienced, if someone were to agree to be my mentor
when I was a beginner, I should have been suspect of their expertise, because
I don't know anyone who is actually any good at what they do who has time to
do anything called mentoring.

Where does this idea of mentorship come from? I have never seen it. I've had
examples in my life of people to look up to, but when people talk about
mentorship they seem to be talking about some sort of creepazilla relationship
where the student sits at the feet of the master and receives wisdom. Yeah,
no, that doesn't exist in the real world, at least not for the vast majority
of people.

If that's what it takes to be successful, to be reallly good at anything, then
buddy, we're all in a world of hurt. It's an appealing idea, but who the hell
does it ever actually happen to? I'm convinced it's a fantasy.

~~~
mathgladiator
Strictly speaking, you don't _need_ a mentor to get good at anything. However,
it can really help in the areas that are defined more by people than by things
working or not.

As a mentor, I have found that is mostly about reviewing others work and
thinking and giving feedback. For instance, you don't really need a mentor to
get better at solving problems. You may need a mentor to help you communicate
details about the solution.

Somewhat related:
[http://jeffrey.io/writings/apprentice.html](http://jeffrey.io/writings/apprentice.html)

------
fridek
The best thing that happened to me as a JavaScript developer was being exposed
to other languages. Especially the not-so-fancy Java and C++, really opened my
mind about structuring code and planning for a long-term project.

Knowing JavaScript and JavaScript frameworks is surprisingly useless for the
type of work JS devs usually handle. The documentation often consists of
TodoMVC type of examples and approaches. Hardly anyone explains how patterns
like DDD, SOLID, advanced REST, etc. fit into this. The highly appraised Flux
is in reality just a pub/sub system like many on backend (and still it's a
huge step forward - it admits JS systems are large and complex).

I'm just looking at a system design graph, preparing for a new job. There are
about 30 nodes representing multiple services, databases, load balancers and
processes on the backend. There are two for frontend - one says "JS" and the
other "JSON". This is how most people think about frontend and to be a great
JavaScript developer just don't be one of them.

~~~
jakub_g
I agree a lot with it. I also think it's useful to work with at least one
statically-typed language (like Java for example) because it teaches some good
maintainability practices. In JS world, I've seen far too often creating
objects in random places, as a map of parameters, passing them around, and
injecting new keys to the object in other random places, and when such an
object goes around too much and is augmented randomly in a myriad of ways,
it's really hard to reason about it.

In Java, you'd typically create a separate class for such an object, create
fields, assign types to them and document them, and have a constructor which
populates the fields with sensible defaults if not provided. Sometimes it's an
overkill to do it this way, but often it pays off with a better understanding
of the data model. In JS you have a lot of freedom, but too much freedom leads
often to a mess when enough people are working on the code.

~~~
Roboprog
I enjoy the freedom to use a map/object/parameter object as named parameters,
speaking as somebody who has suffered through much Java ceremony.

That said, JSDoc helps a lot: make a @typedef comment for parameter objects at
the top of a file, then use the type in the @param annotations of the relevant
functions. Makes understanding the JS code in an IDE much easer, as well as
having something worth generating HTML documentation from.

------
darby2000
Just adding my two cents. Wanna be a good JS dev? Go play around with a lisp.
Like Clojure for a month or two. Get comfortable with functional programming.
Then come back to JS. So many people come from a OOP to JS and they have a bad
time with it. JS is more like a lisp with C syntax than it is a traditional OO
language. Learning Clojure, not only improved my JS abilities, but just my
over all programming maturity. IMO. Additionally, I agree with the author
about reading books, and libraries. It's always good advice for any language.

~~~
dlau1
Agree so much with this comment.

Downside is that after using a proper functional language (clojure[script])
you end up wanting some really basic things such as immutable core data
structures.

I feel like if you start from scratch on a javascript project, it's possible
to program in a functional manner. I've found it really tough to introduce
functional concepts to an already full stack javascript codebase.

BTW: I'd recommend ramda [1] for those interested in functional javascript
programming. The auto-currying makes it way more powerful than
underscore/lodash in terms of encouraging pure reusable functions.

[1]: [https://github.com/ramda/ramda](https://github.com/ramda/ramda)

~~~
jdd
There's a flavor of lodash with auto-curried iteratee-first data-last methods
too. See lodash-fp – [https://www.npmjs.com/package/lodash-
fp](https://www.npmjs.com/package/lodash-fp)

------
mhd
If you're already a decent enough developer and just need to get your grips on
JavaScript, I'd say that most books listed aren't that useful. A decent enough
online reference will get you going and after that you'll have to consider
that JS is a pretty large dung heap by now where you probably won't get a lot
of mileage out of inhaling dust from the crusty parts. Unless you're an
enterprise developer tasked with maintaining your company's Dojo application.

If you're a new developer coming into JS from a more _tabula rasa_ situation
(possibly these days), I'd still say that most of those books are wasted, and
you'd probably get a better mileage out ouf SICP or the GoF book than most
Ninja/21days/Dummies tomes.

The core of JS is small enough, and the rest is _highly_ dependent on your
task, scope and framework. No jQuery book will help you with your intranet
extjs app or your state of the art fluxified React SPA. You'll have to wade
through code to get there, preferably as much of your own as possible.

And the most important thing: Pick something and stick with it. No mid-project
framework/build tool/library changes. Even "obsolete" tech still works better
than falling into the Duke Nukem hole. So don't get nervous about still using
"grunt" when all the cool kids are using "gapoodle".

~~~
wlesieutre
For the decent developers picking up Javascript,
[http://learnxinyminutes.com/docs/javascript/](http://learnxinyminutes.com/docs/javascript/)
is hard to beat. All the basic syntax and language features in one page
without trying to explain to you what a while loop does.

~~~
a3n
This made me gag, years ago:

    
    
      // Statements can be terminated by ;
      doStuff();
      
      // ... but they don't have to be, as semicolons are automatically inserted
      // wherever there's a newline, except in certain cases.
      doStuff()
      
      // Because those cases can cause unexpected results, we'll keep on using
      // semicolons in this guide.

~~~
wlesieutre
I haven't gotten much into Javascript yet, but is there any reason I would
_not_ terminate with semicolons? Without understanding which "certain cases"
won't have them inserted automatically, relying on that feels like asking for
trouble.

~~~
a3n
My understanding is that the original decision was to make life easier for the
programmer: if you forget, we'll put one in there for you. Myself, I'd rather
be told that I made a mistake, then have it ignored, because how does the
compiler know what I really wanted?

Here's a good one: [http://stackoverflow.com/questions/18986144/javascript-
compi...](http://stackoverflow.com/questions/18986144/javascript-compile-
error)

Instead of being told there's some problem with the code, it inserts a semi-
colon into an arguably ludicrous location, and then gives you a _differen_
error.

Would probably make compiler writers' jobs easier if they just spit out
errors.

~~~
ricardobeat
The _actual_ reason that third function compiles, and the fourth does not, is
that

    
    
        {
          x: 0
        }
    

is a _block statement_ with a _label_ x. Try it in your console, it returns 0.
The last one is an object literal outside an expression, which is a syntax
error.

In addition to that, the return statement is 'restricted production' where the
line break itself is a terminator, this has nothing to do with semi-colons or
ASI.

------
murbard2
Missing advice: learn to program well in a few well designed programming
language. JavaScript was designed in 10 days and the main reason it still
exists today is incredibly strong path dependence. There's nothing wrong with
wanting to become a great JavaScript developer, but one needs to become a
great developer first, and JavaScript just isn't conducive to that.

~~~
91bananas
I personally am so over this argument. Sure, that is roughly a fact about the
time in which it was designed... but that was 20 years ago. Since then there
has been a team of some of the best programmers in the world maintaining and
advancing the language.

~~~
murbard2
That's irrelevant; advancing the language isn't an exercise in programming
language design, it's an exercise in getting everyone to support the extension
and in avoiding breaking legacy code. It has almost nothing to do with the
maintainer's talent as programmers or PL experts.

If you doubt this argument, consider the fact that the horrible scoping, the
weak typing, the insane casting rules are still here to this day; empirically
you're wrong.

~~~
aaron-lebo
Well, a lot of the little issues are being slowly fixed (see let and scoping
in ES6). This goes back to the point of the person you are responding to.

This is a thought more than a full-fledged argument, but perhaps little issues
with the language actually can and do make people better developers when they
are aware of them. My friend started driving a scooter. Dallas isn't
particularly conducive to that. My friend says he has since become a better
driver because he knows one little screw up by him or someone else can end his
life. Similarly, you'd better be aware of weak typing and casting and code
accordingly or you might get hurt. Of course, you shouldn't have to...but that
doesn't make people worse developers.

But the truth is, JS has a lot of features which make it great for becoming a
good developer. It's less class-based than Ruby and has better lambdas than
Python which I would argue make it better for functional programming than
either.

~~~
murbard2
Yes, "let" will finally fix the horrible scoping - 20 years after the creation
of JavaScript. In the meantime you'll still be stuck using lovely constructs
like === and !==

And yes, JS support for lambda expression is surprisingly nice, but that is
basically the only nice surprise.

------
sailfast
This is a good collection of resources that I have found are very educational
and useful. That said, for me personally it was extremely important to dig
into some problems concretely rather than by reading. "OK I've read about how
I should do this in the ideal - now go actually set up an Angular app with a
full test suite pointing at a REST API." Or perhaps - "I've got a great idea
for some code art - let's try it out."

Without the follow-through I found that I could keep up in a conversation but
still had doubts and issues when it came to implementation. Doing it in anger,
delivering a product, as many times as possible helps a good deal in moving
toward greatness.

------
alkonaut
I'd like to know how to learn to "accept" JS, coming from other languages.

No really.

How do I become a JS developer that doesn't whine all day long about all the
little idiosyncracies of the language, or the tediousness of writing tests for
things my compiler should work out? Obviously people enjoy writing JavaScript,
and at least some fraction of these have to have been the kind of person that
whined about the type systems in Java or C# _being too weak_.

If you were one of those developers, how did you let that go (did you?) when
becoming a javascript developer?

~~~
mattdesl
It took me a while. My background was Java, Python, ActionScript and a few
other languages sprinkled in. After about a year working JS, its now my
preferred dev environment.

The turning points for me:

\- modularity - npm has really changed the way I program, for the better

\- Node.js tooling (including a Browserify, Babel, Webpack) will greatly
improve your experience with the language

\- live reloading, zero compile time, instant visual feedback

\- the breadth of Browser/Node/npm APIs can make it a ridiculously productive
language to work in

\- IDE plugins and linters can catch a lot of errors as you type

\- above all else; it has an amazing community of enthusiastic developers,
tinkerers, scientists, artists, etc.

------
moron4hire
Books are a waste of time. Most of them are garbage to begin with, and most of
them are practically obsolete by the time they are published. Few have any
lasting staying power.

Besides, nobody ordained the author to be an authority on the subject. He was
just a guy who wrote a book. It's zero indication of the quality of the
content.

Just write code. Practice, practice, practice.

~~~
jackweirdy
You say "Books are a waste of time" but all your explanation says is "Books
can be bad". That's not the same thing.

~~~
moron4hire
:|

Because there is no objective way to evaluate the quality of a book before
reading it, and because any useful information in most of the few good
technical books is of limited lifespan, books are a waste of time. It's not
just that books _can_ be bad. It's that _most_ books are bad, and having to
wade through them is what makes them a waste of time.

~~~
mightybyte
So don't wade through random books. Get recommendations from other people and
read only the ones that are highly recommended.

Here are a few books that I see at the top of the lists almost every time this
topic comes up:

The Mythical Man-Month

The Pragmatic Programmer: From Journeyman to Master

Code Complete

------
donatj
I 100% indorse "read libraries". There really is a lot of wisdom buried in
them. I read through MooTools back in the day and I would go as far as to call
the experience formative. Read frameworks you don't like and consider WHY they
work like they do.

------
danbruc
Become great in language X seems the wrong goal to me. An enormous amount of
things and at the same time the most important things that make you a great
software developer are completely language agnostic. And I would argue they
are harder to learn through the lens of a single language and software stack.
You then still have to become a productive software developer knowing your
libraries and tools and their quirks but this seems secondary to me and easily
compensated by your favorite search engine. Or by example - knowing when to
use a set as opposed to a list is more important than knowing in which
namespace you can find the implementations for language X.

------
rrss1122
What prompted me to develop as a JavaScript developer was being put in charge
of a major project that was mostly JS code. Up till then, I had done some JS
work, using jQuery to add animations and interactions to a UI and some ajax.
Doing this JS project exposed me to pretty much everything you can do with JS,
and I learned it all pretty quickly so I could start contributing to the
project.

I only got this project too because the dev previously in charge of the
project left the company and I asked about it. It's another lesson to new
developers: never let an opportunity pass you by.

------
srpablo
Tastes in books varies wildly between developers: there are many on there that
I wouldn't say helped me as much as others, but to each their own!

With that in mind, I'd put a plug in for David Herman's _Effective
JavaScript_. It goes beyond simply stating the mechanics of JavaScript into
what pitfalls can be had, and uncommon but critical factors to consider when
writing your code. The point about UTF-16 code points in strings alone makes
it a valuable resource.

    
    
       [1]: http://effectivejs.com/

~~~
davidjnelson
Best JavaScript book I've read. Advanced topics!

------
javabank
They straight up stole the Aphex Twin logo:
[https://twitter.com/ustunozgur](https://twitter.com/ustunozgur)

------
humbleMouse
I think it totally depends on the problem domain you are working with. There
are so many different ways to use javascript it is overwhelming. There are
also lots of ways to structure it. I feel like a very good understanding of a
widely used OOP language such as Java is a good place to start before jumping
into the wild west of javascript programming.

------
kriro
I think that setting up a test environment is one of the bigger hurdles (it
seemd more confusing for JS than for most other languages I used before).
Starting with installing node and "node myfile.js" is pretty good to get going
(writing hellow world, fizzbuzz etc.). I struggled quite a bit sifting through
all the options after that (e.g. npm+Grunt+Browserify to be able to require
stuff etc.). Maybe I'm imagining things but the simple "getting started" was
quite complex for JS. Or in other words...the first steps are pretty hard imo.

The inclusion of Backbone seems a bit odd. Isn't that also frontend-ish (like
the pick one of Ember,React,Angular). I'd rather substitute it for Express.

------
stared
Maybe it's person-dependent, but I've learn most JS from MDN
([https://developer.mozilla.org/en-
US/docs/Web/JavaScript](https://developer.mozilla.org/en-
US/docs/Web/JavaScript)) _and_ collaborating with others (plus a lot of blog
posts, code snippents, and in general: reading code by good developers (side
note: it's why I hate minification - I habitually read code on webpages)).

For books the main problem is that they are getting obsolete quickly (JS is a
rapidly-changing technology) and, except for very basics, somewhat opinionated
and task-dependent.

------
z3t4
To be good at something, you do not need to know things outside of the area.
It might however be helpful if you need to go "outside the box". But to be an
expert at the things in the box, you only have to know about the box ...

That said, before I started with Node.JS and understood it's "patterns"
JavaScript was just some evil necessary to get things to work. But after
learning the module patterns of Node.JS, JavaScript started to get fun!! And
the more ppl that understands "modules", the more fun it gets! So go learn
about modules and even try making your own!

I guess Node.JS is now part of the JavaScript box.

------
beat
"A human being should be able to change a diaper, plan an invasion, butcher a
hog, conn a ship, design a building, write a sonnet, balance accounts, build a
wall, set a bone, comfort the dying, take orders, give orders, cooperate, act
alone, solve equations, analyze a new problem, pitch manure, program a
computer, cook a tasty meal, fight efficiently, die gallantly. Specialization
is for insects." — Robert Heinlein, Time Enough for Love

I have a hard time thinking of "web programmer" as "polymath" and worrying
that it's not specialized enough.

------
petercooper
Fancy linking up [http://javascriptweekly.com/](http://javascriptweekly.com/)
where it's mentioned? :-) Not everyone knows where it is. Thanks!

~~~
ludwigvan
Just did. Thanks for the weekly btw :)

~~~
petercooper
No worries, thanks! We'll hopefully be linking this up on Friday too!

------
adam12
I think he/she should have suggested that you actually work on some javascript
projects that you are passionate about.

Also, it seems like a big jump to go from doing exercises to giving lectures.

------
landmark2
tl;dr - to become a great javascript developer...learn javascript

------
pixel67
I just want to point out that 'JavaScript the Good Parts' is not a good first
book for beginners. David Flanagan's book is a much better book to start off
with or Zakas book `Professional JavaScript for Web Developers` is the one I
would suggest, then Crockford's book. Nothing trumps practice though,just keep
coding and breaking things just to fix them, that, imo is the way to learn
anything.

------
serve_yay
I don't think there's any other way than working with talented people. It
shows you what they're better at than you are, and (maybe) what you're better
at than they are. I did all this stuff and I thought I was pretty hot shit,
until I joined the team I'm on now.

You have to find out what you don't know that you don't know, and it's really
hard to do that on your own.

------
ahallock
> Reading and understanding underscore will improve your functional
> programming skills.

No. underscore does it wrong (check
[https://www.youtube.com/watch?v=m3svKOdZijA](https://www.youtube.com/watch?v=m3svKOdZijA))
Check some of the real functional libs like Ramda and Pointfree Fantasy

------
Roboprog
I mentioned this elsewhere, but I thought it would make a nice "top level"
comment: Learn to use (and use) JSDoc in your JS code. Having comments that
generate a standardized index of your code, as well as being used by an IDE,
greatly helps the comprehension of the code when you come back to it a day or
two later.

------
rilita
tldr: ( my own, not the authors in the article itself )

\- Read books

\- Learn libraries ( author seems to like node.js and recommends libraries
associated with that )

\- Do exercises

\- Learn how classes work in JS ( Note this is amusing to me since JS does not
have classes in the typical sense [ they are implemented via libraries with
prototypes and closures ] )

\- Learn what Es5, Es6, ES7 are ( There are good things here, but be aware
that most of these features are not implemented in most browsers and will
requires shims and/or translators to even function. Be careful as they may
work in your browser but not others. Test! )

\- Read JS blogs and watch JS educational videos

\- Practice

It's an okay article. If you are clueless how to start learning seriously this
should help. Some decent books and websites are mentioned by name.

I think the "every JS developer needs to learn XYZ" is a bit off though. This
is one man's perspective.

~~~
LukeB_UK
_\- Learn how classes work in JS ( Note this is amusing to me since JS does
not have classes and everything about the way they are done is just craziness
compared to a real OO language )_

ES6 brings classes: [https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Classes)

 _\- Learn what Es5, Es6, ES7 are ( good for confusing yourself and writing
code that won 't work cross-browser... )_

Babel means you can write ES6 and ES7 code and make it cross browser:
[https://babeljs.io/](https://babeljs.io/)

~~~
rilita
Are you kidding here? In ES6 classes provide nothing more additional than the
closures already in use via a bit of extra utility code. Doubters should click
the link here provided by Luke. It is filled with "To Be Determined" for all
details of anything useful.

Do you know what classes actually do in a real OO language, or are you just a
fanboy of JS?

Also, using shims or translators proves nothing. I can write in C++ and use
translators to convert that to JS. What is the point here exactly?

Adding extra confusing junk onto a weak language does not make the language
"better", especially when the standards you are recommending people to learn
aren't even finalized.

Where is the Acid test for ES5, ES6, and ES7 features? Hell where is the Acid
test for HTML5?

Oh that's right; all of this is just a pile of nonstandard junk that people
are begging for and isn't really implemented.

~~~
clessg
> In ES6 classes provide nothing more additional than the closures already in
> use via a bit of extra utility code.

ES6 classes are sugar over prototypes, not closures. Insisting that ES6
classes aren't classes requires at the very least a basic understanding of how
they are implemented.

> Do you know what classes actually do in a real OO language

JavaScript is a real OO language. Do you mean class-based?

> are you just a fanboy of JS?

Surprising vitriol here and makes you lose all credibility. Why does stating a
couple of facts imply that you are a fanboy of JS?

> Also, using shims or translators proves nothing. I can write in C++ and use
> translators to convert that to JS. What is the point here exactly?

The point is that you stated that ES6 and ES7 code don't work cross-browser.
Using Babel means that they do.

> Adding extra confusing junk onto a weak language does not make the language
> "better", especially when the standards you are recommending people to learn
> aren't even finalized.

Where exactly did he make this argument?

~~~
rilita
Have you looked at the implementations of classes in jQuery, Prototype,
Mootools, Dojo, etc? I have. I've used thousands of lines of codes from these
libraries and fixed numerous bugs in them. ( Note I'm referring to the 'bind'
function specifically in the case of jQuery as it doesn't even provide an
equivalent to Class.create(). That said, John Resig himself wrote an article
about this and ported out the core of Prototype [ same as I have done ]
[http://ejohn.org/blog/simple-javascript-
inheritance/](http://ejohn.org/blog/simple-javascript-inheritance/) )

Using the prototype may be the way that things get copied from the base
definition to an instance, but generally closures are what allow things to
have the proper scope. Arguably the scope is far more important for using
something like a class than the copying. Additionally, without closures there
is no way to pass of anonymous function pointers calling back into the class.

If you think you are demonstrating that I have a lack of knowledge of how this
shit works, you are mistaken. But by all means, continue disregarding my
points and nitpicking details instead.

You will note that here on hacker news I don't really give a shit about my
credibility; I care about providing the most accurate information I can to the
benefit of others.

You haven't invalidated my statement about translators at all. ES5, ES6, etc
are not cross-browser compatible. Using a translator to "make it work" doesn't
count. If you wish to say that C++ is cross browser compatible too then fine,
but it is obscuring the root issue that those features do not exist in all the
browsers, nor even the whole set of them in any one browser. This is
misinformation and will mislead developers.

My last paragraph is in reference to the fact that JS/Ecmascript have never
truly been "fixed". It is just a constant hodgepodge of whatever vendors
decides to add on to the language.

~~~
clessg
> Have you looked at the implementations of classes in jQuery, Prototype,
> Mootools, Dojo, etc?

Yes, and jQuery doesn't implement classes.

> I care about providing the most accurate information I can to the benefit of
> others.

By calling other people fanboys after they provided a link?

> ES5, ES6, etc are not cross-browser compatible.

I guess it depends on your definition of cross-browser compatible, but ES5 is
what, 5 years old now? I guess it doesn't work on IE8, but by that definition
ES3 isn't cross-browser compatible because it doesn't work on IE1.

As for ES6, it's cross-browser compatible in the same way that CoffeeScript
is, with the added benefit that it'll work natively in most browsers in a few
years.

> My last paragraph is in reference to the fact that JS/Ecmascript have never
> truly been "fixed". It is just a constant hodgepodge of whatever vendors
> decides to add on to the language.

That's really not the case anymore.

~~~
rilita
jQuery provides bind. That and related code is what I am referring to in that
case, hence my insistence on the importance of closures. I have revised my
comment to mention this as well as the fact the John Resig himself reccomends
the Prototype way of doing Class.create(). By the way, Class.create() itself
is implemented as a closure.

Are you claiming that CoffeeScript is cross browser compatible? If so you are
just going further down the rabbit hole. To my knowledge there is not a single
browser than itself is capable of parsing CoffeeScript without a helper
library that doesn't come installed by default. ( Firebug comes to mind, and
if I recall correctly there is a helper tool for that. I'm also aware of
source mapping for debugging things such as JS in both Firebug and Chrome )

------
sjcrank
In addition to these great points, I find it extremely helpful to spend some
time reviewing the source of various open source JS frameworks.

You can learn so much from patterns and techniques others are using, but that
may have not been documented in the other listed resources.

------
synthmeat
I definitely do not consider myself great JavaScript developer. Not even
mediocre. Code by some people that now do JavaScript lectures, I've refactored
and made at least order of magnitude faster, so there's that.

There's one important thing I've already learned though and I'll do you a
solid - _be a total nazi to your code_.[1]

At the start, it's easy to get impression that it's all loosey-goosey-
everything-works kinda thing, and it actually is... _at small scale!_ When you
get to medium-sized thing, all hell starts to break loose, and I'm not talking
just callback hell. You can avoid all that with modest amount of discipline.

I'm aware many people have qualms with JSLint, some even with JSHint. But it
doesn't matter what you use as long as you keep consistency. Those two tools
help you with that. If you can be disciplined without it, sure, go for it.
Just reading on possible configuration options for JSHint already made me
consider many potential pitfalls I wouldn't have even thought of otherwise..

As far as learning goes, I'm definitely recommending learning as-you-go. To
hell with academics - this is JavaScript, language made in few weeks[2]. You
can develop amazingly accurate feel for the language in spite of not knowing
rigorous abstracts. You're not sure what _new_ actually does, and you're on
deadline? Make a note - "figure out _new_ " \- and move along. When you manage
to scrounge few hours of your busy week, run through those questions of yours
across plethora of amazing resources online, head over to #Node.js or
##javascript on freenode, ask and ye shall receive.

In JavaScript, there's about a million ways one can make something work, an
immense solution space. Are you sure your attack vector is good enough?
_Refactor aggresively!_

[1] I wanted to go with "anal" instead of "nazi". But you get the idea.

[2] ...by some amazing dude though.

------
scelerat
My breakthrough moment with JavaScript was reading Mark Jason Dominus'
''Higher Order Perl'', and realizing everything described there could be
applied to JavaScript.

That and just building a lot of things with it.

------
malandrew
Read code. Write code. Repeat.

Once you have developed an eye for good code, find better code to read, write
better code. Repeat.

This is the key. You need to move from "practice makes perfect" to "perfect
practice makes perfect."

------
lgsilver
Force yourself to lint your code. Having clean code is like having good
handwriting, it makes content of your projects easier to understand and
drastically improves how you think about what you're building.

------
HaseebR7
I've never learned JS completely, just dangerous half knowledge from
stackoverflow answers or blogs.

Should I jump into ES6 directly or learn ES5 and learn ES6 when it is
implemented across all browsers ?

~~~
jhildings
If you been doing a lot of JS for web stuff, and used SO etc to check things
but don't have a thorough understanding of the language I would recommend the
book "JavaScript the good parts"

~~~
edwinnathaniel
JavaScript the Good Parts shouldn't be the recommended book anymore (and I
think even Crockford himself said something along that line in one of his
newer videos, couldn't find it though... it's been a while)

~~~
jhildings
Why not? I found it more useful than Eloquent Javascript at least

------
fapjacks
This is awful and wrong. _Always Be Coding._ That's how you become a great JS
developer. Or great anything. Practice makes perfect. It's said for a reason.

------
interdrift
The 'great' developer has nothing to do with this description. It's not only
about knowing/learning stuff,it's about coming up with smart stuff.

------
gauravgupta
I personally like to follow the best (and frequently updated) tutorials on
crowdsourced tutorial websites like Hackr.io for example. Just my 2 cents.

------
clavalle
This is all solid advice.

Is there a 'Genius' (nee 'Rap.Genius') type resource that annotates well known
open source code?

~~~
kilian
Yes, Genius: [http://genius.it/5088474/ejohn.org/files/jquery-
original.htm...](http://genius.it/5088474/ejohn.org/files/jquery-
original.html)

~~~
gluelogic
Thanks for this link. I will be reading it for sure. I also stumbled on the
annotated source of Underscore.js a few days ago
([http://underscorejs.org/docs/underscore.html](http://underscorejs.org/docs/underscore.html)).
Would love any more stuff like this that anyone knows of.

~~~
anc84
Why oh why are those not comments within the source file? It would help me so
much to have comments like those in software...

Generally I think that a linear step-by-step description is often not the best
way though, often you would have to explain concepts or the bigger picture
first.

~~~
jashkenas
You're in luck. Those comments _certainly are_ within the source file:

[http://underscorejs.org/underscore.js](http://underscorejs.org/underscore.js)

~~~
anc84
That's fantastic! I guess the website was auto-generated then, how nice.

------
dj_doh
Read a book or six top to bottom, mix it with video and blog posts focusing on
concepts that are deemed complex or critical in that subject.

Build general purpose libraries, plugins, micro-framework or personal
projects. Follow-up by validating your work with your community or sample
audience. I have been taking the later route.

When it's done. Read some more and build some more. Put it on a repeat loop.
Look for some variation as it brings different perspectives.

------
kelvin0
Learn Dart :)

~~~
tempodox
As minimalistic as your comment is, I think it points to the single most
important truth about JS: It's practically impossible for human beings to
write “good” JS code. The only hope you have is using a sane language with
sane concepts that can be compiled down to the JavaScript of the week (ES6,
ASM.js, the works...).

I would argue that JS should be handled analogously to Assembler: Good for you
if you understand it, but only highly trained field specialists in protective
suits dare to write production code in it. Go and get a decent compiler if you
can't avoid using that technology.

~~~
moron4hire
... I'll never, for the life of me, understand comparing a high-level
scripting language to almost the lowest of low-level assembly languages, as if
JS doesn't give you abstractions at all.

If you can't write good code in JS, it's because you're a bad programmer.

~~~
mitchi
As a veteran C++ developer, I actually quite enjoy Javascript. Once I
understood that Prototypes are linked lists and that *this is a pointer that
changes according to 2 simple rules, Javascript became quite easy. I mean they
even give you a GUI debugger. It's hard to get stuck for long, even though
it's not not a Visual Studio. Like you said, you have already all the
abstractions you need with this language. You can do complex things and for
me, if I have composition, I'm pretty much already good to go.

~~~
moron4hire
Composition is really the key.

------
isisanchalee
I wish this post was for Ruby! I've already done most of these things for JS
-_-

------
ExpiredLink
Can you become a great developer in a crap language?

~~~
swsieber
Yes. It's possible to draw a straight line with a crooked stick.

~~~
kelvin0
Can I make a t-shirt with your quote? It's awesome!

~~~
swsieber
By all means - it's not actually mine though. It's a derivative of "God can
draw a straight line with a crooked stick." It's generally attributed to
Martin Luther, though I didn't really know until I looked it up just now :)

------
pmalynin
1\. Stop.

2\. Switch to TypeScript

3\. ???

4\. Profit!!!

~~~
M8
WebAssembly will make both irrelevant in a few years.

------
notNow
How many books did this guy plug in his piece? I really lost count at 10 or so
...

