Preface

It wasn’t a long time ago that many JavaScript engineers or, most of the time, web frontend engineers, were still focusing on solving detailed technical issues, such as how to lay out specific content cross-browsers and how to send requests cross-domains.

At that time, a good web frontend engineer was usually expected to have notable experience on how detailed features can be implemented with existing APIs. Only a few people cared about how to write application-scale JavaScript because the interaction on a web page was really simple and no one wrote ASP in JavaScript.

However, the situation has changed tremendously. JavaScript has become the only language that runs everywhere, cross-platform and cross-device. In the main battlefield, interactions on the Web become more and more complex, and people are moving business logic from the backend to the frontend. With the growth of the Node.js community, JavaScript is playing a more and more important roles in our life.

I am currently working for an IoT company called Ruff that builds a platform for JavaScript to write applications run on embedded devices. You might have seen a fake book cover in the title of Writing Device Drivers in JavaScript, but that is actually a part of what we do.

The boom of JavaScript, however, makes people realize that the language itself might not be powerful enough for applications on a larger scale. While we enjoy the flexibility of the language, we suffer from its lack of static-type information; for instance, consider the following:

• No static type checking: We have to rely on debugging or tests to get rid of simple errors that could be eliminated when the code is written.
• Refactoring is a pain: Basically, what the IDEs or editors can do about JavaScript code is renaming local variables or exported module functions at best.
• Understanding code is difficult: When you grasp a piece of code, you might have to look around and manually search for references just to figure out which properties an object has and what types of property they are. This happens to our own code as well.

Compared to tools such as ESLint and even Flow, which only partially solve the problems, TypeScript does a really good job while it is still sticking to the ECMAScript standard.

TypeScript is indeed an awesome tool for JavaScript. Unfortunately, intelligence is still required to write actually robust, maintainable, and reusable code. But wait, doesn’t the intelligence part involve the true value of our work?

We might all have had trouble finding clues to mysterious bugs, or squeezed our head thinking about how we can add new features to the existing code base. Some of us, with experience and intuition built over the years, may directly come up with a design that’s not bad. For these people, getting through the common design patterns can help gain knowledge of what people have already catalogued over years in the industry or be better understood when discussing software designs with others. For people who have less experience, learning common design patterns may be a more straightforward approach to creating code that’s beautifully designed.