In his recent book Effective JavaScript, author David Herman takes an in-depth look at the JavaScript programming language and how to use it effectively to write more portable, robust and maintainable applications and libraries. This book brings together tips, techniques, and code examples to explain important JavaScript concepts.
InfoQ spoke with David about new trends in JavaScript and writing effective JavaScript libraries.
InfoQ: What was the motivation to write this book?
David: I wanted to write a book that was not about front-end development, or server-side development, but about JavaScript as a programming language all to itself. My goal was to help people deepen their understanding of what it means to write good, robust code in JavaScript. As JavaScript is moving into more environments from server programming in Node.js to Windows and GTK application development, I think the time is right for people to see JavaScript as a programming language in its own right, not just a piece of the web browser development tool chain. And I have always loved the Effective Software Development series for its concise and no-nonsense approach to giving practical, expert programming advice.
InfoQ: We tend to use ECMAScript and JavaScript interchangeably, which is confusing. Could you tell us a little bit more about their relationship or differences? What version of JavaScript is in use right now? And what is coming next?
David: It does seem confusing, but thankfully they're basically the same thing. Generally speaking, everyone refers to the language as JavaScript. But JavaScript is officially specified by the Ecma standards organization, which created the name ECMAScript for the standard due to unfortunate trademark issues. In practice, there's really no difference between the two.
The latest version of the ECMAScript standard is Edition 5, commonly referred to as ES5. Most modern JavaScript engines implement more or less the complete ES5 language. The upcoming version of the language will be Edition 6, which is currently scheduled to be officially released next year. However, the spec will be finished well before the standard is ratified, and JavaScript engines are already implementing select features of ES6.
InfoQ: In your book you specified many useful JavaScript programming tips. These are really good tips for professional JavaScript programmers. How many of them are because JavaScript lacks certain features? I wonder whether some of them could be fixed in the future version of the language.
David: Yes, I do think some of the advice in Effective JavaScript could be better served by improvements in the language. For example, some of the tricky scoping rules described in Chapter 2 will hopefully become simplified with better variable declaration constructs in ES6. Since ES6 is not yet finalized, I avoided discussing it in the book; these things have a way of changing quickly, and I didn't want to put in print anything that was especially likely to change.
InfoQ: JavaScript is becoming a very popular language and lots of programmers want to get a head start. Do you have any recommendations for them?
David: Well, hopefully they find Effective JavaScript helpful! For people who are newer to programming, I also recommend Marijn Haverbeke's "Eloquent JavaScript" and Douglas Crockford's "JavaScript: The Good Parts."
InfoQ: In one of your tips you mentioned that JavaScript programmers should get comfortable with "Higher order functions". Do you think it is important for JavaScript programmers to learn functional programming?
David: I don't think functional programming is a necessary prerequisite to programming in JavaScript. But learning functional programming is a great way to enhance your programming skills, and it has many uses in JavaScript. For many people, JavaScript actually provides them with their first taste of functional programming idioms. I touch on several of these idioms in the book, including higher-order functions and stateless API design.
InfoQ: What are some of the conventions developers should follow for a well-written JavaScript library?
David: Chapter 6 of Effective JavaScript is dedicated to this question. Some aspects of library design that are specific to JavaScript include dealing with JavaScript's type coercions, working with JavaScript arrays, and using "options objects" as a way to provide API's with potentially large numbers of optional arguments. There are also some elements of library design that are more universal but are still appropriate for JavaScript, like using structural typing (also known as "duck typing") and method chaining.
InfoQ: There is a trend right now to build languages that compile to JavaScript. For example CoffeeScript, ClojureScript or TypeScript. Do you think JavaScript is slowly becoming a bytecode language for the Web? Can a person having limited JavaScript knowledge be effective in these languages?
David: Yes, I do think that JavaScript is increasingly becoming a target for compiling other languages. I expect this trend will continue, and yet at the same time, JavaScript continues to gain a larger audience of programmers. So I don't think JavaScript is becoming exclusively a "bytecode language."
Whether a person can be effective in languages that compile to JavaScript is largely a question of those other languages. Some languages, like CoffeeScript or TypeScript, are designed to very closely match the programming model of JavaScript. You can't really program CoffeeScript without understanding JavaScript. Others, like ClojureScript or Roy, have more radically different programming styles. So ClojureScript might be easier for a programmer who's comfortable with Clojure but not JavaScript.
However, there are still benefits to learning JavaScript regardless. For example, when a program is misbehaving, it may be necessary to understand what's happening in the implementation in order to diagnose the problem. After all, the problem could be caused by bugs in the compiler that generated the JavaScript, or even if not, the platform (such as the web browser or Node.js) may report errors in terms of JavaScript.
InfoQ: In your book you have a section on concurrency and asynchronous programming. Is this only meant for server-side JavaScript developers? One common complaint I hear about doing asynchronous programming is the difficulty of managing all the callbacks. Do you think Promise API or other alternative APIs will help?
David: Concurrency and asynchronous programming are central to JavaScript programming, on the server side as you say but also in the browser and pretty much every environment that runs JavaScript. There are a number of styles people use to manage the complexity of asynchronous program logic -- including promises, which I discuss in Item 68. I think promises are a great way to manage that complexity, and they're becoming more popular and widely used in JavaScript. However, not all libraries and applications have settled on promises or any other single approach to asynchrony. So it's important to understand the basics of event loops and callbacks in order to work with the variety of JavaScript concurrency styles.
InfoQ: You are part of the asm.js project. I know lots of people are quite excited about the possibilities and its usage. What are the goals of the asm.js project?
David: The asm.js project identifies a subset of JavaScript that can serve as a good target language for compilers and that can be executed extremely efficiently in modern JavaScript engines. The first version of asm.js, which we're just in the process of releasing now, focuses on very low-level languages like C and C++. This has helped us to improve the performance of the Emscripten compiler (and will hopefully also be beneficial to the similar Mandreel compiler), which makes it possible to compile native C/C++ applications to JavaScript. Our current benchmarks, running in nightly builds of Firefox, are seeing running times down to about 2x that of a pure native implementation. And we expect to apply more optimizations over time to try to get as close to 1x as possible.
Currently, asm.js is extremely low-level and only helpful for a pretty narrow set of programs. Over time, we'd like to expand asm.js to incorporate more features of full JavaScript while still preserving the excellent performance we're currently seeing in the first version. Ideally, this will open up asm.js to becoming an appropriate compile target for higher-level languages like Java, C#, Clojure, Ruby, Python, Racket, and many others.
As you noted above, JavaScript is getting more popular as a target for compilers, mostly due to its ubiquity. The overall goal of asm.js is to provide better support to these languages and compilers, so that people can port their existing code to the web (or other JavaScript platforms), or simply so they can write their application logic in their language of choice.
JavaScript developers interested in learning more should check out these excellent blog posts by John Resig and Axel Rauschmeyer:
About the Book Author
David Herman is a senior researcher at Mozilla Research. He holds a BA in computer science from Grinnell College and an MS and PhD in computer science from Northeastern University. David serves on Ecma TC39, the committee responsible for the standardization of JavaScript.
