with Small-Scale JavaScript Experience
In our endeavor to add developers with JavaScript experience to our team, we've encountered many candidates who feel small-scale JavaScript experience, such as input field validation or jQuery element transitions, warrants listing “JavaScript” prominently on a résumé.
In an interview, it doesn't take much time to determine such a candidate has no problem hooking up a button handler, perhaps in the context of an ASP.NET Web Forms application, but would be hard-pressed to create a JavaScript module that has variables that are protected from external manipulation.
As our organization's use of JavaScript has evolved, our definition of what it means to have JavaScript experience has evolved as well. A few years ago, if a developer had a bit of experience with jQuery, we would check our “JavaScript” box with satisfaction.
Now, however, we're looking for a lot more. And we're not alone. It's no longer uncommon for entire applications to be written in JavaScript. In so-called single-page applications (SPAs), the JavaScript code organizes the entire application, bearing vastly more responsibility than the ephemeral click-handlers of the past. In order to participate in the development of a large-scale JavaScript application, developers must know how to use the language in a structured and disciplined way while simultaneously taking advantage of its many unique capabilities and quirks.
Through the examples in this book, we hope to help you, the small-scale JavaScript developer, make it big.
Developers Responsible for Choosing Programming Languages for a New Project
Perhaps you've heard the adage “No one ever gets fired for buying IBM.” The statement reflects the feeling that, when faced with choosing a technology partner for an IT project, it's unlikely that the decision to pick an established, reputable company such as IBM will be second-guessed. The statement implies that IBM is the safe choice. Even if the project experiences cost over-runs, missed deadlines, or complete failure, the choice of IBM is above reproach.
If you're in a position to choose the language or languages used for the development of a new application, you're in the same position as the IT manager choosing a technology partner. There are many tried-and-true programming languages with long histories. For instance, C# and Java, each backed by a large, established technology company, have been used to build both web and desktop applications for over a decade. No one would be fired for choosing C#.
In terms of being a safe choice for a new programming project, especially in the enterprise, JavaScript is decidedly not like C#. JavaScript is not a mature, staid, starched-shirt-wearing programming language. She is young, daring, and free-spirited.
She doesn't have the same long track record of success for large-scale software projects that languages such as C# and Java have. That's not to say that projects using C# and Java are guaranteed to succeed. If a project using one of those languages isn't successful, however, language choice probably wouldn't be included as a factor contributing to failure.
As we mentioned in the previous section, JavaScript makes it all too easy to write disastrous code. This has given her a bit of a reputation, reducing the likelihood you'd want to bring her home to meet mom and dad.
JavaScript's reputation should not automatically exclude her for consideration for projects that could benefit from her strengths. Node.js, a server-side JavaScript engine, is lightweight and highly scalable; perfect for real-time and data-intensive applications. JavaScript may be used to create rich user interfaces in the browser. Client-side frameworks such as Ember and AngularJS may be used to build complete browser-based applications that can help reduce the load on the web server by off-loading presentation logic to the client.
While we can't guarantee it will succeed, the upcoming chapters will show ways to mitigate the risk of choosing JavaScript for your next project by applying the lessons we've learned while working on our own projects.
Success will not happen by accident, especially with JavaScript. It requires a firm grasp of engineering principles, which are the subject of the first chapter.
HOW THIS BOOK IS STRUCTURED
We've organized the book into five parts.
Part I, “Laying a Solid Foundation,” covers key concepts of software engineering such as the SOLID and DRY principles. It also discusses the benefits of unit-testing and test-driven development. Part I also introduces the tools and JavaScript libraries that will be used throughout the book. Finally, it discusses objects in JavaScript and their testability.
In Part II, “Testing Pattern-Based Code,” we describe and use test-driven development to create several useful code patterns. Some of the patterns, such as the Singleton, may be familiar from other languages you're familiar with. Others, such as Promises, are associated primarily with JavaScript.
Part III, “Testing and Writing with Advanced JavaScript Features,” describes how to leverage and test more advanced features of the JavaScript language. It also covers creation and testing of applications that use advanced program architectures, such as the Mediator and Observer Patterns.
Part IV, “Special Subjects in Testing,” provides examples of testing DOM manipulation, and it also illustrates the use of static analysis tools to enforce coding standards.
Finally, Part V, “Summary,” reviews the concepts of test-driven development, and also presents a collection of JavaScript idioms that you will have encountered in the book.
WHAT YOU NEED TO USE THIS BOOK
To run the samples in the book, you need the following:
● A text editor
● A web browser
The source code for the samples is available for download from the Wrox website at:
www.wrox.com/go/reliablejavascript
Open-source software based on the book can be found on GitHub at www.github.com/reliablejavascript.
CONVENTIONS
To help you get the most from the text and keep track of what's happening, we've used a number of conventions throughout the book.
NOTE Notes indicate notes, tips, hints, tricks, and asides to the current discussion.
As for styles in the text:
● We italicize new terms and important words when we introduce them.
● We present keyboard strokes like this: Ctrl+A.
● We show filenames, URLs, and code within the text like so: persistence.properties.
We present code in two different ways:
SOURCE CODE
As you work through the examples in this book, you may choose either to type in all the code manually, or to use the source code files that accompany the book. All the source code used in this book is available for download at www.wrox.com. Specifically
