"JavaScript: The Good Parts" is a fantastic book, but anyone telling you to read it if you're coming at JavaScript as your first language is doing you a horrible disservice.
It is a fantastic book for learning to avoid being bitten by all of the stupidity in JavaScript if you're used to programming in sane languages, but it isn't a tutorial or "Learn to Program" book by any stretch of the imagination.
To be completely honest, I'm a bit horrified people are learning JavaScript as a first language at all. The language does indeed have its "Good Parts" and it is incredibly useful because of its ubiquity, but I just wonder how many young brains are going be hardwired to think some of the design choices (the way block scoping works/doesn't work, equality, lack of modules, etc, etc) in current JavaScript versions are normal, when in fact they are very unfortunate.
I learned JavaScript first, and I think in many ways I'm actually better off for it.
Anyone who's serious about JS hears constantly about the problems of lexical scoping, type coercion, lack of modules, etc. When I moved on to learning PHP and Python, I largely knew what to expect - and found them both pretty easy (aside from PHP's standard library being ENORMOUS and impossible to memorize).
On the other hand, I've seen people coming from classic OOP languages really struggle with things like first class functions and prototypal inheritance.
I don't think the problem is that people are learning JavaScript as a first language. I think the problem is that a lot of people who write JS don't ever really learn it.
I think that you're misinterpreting disgust as "struggle" when it comes to those people with a more traditional OO background dealing with JavaScript's prototype-based OO approach.
Languages like C++, Java, C#, Objective-C and Smalltalk have very well-defined and consistent ways of declaring classes, inheritance relationships, instantiating objects, using objects, and so forth. With some experience, it becomes extremely trivial to quickly understand and work with such code, even when it was written by other developers far away or long ago.
JavaScript is the opposite. Like so much of the rest of the language, its prototype-based approach is an absolute mess, and this further encourages code that uses this functionality to be a mess, too.
Those are three different ways of doing the same thing (and one of them also has non-obvious resource consumption impacts). Those are a very basic case, as well, without even any inheritance. This lack of consistency may not seem like a big deal when it comes to simple examples like that, but it does quickly become an issue in any code written by more than one or two developers, and meant to be maintained for years. Some will claim that coding standards will help here, but they do absolutely no good once integrating code developed independently of said coding standards.
The numerous problems with JavaScript's approach might be excusable if it brought any benefit relative to more traditional OO approaches, but it just doesn't. It takes something that is done quite sensibly in so many other languages, and ruins it. While somebody who started with JavaScript as his or her first (and often only) language may not see these problems, it is very frustrating and disgusting for those coming to JavaScript after years or decades of experience with other languages.
I disagree with your assessment. Arguably your trying to cram non JavaScript style into JavaScript and then getting upset that it'a not what your used to.
I had a bad opinion of JavaScript at first too coming from a C++ background. Then I finally stopped trying to make it C++. I never want to go back. Things that are hard in statc languages are so easy in JavaScript.
My best advice would be to maybe read though one of the more popular libraries though I don't know which one to recommend. There's a level of elagance there I rarely see in C++
The "classical inheritance background" frustrates the heck out of me at times. I strongly encourage developers to look at traits/roles -- http://en.wikipedia.org/w/index.php?title=Trait_(computer_pr... -- for OO development and the first thing I have to do is to try to get them to "unlearn" class-based inheritance.
For me, the key bit of learning that unlocked my ability to switch between OO paradigms was actually assembly programming.
Having an understanding of how C++ types, strings, structs and finally objects all impacted the stack and memory, then being able to actually create something in x86 let me 'see' how classes create objects, and also got me over the 'how do pointers work?!' hurdle.
It might be entirely counter-intuitive, but learning assembly was the key to me being able to shift OO-gears. Today I write in PHP and JS, and the only thing that I find myself stumble over when moving back-and-forth are weird things like the `this` scope of setTimeout returning to global space when invoked locally.
Interesting. For me, I learned OO with Perl (scary, I know), but really started grokking it when I learned to Java. Finally, I started studying Smalltalk and when I found out that it doesn't have "if" statements (it creates boolean objects you can send ifTrue/ifFalse messages to said objects). Once I grokked that, it was like my eyes opened. I still have more to learn, but OO programming is so much easier and more pleasant after understanding how multiple languages approach it.
Hmm. There was another comment in the chain last night about why Dart doesn't use prototypal inheritance. That's what I was replying to. Must have been deleted and orphaned the comment above.
> I just wonder how many young brains are going be hardwired to think some of the design choices (the way block scoping works/doesn't work, equality, lack of modules, etc, etc) in current JavaScript versions are normal, when in fact they are very unfortunate.
Your concerns echo those of Edsger Dijkstra when he discussed the educational shortcomings of popular PLs in 1975:
True. I think the best characteristic of a programming language is that you can do really cool stuff with it that makes you want to learn to program, and enjoy the results. Javascript has a monopoly on doing cool stuff in a web browser, so for that reason alone it makes it fun to learn.
Heck, thousands of programmers (myself included, come to think of it) got started on programming because of "DHTML" and script kiddy DOM manipulations back in the days of Netscape. It was a gateway language. Fortunately I learned the fundamentals more thoroughly in Scheme...
JavaScript was my first language. I learned allthe basics of programming in it. I quickly got frustrated because I still did not know how to make anything complex. I switched to python and it almost was like easymode. With python I was much more able to learn how to make things. Now I'veswitched back and I hate it. I'm continually forced to go out of my way with js to make things work properly. Thought now at least I can work on html projects that I can share, python on the other hand can't do that.
Agreed, the best advice I can give is to learn core programming concepts (and if possible, computer science concepts) first, in a good language which elucidates them without getting in the way. Lisp is one, Python may be even better, Ruby wouldn't be bad.
Then take on Javascript, since it has some complex ideas and constructs.
Also "the way block scoping works/doesn't work" in JavaScript is weird, but it has closures and first-class functions, which are way cool and sort of make up for it. Coffeescript makes using these easy, thank goodness (these are the kinds of concepts I wouldn't want to deal with when learning how to program for the first time).
There was never the cult-like following of BASIC that we see with JavaScript. While there were people who did prefer BASIC for one reason or another, virtually all of them would readily admit that it was inferior to languages like C (and C++ later on), the various dialects of Pascal, and Fortran for any serious work.
We don't see this when it comes to many JavaScript programmers today, however. A lot of them don't even know any other languages aside from JavaScript. Others refuse to acknowledge its many, many inherent flaws. This in turn leads to them trying to use it for serious work, often with disastrous results. This is especially apparent with node.js and server-side JavaScript development getting more and more hyped.
I'd much rather deal with a BASIC programmer who at least knows and acknowledges the downsides of his preferred language, rather than a JavaScript programmer who either doesn't know or refuses to admit the vastly more serious flaws with his preferred language.
There was a pretty big BASIC cargo cult back in the day.
I didn't even really know what C/C++ were for a fair few years of programming apart from some vague notion that they were used for games because they were faster.
In fact back then you had to pay for C compilers usually, whereas BASIC interpreters were often free with the platform so it was fairly common to have never used anything else.
That became further cemented with Visual Basic it's legions of copy/paste & visual designer oriented developers.
Javascript has a large following not because it's a particularly great language but because it is so ubiquitous. The draw of stuff like node seems to be more to do with code-reuse and having a language that is async-by-default rather than necessarily not knowing anything else.
Javascript's secret weapon[1] -- especially for beginning programmers -- is its dev tools. If you learn JS' debugging toolkit early on, it will accelerate your learning in general. I recommend Code School's "Discover DevTools" course [2] for beginning devs, but I'm not aware of a high-quality introduction for experienced devs.
Shameless plug: I teach at a school for JS devs named Hack Reactor. If rewriting Underscore as a learning tool sounds like fun, you should apply. http://hackreactor.com
Holy shit! I've been programming in JavaScript for years and never heard about the debugger statement. This looks great for really understanding the details of JavaScript's object model.
Also that little stop sign shaped pause button in Chrome will 'Pause on all exceptions' (blue) or 'Pause on all uncaught exceptions' (purple, I usually leave it on this).
Yep! I find it easier to use the debugger statement though when changing code a lot. Also, some places like compiled templates are difficult to set the breakpoint so it's useful there too.
I've been reading up on all of the hacker schools (Dev Bootcamp, App Academy, etc.) and I was really excited to find out about Hack Reactor: I have very minimal programming experience, but have found JavaScript a pleasure to work with.
I look forward to applying to Hack Reactor when it's financially feasible! :)
The Developer Tools feature built into modern browsers (Chrome/Safari/FF/IE8+/probably others). Extremely useful when debugging JS. I know the Chrome one also allows remote debugging of your web site/app on Android.
Just whatever you do, remove the debugger (and console.log) statements before committing/deploying!!! I've seen this too many times and it's not nice when you end up throwing exceptions in older browsers that have no idea what these statements mean.
JavaScript has three main features that commonly trip up people from other languages. If you understand these three things, you'll be way ahead of the curve:
I definitely agree on JavaScript: The Good Parts -- it's quite possibly the single most over-rated book I've ever read.
There is literally a Stack Overflow thread devoted to just about every single code example and paragraph in the book, because no one has any idea what he's talking about. And even the JavaScript gurus on SO can't figure out what he's actually trying to say a good percentage of the time.
I'm sure it would be a great book if I were already pretty good at JavaScript, but as a first book it's just awful. I had much better luck with a HeadFirst book that covered JavaScript, even though that is a little too dumbed down at times. I was then able to then go back and have a much better appreciation of what Crockford was trying to say.
Your second paragraph is nonsense. Any JS expert should be able to understand every point made in that book, by the very definition of expert.
Your third paragraph is completely sensible however. The Good Parts is horrible if you're a beginner programmer, and I'd definitely recommend against it. But if you have a CS degree or years of programming experience, it should not cause you trouble - it's a great, terse intro to JS that'll get you up and running in no time.
The worst book to learn from is JavaScript: The Definitive Guide [1]. It's unnecessarily lengthy (1000+ pages!) and attempting to learn from that has dissuaded more colleagues from JS than I care to remember.
The introduction to the book tells you it's not for beginners but experienced programmers. So complaining that it's not a good first book is like complaining coffee makes for a terrible cup of tea.
For someone who has programmed in C, C++, C#, Java, Python, Ruby etc., it's the perfect book: it succinctly explains the good and unique parts of JS. It's actually a bit too long in my opinion, the railroad diagrams and syntax parts can be skipped by the target audience.
When I was learning JS last year, coming from a background using other languages (Python, Actionscript, Java), this was the first book I read. It helped me immensely. Obviously AS3 shares a LOT of DNA with JS, but Crockford's funnel paved the way. Certainly not the be-all-end-all, but for a book I was able to read in an afternoon, I give it high marks.
Professional Javascript for Web Developers is really an excellent book. Also, I would like to mention a blog post [1] by Richard Bowell which was front-paged here recently who also recommends the same book.
I'm currently learning JavaScript and the thing that sucks is reading about IE incompatibility/workarounds on almost every other page of the book. Any advice on how should I handle it? Is it really necessary to keep in mind all those quirks or can I skip through those material right now and learn what works on most browsers?
Definitely skip it. You'll learn them one by one later as you run into them in your code. Or by the time you need to use most of them, IE's quirks won't matter for you target audience.
Yep, skip those pesky IE compatibility issues, except, if you expect to target IE <= 8, you should definitely get the shim library at the link below. It provides compatible IE functions for all the common native JS methods and functions that missing in IE <= 8. Then you never have to worry about IE again.
https://github.com/kriskowal/es5-shim
Skim the IE stuff, and use the book as a reference manual if you need to implement cross-browser functionality yourself. It's important to have a general idea about what won't work if you need to support IE in the future, but you don't need to know every single detail.
I tried doing a total immersion in JS recently by coding up small learning projects for Ember.js, Ember.js + Node.js, Node.js + Express, and some general experiments while reading "Secrets of the JavaScript Ninja" (I like this book, BTW).
All that said, I did a 90 minute sprint with Clojurescript tonight, and as awkward as it may seem to use an intermediate language, the development process is really nice. Whether I am modifying server side or client side code, the edit, try it cycle is very quick (a second or so). I have found that if I make little changes in one cycle, keep a browser JS console open with logging from client side code, and keep repls open for both the server side Clojure code and the client side Clojurescript code then I have a good window into both sides of a web app.
However, Node.js with either something like Express or (if you are brave) Ember.js is really nice also. I understand why people like Node.js.
I wish somebody would write a post like this for Ruby. Trying to craft a personal study plan of the best, most current resources from the large number of apparently high-quality offerings is difficult for a newcomer to the language. I'm operating on the assumption that success is mostly path-independent (just start doing stuff and going through resources, and you'll learn), but it still feels like a random walk approach to learning sometimes.
I'd also like a list of critical tools for programmers new to the Ruby langauage. These things don't always get highlighted in beginner resources because of the need to hand-hold on fundamental concepts for people who've never programmed. For instance, I wish when I'd learned Python that somebody would have told me right at the beginning to install ipython, virtualenv, pip, etc.
Edit: Wow. Thanks, guys, for all the good recommendations.
I would like to second Eloquent Ruby. Russ Olsen has a magical way of explaining things in a very simple manner.
I will always read anything he writes. Love his style. Now that I am thinking about it, I feel like re-reading that book.
The most important thing to remember, when you are learning programming for the first time, is that the process is very, very long. You make A LOT of mistakes and it can be INCREDIBLY frustrating. But....once you push through, and actually validate that you know what you just learned and actually figure stuff out...I think there are very few highs that rival that rush.
It's weird....but it is EXTREMELY satisfying. I think because the journey is so hard, that makes the discovery of the solution all the more pleasing.
So, I would say....just prepare your mind that you have a lot of long nights, and problems that may take you days/weeks/months to "fully grok". Once you get in that mindset and are prepared to slog through, you will make it and be much better off for it.
I'd recommend starting with The Well Grounded Rubyist, by David A. Black. Publication Date: June 4, 2009 | ISBN-10: 1933988657 | ISBN-13: 978-1933988658
I wouldn't recommend that to start tbh. Its a great book to get a deep understanding of how Ruby works, but as an intro, I think it could be a bit overwhelming and hard to get through.
1. Agile Web Development with Rails
2. The Rails Way
I've heard good things about "Beginning Rails 3", but I haven't read it myself, I'd pop that up to the top of the list if Agile Web Development with Rails isn't working for you.
I can give you my personal path I took when learning a few years ago if you don't mind starting with rails.
Start with Michael Hartl's Rails Tutorial [1]. I went through the rails 3 version with zero knowledge of ruby and you should feel very comfortable with the basics when you are done.
After that I read The Well-Grounded Rubyist [2]. Having used some ruby now I found the book easy to get into. It's a little dated but should still cover everything you need at this point.
Lastly I read Eloquent Ruby [3]. I highly recommend this book and is easily my favorite programing book.
Nobody has commented on the suggestion to aid learning with Spaced Repetition Software - specifically the Anki open source program.
Anybody try or use this technique? It looks interesting and sounds reasonable and effective. I took a peek at Anki but have to admit it looks messy (and the iOS app is $25, which is def. on the high end of the iOS pricing scale). I'd be curious to hear others' experience in this area...
I haven't used SRS for js specifically, but I've been using it lately to cement certain Ruby concepts. Best advice I can give is that it's totally worth it, but don't take shortcuts when authoring cards. Take the time to separate concepts into bite-sized, more simple (Rich Hickey simple, not "easy" simple) concepts, and write questions that elicit that knowledge.
Also, Anki is free for both desktop (every OS) and Android.
If you spend a lot of time making a good deck full of programming language facts, I'm sure that it works well enough. I don't think that it's any kind of substitute for sitting down and coding. I think that the core issue is that there are a lot of things you CAN memorize in order to make coding easier, but there are very few things that you MUST memorize in order to make coding possible. No matter how much you memorize, you're still going to end up sitting down to code and learning from your mistakes.
That said, if you want to give it a shot, I'd suggest starting with the desktop version of Anki. Make your own deck, because making a deck is its own form of studying. Use it for a while, and if you feel that it's something that you want to invest more time in, get the mobile app.
Oh, one other thing I'd like to mention about SRS. SRS techniques are designed to manage HUGE numbers of cards, ranging from a few hundred to tens of thousands. If you have less than a hundred or so cards, it's just a really smart flash card system - you could review all the cards every couple days without much trouble. People who really get into SRS tend to use it for everything, because it's an easy way to integrate more knowledge into their existing knowledge-management framework. As such, you should be careful about recommendations for using it for one particular field. The people doing the recommending usually have lower friction regarding adding a couple hundred programming cards to their deck than you will as a beginner.
If you don't feel like buying the app up front (not knowing if you will find it useful) you can just use anki's web interface [1]. I find it much faster to enter the cards on my desktop/laptop using the keyboard and then sync them to my mobile devices anyway.
The Anki business model is to give it out for free for all platforms and then exploit the iOS users.
StickyStudy is cheaper and so far works fine with my < 200 element deck.
Only problem I had is that it sometimes crashes after searching for a word and then clearing the search-box.
Anki works great for me but it is important to get its scope of usefulness. It's good for standalone facts, not interrelated concepts. This means it doesn't replace books nor practice. On the other hand it's a perfect complement to them.
The way I use it is to just create a card or two for every useful trick, library function, command line option or whatever I encounter that looks interesting or useful. The area it worked best so far is git - I no longer fumble for that elusive option to 'log' or 'diff' that I know exists but I just cannot remember it because I use it just rarely enough to forget it between use cases.
I do not create large decks upfront so I'm using it as a notepad rather than study book.
I haven't used it for programming languages (though I intend to the next time I learn one), but I used it for my maths degree (for sit-down exam at the end of the year), and it seemed to be very effective. The danger is always that it can be time consuming to create the content for it.
Anki does look a bit raw, but worked absolutely fine for me (though transferring LaTeX-ed decks between devices was a hassle). There's also memrise.com, which mostly focuses on languages, but allows users to create content on any subject. It's also more easily shareable there, I think.
In any case, the science behind SRSs is good, and in my experience it helps a lot with memorisation!
I think he has some good points; you can definitely program a lot faster in a language in which you have memorized much of the standard library and the API/frameworks you are using heavily. I don't really think SRS has a place when it comes to learning a new language. To me it makes more sense once you are certain you are going to specialize in a language/platform. I am still yet to try it.
Spaced repetition has a pretty good history. If you want a free online alternative, check out memrise.com. They're pretty popular in the language learning community, but they cover a lot of areas and you can create your own. For example, here's there physics section: http://www.memrise.com/courses/english/physics/
I'm trying to use Anki to learn various things and whilst it does seem to be working, some of the decks you can download could do with a firm hand on the layout / design tiller.
e.g. the C one presents the code in an awful centred and line-broken fashion which completely obliterates the location of significant comments and the like.
(But I believe the SRS people recommend you make your own decks as part of the process.)
In a nutshell, pressing the button this extension adds to Anki either pastes the contents of your clipboard as syntax-highlighted code, or applies syntax-highlighting to the text you have selected.
This makes code much, much easier to parse, especially when using Anki on a mobile device.
I'm guessing that's not going to do much in the Anki iOS app though.
On the plus side, checking the app to see if such an option exists found a bunch of options I didn't know about that will make my experience more pleasant. Ta.
Anki is great to recapitulate what you already know.
At the moment, I'm trying to use it for learning new stuff. I am preparing for lpic-1 certification exams, and I use only Anki as tool to study. For now I'm really satisfied.
> you'll love looking at the code to two very popular and powerful JavaScript projects: Underscore.js, Backbone.js
Is that a joke? I can't stand reading the source of those two libraries, even with the pretty two-column documentation. There have got to be better examples of readable JavaScript.
I'll third this recommendation. Herman's book is succinct, clear, and well-written. Although I wouldn't recommend it as your first intro to JS; If you've already been hacking in JS for a while, and want to take it to the next level, this is the book to buy.
I've recently made something that I hope to use to teach our new hires (who will all have programmed before, but probably not in javascript) the ins and outs.
I've had to learn JS pretty fast just a couple of months ago and from what I can read I managed to do almost exactly what Derek did, same exact books and all. Professional JS is indeed fantastic and is highly recommended. Same thing as far as reading Underscore and Backbone source.
For fun, try implementing something in Backbone. It's certainly one way of assessing if you're at all proficient in the language.
I read "JavaScript: The Good Parts" after having been using JavaScript for a couple of months and still found it overwhelming. Douglas Crockford moves through the topics at a very fast pace.
However, after a few more months of learning the language I went back to the book and was immediately thankful for how quickly he moved from topic to topic. I understood the references and was receiving quick tips on what to do and what to avoid doing with all the different elements that make up the language.
Also, I agree with the author, Professional JavaScript is the ultimate JavaScript book in my opinion.
TGP is mostly dogma. The title should make that very clear, but unfortunately, as usual, Crockford is short sighted so the title of his book is misleading, implying you might learn something about the language by reading it.
A much more appropriate title would've been "JavaScript: Crockford's Best Practices for Experienced JavaScripters", or "What's Wrong With JavaScript According to Crockford." Then it's pretty clear what the book is doing, and doesn't trick readers into thinking it's an introductory or learning book.
A few of Crockford's opinions are fairly widely accepted as good advice, but much of it is controversial at best, and in practice incorrect or misguided.
As for the article: it's mostly sound advice. I will reiterate reading the source to underscore and backbone. I started recommending this lately to people after they get comfortable with the language. Many popular patterns and techniques are used in these code bases and they're very approachable from a reading perspective. I read both a few months ago to get up to speed on a new project and I found it quite enjoyable compared to reading the likes of jQuery or Angular.
TGP isn't a good book for learning JavaScript the first time, it's true.
The time to read it is when you've been doing this for a while, and it's time to "unlearn what you have learned" before you can move on to the next level of expertise. There's a lot of dogma in the book, but that's not bad in the appropriate context: most people will find something to follow in its pages, but most people will also find something to question. Both experiences are valuable, especially for someone preparing to "take the next step," as it were.
This is really a good set of resources for learning Javascript. In addition I want to add the "Learning to love Javascript" presentation by Alex Russell from Google Code 2011, http://www.youtube.com/watch?v=seX7jYI96GE that I felt really boosted my learning curve (or at the very least kept me passionate about JS to continue learning as much as I possible could)
Thanks a lot for this post. As a relatively new web dev mostly working in jQuery (I get stuff to work right and be relatively fast, but thats about it), I've been very curious about where to go next.
This was one of the reasons why Backbone was my first choice compared to the other "MVC" frameworks. The documentation was simple and I think some the handling of Views helped you mentally organize your DOM manipulation code versus having a file riddled with various event bindings with possible selector conflicts hidden. Right now I am working with AngularJS but the documentation can be cryptic at times. I didn't have resources like John Lindquist's site (http://egghead.io), I may have suck with BackboneJS. It is still a great framework but AngularJS, after gaining experience, has some amazing features.
So true, that was one of my favorite things about Backbone. I don't even really look through the docs anymore, just jump straight to the source. It's incredibly well done.
It is a fantastic book for learning to avoid being bitten by all of the stupidity in JavaScript if you're used to programming in sane languages, but it isn't a tutorial or "Learn to Program" book by any stretch of the imagination.
To be completely honest, I'm a bit horrified people are learning JavaScript as a first language at all. The language does indeed have its "Good Parts" and it is incredibly useful because of its ubiquity, but I just wonder how many young brains are going be hardwired to think some of the design choices (the way block scoping works/doesn't work, equality, lack of modules, etc, etc) in current JavaScript versions are normal, when in fact they are very unfortunate.