In his latest book, Effective JavaScript, David Herman dives deep into the programming language JavaScript and shows how to use it effectively to write more portable, robust, and maintainable applications, and libraries. The book brings together tips, techniques, and code samples to explain important concepts in JavaScript.

InfoQ sat down with David to talk about new trends in JavaScript and writing JavaScript libraries effectively.

InfoQ: What was the motivation behind writing this book?

David: I wanted to write a book that wasn’t about front-end development, or server-side development, but JavaScript is a programming language in its own right. My goal was to help people deepen their understanding of what it means to write correct and robust code in JavaScript. As JavaScript is found in more and more environments, from server-side programming with Node.js to Windows to GTK application development, I think now is the time for people to see JavaScript as a real one programming language and not just as part of the web browser development chain. And I have always liked the “Effective Application Development” series of books for their concise and pragmatic way of providing practical, expert programming advice

InfoQ: We tend to see ECMAScript and JavaScript interchangeably, which is confusing. Could you tell us a little more about their relationships or their differences? What version of JavaScript is currently in use? And what will come next?

David: It sounds confusing, but luckily they’re the same thing. Generally speaking, everyone refers to the JavaScript language. But JavaScript is officially specified by the Ecma standard organization, which created the name ECMAScript for the standard, mainly because of unfortunate branding issues. In practice, there is no real difference between the two. The latest version of the ECMAScript standard is Edition 5, commonly referred to as ES5. Most modern JavaScript engines more or less fully implement the ES5 language. The next version of the language will be Edition 6, which is currently slated to be finalized next year. However, the specification will be complete long before the standard is ratified, and JavaScript engines are already in the process of being ratified.

InfoQ: In your book, you give a lot of useful JavaScript programming tips. These are great tips for professional JavaScript programmers. How many of these tips owe their existence to the lack of certain features in JavaScript? I wonder if some of these issues could be addressed by future versions of the language.

David: Yes, I think some recommendations in Effective JavaScript could be avoided by improving the language. For example, some of the somewhat tricky scoping rules, described in Chapter 2, will be simplified with better constructs for variable declarations in ES6. Since ES6 is not yet finalized, I avoid talking about it in the book; these improvements can change very quickly and I don’t want to print anything subject to change.

InfoQ: JavaScript is becoming a very popular language and a lot of programmers want to get started. Do you have any recommendations for them?

David: Well, I hope they find Efficient JavaScript useful! For people who have never programmed, I also recommend Marijn Haverbeke’s book: “Eloquent Javascript” and Douglas Crockford’s: “JavaScript: The Good Parts.”

InfoQ: In one of your tips, you mentioned that JavaScript programmers should be comfortable with “high-level functions”. Do you think it is important for JavaScript programmers to learn functional programming?

David: I don’t think functional programming is a prerequisite for programming in JavaScript. But learning functional programming is a great way to improve your programming skills, and it has multiple uses in JavaScript. JavaScript provides many people with a first glimpse into functional programming concepts. I talk about these different concepts in the book, like high-level functions and the stateless API design.

InfoQ: What are the conventions developers should follow to properly write a JavaScript library?

David: Chapter 6 of Effective JavaScript is dedicated to this question. Some of the design aspects that are specific to JavaScript, including handling JavaScript type coercion, working with JavaScript arrays, and using “option objects” as a way to provide APIs with potentially a large number of optional arguments. There are also a few library design elements that are more universal but still appropriate for JavaScript, such as using structural typing (also known as “Duck Typing”) and method chaining.

InfoQ: There is a trend right now to create 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 with limited knowledge of JavaScript be effective at JavaScript?


David: Yes, I think JavaScript is increasingly becoming a target for compilation from other languages. I hope that this trend will continue and, at the same time, that JavaScript will continue to gain a larger audience of programmers. So, I don’t think JavaScript becomes just a “bytecode language”.


Whether a person can be effective in a language that compiles into JavaScript is more of a question for these other languages. Some languages, like CoffeeScript or TypeScript, are designed to be very close to the programming model of JavaScript. You can’t program with CoffeScript without understanding JavaScript. Other languages, like ClojureScript or Roy, have a radically different approach to programming style. So ClojureScript might be easier for a programmer who is comfortable with Clojure but not with JavaScript.


There is still interest in learning JavaScript. For example, when a program does not behave as expected, it may be necessary to understand what is going on in the implementation to diagnose the problem. After all, the problem could be caused by a bug in the compiler that generates the JavaScript, and even if it doesn’t, the platform (like a web browser or Node.js) can report errors in the form of JavaScript.


InfoQ: In your book, you have a section on concurrency and asynchronous programming. Is this part only for JavaScript developers working on the server-side? A gripe I often hear about asynchronous programming is the difficulty in handling callbacks. Do you think the “Promise” API or other alternatives can help?


David: Concurrency and asynchronous programming are central to programming in JavaScript, at the server level, as you say, but also at the web browser level and more or less in any environment that runs JavaScript. Certain types of people are used to dealing with the complexity of asynchronous programming logic, including


“Promises”, which I discuss in Item 68. I think Promises are great at handling that complexity and that they are becoming more popular and widespread in JavaScript. Yet not all libraries and applications have adopted the Promises, nor even a single approach to asynchronism. So, it’s important to understand the basics of the loop.


InfoQ: You are part of the asm.js project. I know a lot of people are excited about its possibilities and uses. What is the goal of the asm.js project?


David: The asm.js project identifies a subset of JavaScript which can be used as a good target language for compilers and which could be executed extremely efficiently in modern JavaScript engines. The first version of asm.js, which we are just in the process of releasing, mainly targets very low-level languages ​​like C and C ++. This helped us improve the performance of the Emscripten compiler (and should also benefit the Mandreel compiler, which is similar), which makes it possible to build native C / C ++ applications into JavaScript. Our current benchmarks, which run on “Nightly” versions of Firefox, have been seen to be twice as slow as their native versions. And hopefully, we can apply more optimizations overtime to get as close to native speed as possible


Currently, asm.js is extremely low-level and useful only for a very small set of programs. Over time, we would like to extend asm.js to incorporate more functionality from JavaScript, while preserving the excellent performance that we can currently see in the first version. Ideally, this should allow asm.js to become a suitable target compiler for higher-level languages ​​like Java, C #, Clojure, Ruby, Python, Racket, and many more.

As you previously noted, JavaScript is becoming increasingly popular as a compiler target, in part because of its ubiquity. The overall goal of asm.js is to provide better support for these languages ​​and compilers so that people can port their existing code to the web (or another JavaScript platform), or just so that they can write the logic of their application in the language of their choice. JavaScript developers interested in learning more about this should take a look at these excellent blog posts from John Resig and Axel Rauschmeyer:


Please enter your comment!
Please enter your name here