You don't know JavaScript, but you should

This is a partial transcript of a meeting with Kyle Simpson, an Open Web Evangelist from Austin, TX, who's passionate about all things JavaScript. He's an author, workshop trainer, tech speaker, and OSS contributor/leader.

Thank you all for having me. I'm Kyle Simpson, known as "getify" online on Twitter, GitHub, and all the other places that matter. I was here in Rochester teaching a workshop for the Thought @ Work conference this past weekend, and figured I'd stick around to check out some JavaScript (JS) and Node classes here in the New Media Interactive Development program, so thank you for having me.

I have been writing a book series on JavaScript called You Don't Know JS. The entire series is being written in the open, up online on GitHub for free reading. They're also being professionally edited and published through O'Reilly. There are five titles planned for the series: two have already been published, the third is complete and in final editing, the fourth is almost complete, and the fifth one will commence soon.

1. 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.
2. this & Object Prototypes: Covers the mystery of how the this keyword works, and then tackles the misconception that JS has classes—not true! Instead, JavaScript has prototype delegation, and we should embrace that rather than trying to fake class orientation.
3. 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!
4. 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.
5. ES6 & Beyond (planned): Covering all the changes to JS coming in ES6, as well as forward looking to beyond-ES6 evolution on the horizon.

To understand the spirit of this series, compare it to JavaScript: The Good Parts by Douglas Crockford. His book was both good and bad for our community. It's almost single-handedly responsible for bringing lots of developers to (or back to!) the language and giving it serious attention. We owe a lot to him for that. But it also taught developers that there is only a small part of the language you need to learn. And because you only have to learn a little bit of it, that's all most developers ever learn. Even developers with 5 or 10 years JS experience know comparatively very little of the language.

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.

I believe JavaScript takes time to learn properly and completely, and that if you're going to write it, then you should invest that effort. You should understand why the code that you write works the way that it works. Instead of saying "it works, but I don't care how," the most important question you can always ask is: "How does it work, and WHY?" I'm an open web evangelist who teaches JavaScript for a living. I work with developers all the time who've learned JS incompletely and improperly, and they're having to fight hard against the grain to re-learn it. That's why I'm so encouraged to see you learning JS in university. By learning JS properly here in school, you can graduate and come right into the industry as a new generation of developers that already understand and appreciate the importance of JS as the standard for the entire web platform.

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&A session

Q: Five books, should they be read in a specific order?

A: Scope and Closures is in most demand and chronological release order is certainly OK. The first three are about the core of JavaScript. Four and five will be build upon the first three, but mostly deal with new things coming to the langauge as of ES6.

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.

Q: Where?

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?

A: Great question, and loaded, but... Dart isn't going to succeed in replacing JavaScript, not because it is bad or poorly designed, but because of how Google is going about it. Going beyond what they say on their site, they've positioned it to compete against JS, in hopes of replacing it, rather than being a language that experiments with things to intentionally inform and influence the future of JS. From the original "leaked memo" where the world learned about Dart in terms of "fundamental flaws [in JavaScript] that cannot be fixed," to the Dartium VM they're building in Chrome to sit alongside JS, to the Dart2JS transpiler—the messaging is unclear and smells of not just being a "better compiling JS lang," but more an attempt to hope JS declines if developers can just write Dart in the web natively. I can tell you this for sure: Mozilla will never implement Dart in Firefox. Unless there is a future where Firefox doesn't exist, which I cannot imagine, Dart will not replace JS.

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.