Join the 85,000 open source advocates who receive our giveaway alerts and article roundups.
Get the newsletter
- Scope & Closures: Covers closure primarily, which is one of the most important foundational topics. All JS programs use closures, but most developers don't know that they're using it, or what to call it, or just how it works.
- this & Object Prototypes: Covers the mystery of how the
- Types & Grammar: Goes deep into coercion, the mechanism most people think is evil in JS. I encourage you to dig into it and learn it, because coercion not only isn't as bad or weird as you've been told, but it can actually help improve your code if you learn how to use it properly!
- Async & Performance (in progress): Explains why callbacks for async programming are insufficient, then goes deep into promises and generators as much better async patterns. Also covers optimizing and benchmarking JS performance.
- ES6 & Beyond (planned): Covering all the changes to JS coming in ES6, as well as forward looking to beyond-ES6 evolution on the horizon.
My books are the opposite. They're the anti-"The Good Parts." That doesn't mean they're the bad parts, it means they're all the parts. Rather than avoiding most of the language because one guy said to—rather than running away from the hard parts—I encourage you to run towards "the tough parts" and learn them. When you see something in JS that you don't understand or is confusing, instead of blaming the language as being poorly designed, turn your attention toward your own lack of understanding, and spend the effort to increase your understanding.
This is somewhat unique to JS developers, that they expect a language should be so simple and intuitive that merely glancing at it should be enough to understand it, and that if they can't, it's a failure of the language. Expecting perfectly self-explanatory syntax and rules wouldn't be reasonable of any other language, like Java or C++. If you were confused by code, you wouldn't blame the designers of those languages. You'd blame either your own understanding, or at least that of the person who wrote the code. Either way, learning the language better is the best solution to that lack of understanding. Many times, when developers hate something about JS, it turns out it's because they simply don't understand it enough. When I explain how it works, many times they go from hating it to appreciating it—and by the way, appreciating doesn't mean liking, it just means respecting.
JS is going to be the foundation of the web platform for the rest of our careers. We might as well get to know it better!
I'll leave you with this: I believe strongly, that the most important thing you can learn at university—of course, you're being taught lots of great stuff—but the most important is how to learn, and how to love and enjoy learning. You'll never find "just one thing" you love and do that for the rest of your career. The industry reinvents itself every couple of years. If nothing else, it'll just be Apple doing that. You have to be adept at learning and remastering new things. That's the path to success in your career, whatever interests you dig into.
Q: Five books, should they be read in a specific order?
Q: How important is free and open source software in your work?
A: Everything about my career is open source. I believe very strongly in the power of open source, and its position in the future success of our industry. If you study the history of technologies, they start closed/proprietary, are shepherded through adoption and evolution, and eventually end up open. Ultimately, open always wins. But increasingly, I believe open should be the default mode. Many people say, "I don't feel like I wanna put my stuff out, they'll make fun of my crappy code..." And when I write code, people say "you just have more confidence 'cause you're good." But if you look at my old code, there is some terrible stuff in there. When I say "you" in "You Don't Know JS", that's a collective term. I don't know it either.
Every time I start writing code for a project, I start with an empty file, publicly, on GitHub. I do the best I can and am constantly evolving. But instead of just using GitHub as a platform for marketing my own code and ideas, I assume that every line of code I write is the worst, and the only way to get better is with the help of others. Open source collectively makes the best software better than any one person can make.
It is a culture you should strive for individually, and professionally. I believe very strongly, "open" is the reason why all this exists, and why the stuff we're doing now will still exist 10 years from now.
Q: I'm in that camp where I am afraid to code publicly. Where do I start?
A: My perspective—and there are different answers—is to seek out others' projects. There is a lot of FOSS contribution that isn't about code. Docs are usually left to the end of a project, and are neglected, but it is critically important they are up to date. If you can read others' code, and add details, examples, or tests, that is a super important contribution you can make. Many of "the rockstars" in FOSS got there by just pitching in and started with docs/tests. Some projects go the extra mile, and identify "low hanging fruit" or bugs that are known to have simple solutions. It is a great place to start with, and you can learn about how the project works. Even providing bug reports is a way you can contribute without writing your first line of code. But even one line of code is important. Someone after you can learn from it.
A: GitHub is the de facto standard. Any community is fine, sure, and I wouldn't say "pick this project." You should pick a project that is interesting to YOU. If you are into data visualizations, get into D3. Find what you are passionate about. If you do, you'll quickly build your confidence, and that will create a virtuous cycle of making both the people and code, better.
Q: You said that you think JS will be the "only language for the web" for our careers? I'm not necessarily a supporter of Dart, or other similar languages, but do you not expect those to succeed?
In a bigger sense, there are hundreds of languages that you can compile into JS. You want to run your code on the web, so can "transpile" it into JS. I don't like most of those languages personally, but they are all super important! Source code, is not for a computer! There are an infinite number of ways to write code to produce the 1s and 0s. Source code is for the developer, and you need to find the language that works the best with your brain. Also, we need more experimentation, and more Compile-to-JS languages, like CoffeeScript, which influenced many great things being added to JS in ES6. The future, I think may be limited for CoffeeScript itself, but that's OK because it was very important to evolve JS forward. As far as Typescript, I don't like classes, but Eich is on record saying there may be something like the type annontations in the future of JS.
Learn JS first, but as you go about your career, you'll find other languages that work better for certain problems or teams. Many people do that because they don't wanna learn JS, but that is the wrong way of going about it. Once you really know JS, then it's totally OK and healthy for you to find other languages that you prefer that will use JS as their compliation target. That's great for the future of the web platform.