Learning JavaScript - my experience and advice
sivers.org
sivers.org
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.
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.
He argues (and I agree) that prototypal inheritance isn't complicated unless you're coming from a very classical inheritance background.
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.
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.
To see what I mean, look at the examples at: https://developer.mozilla.org/en-US/docs/JavaScript/Guide/Cl...
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 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++
Your concerns echo those of Edsger Dijkstra when he discussed the educational shortcomings of popular PLs in 1975:
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EW...
For what it's worth, I share your dismay. However, I (and many others) cut my teeth on BASIC -- turned out just fine.
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...
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.
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.
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
[1] until now. [2] Chapters 3-4. http://discover-devtools.codeschool.com/chapters/3
debugger;
I look forward to applying to Hack Reactor when it's financially feasible! :)
Chrome instructions - https://developers.google.com/chrome-developer-tools/docs/ov... ... others are easy enough to find
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.
1) What `this` means in a function context https://developer.mozilla.org/en-US/docs/JavaScript/Referenc...
2) The prototype chain and prototypal inheritance https://developer.mozilla.org/en-US/docs/JavaScript/Introduc...
3) Function closures and variable scoping https://developer.mozilla.org/en-US/docs/JavaScript/Guide/Cl...
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 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.
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.
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?
[1] http://javascriptissexy.com/how-to-learn-javascript-properly...
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'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.
http://ruby.railstutorial.org/ruby-on-rails-tutorial-book (Include every section labeled optional)
For general Ruby though, less so. I've heard good things about http://tryruby.org/, and I liked the Pickaxe book (though I didn't love it).
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.
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.
[1] http://ruby.railstutorial.org/
[2] http://www.amazon.com/Well-Grounded-Rubyist-David-Black/dp/1...
[3] http://www.amazon.com/Eloquent-Ruby-Addison-Wesley-Professio...
http://www.amazon.com/Eloquent-Ruby-Addison-Wesley-Professio...
If you just want to learn some basics of Ruby without diving into an entire book, check out Ruby Monk. All of the tutorials are interactive:
I would recommend in this order
1. Beginning Ruby (From Novice to Professional)
2. Eloquent Ruby ... then
3. The Well Grounded Rubyist
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.
It was linked here the other day, but Superhero JS is another great "what is the path to javascript mastery" lists:
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...
Also, Anki is free for both desktop (every OS) and Android.
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!
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.)
https://ankiweb.net/shared/info/491274358
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.
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.
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.
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.
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.
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.
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.
It's called "New to JS" and is available on github at http://caplin.github.com/new2JS and the source is https://github.com/caplin/new2JS.
Keen to get any feedback / pull requests.
For fun, try implementing something in Backbone. It's certainly one way of assessing if you're at all proficient in the language.
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.
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.
If you are considering buying it, just watch the talk instead: http://www.youtube.com/watch?v=hQVTIJBZook.
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.
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.
I really like the way codeschool teachers their javascript track.
Zakas "Prof JS for Web Developers" is comprehensive.
Strom "3D Game Programming for Kids: Create Interactive Worlds with Javascript" teaches JS by creating games.
Angular has _huge_ obstacles for dev usability when Backbone's source is so accessible you can use it to help learn js.