JavaScript Programming

Pushing the Limits

Jon Raasch

• Publisher: Wiley
• Year: 2013
• Print ISBN: 9781118524565
• eBook ISBN: 9781118524404
• Edition: 1
• Topic: Computer Science
• Subtopic: Programming in JavaScript
• Index: Computer Science

Take your JavaScript knowledge as far as it can go

JavaScript has grown up, and it's a hot topic. Newer and faster JavaScript VMs and frameworks built upon them have increased the popularity of JavaScript for server-side web applications, and rich JS applications are being developed for mobile devices. This book delivers a compelling tutorial, showing you how to build a real-world app from the ground up. Experienced developers who want to master the latest techniques and redefine their skills will find this deep dive into JavaScript's hidden functionalities gives them the tools to create truly amazing and complex applications.

• JavaScript has evolved into much more than simple client-side scripting; this book delves into advanced topics not generally found in other more intermediate JS development books
• Expert author delivers an in-depth tutorial showing how to build a real-world app that is loosely coupled, with each component built to exist separately
• Explores how to build a backbone app, the importance of JavaScript templates, Node.js and MongoDB, 3D Canvas using WebGL / Three.js, how to convert a desktop app into a dedicated mobile app, and much more
• Ideal for experienced developers with a deep knowledge of JavaScript as well as online developers with strong graphic design skills who are experienced in HTML/CSS and want to develop their front-end skills

JavaScript Programming: Pushing the Limits will arm you with the skills to create killer apps for the 21st Century.

Part I: Starting From a Firm Foundation

Chapter 1: Best Practices

Chapter 2: Libraries, Frameworks, and Plugins

Chapter 1

Best Practices

A firm foundation is vitally important for any application. Before you write a single line of code, you need to spec out the app's architecture. What features will your app have, and how will these be implemented? More importantly, how will these features work with one another; in other words, what is the app's ecosystem?

Answering these questions involves a combination of research, prototyping, and a firm grounding in best practices. While I can't help you research or prototype the specific components of your app, I can pass on the wisdom I've gained on best practices.

This chapter covers the fundamental engineering concept of loose coupling, then explains one method of achieving it: JavaScript MVCs and templating engines. Next you discover a variety of development tools, such as Weinre, version control and CSS preprocessing. Finally, you learn how to set up a project in Grunt to automate tasks such as concatenation and minification. Using Grunt, you establish a test driven development pattern that runs your app through a suite of tests whenever a file is modified.

Loose Coupling

If you take only one thing from this book, I hope that it's to avoid tight coupling in your app. Tight coupling is an old engineering term that refers to separate components being too interdependent. For instance, say that you buy a TV with a built-in BluRay player. But what happens if the TV breaks? The BluRay player may still work perfectly, but is rendered useless by the broken TV. From an engineering perspective, it's better to avoid tight coupling and get a separate, external BluRay player.

This pattern also applies to software development. Basically, you should design your app with isolated modules that each handle a single task. By decoupling these tasks, you minimize any dependencies between different modules. That way each module remains as “stupid” as possible, able to focus on an individual task without having to concern itself with the other code in your app.

But it can be challenging to determine what exactly should be grouped into a module. Unfortunately, there's no one-size-fits-all solution—too few modules leads to tight coupling, too many leads to unnecessary abstraction. The best approach is in the middle: designing your app to use a reasonable number of modules with high cohesion. Cohesive modules group highly related pieces of functionality to handle a single, well-defined task.

Problems with Tight Coupling

Examples of tight coupling are all around us. If you're like me, your phone has replaced your music player, video game console, and even your flashlight. There's a certain convenience to having all these features integrated in one simple device. In this case, tight coupling makes sense. But that means that when one thing breaks, a chain of failures can occur—listen to enough music on your phone and suddenly your flashlight is out of batteries.

In software development, tight coupling isn't necessarily a bad thing—poorly designed coupling is more the problem. Apps almost always have a certain number of dependencies; the trick is to avoid any unnecessary coupling between separate tasks. If you don't take efforts to isolate different modules, you'll wind up with a brittle app that can be completely broken by even small bugs. Sure, you want to be doing everything you can to avoid bugs in the first place, but you aren't doing yourself any favors if every bug takes down your entire app.

Furthermore, debugging a tightly coupled app is extremely difficult. When everything is broken, it's almost impossible to track down exactly where the bug happened in the first place. This issue results from what is commonly referred to as spaghetti code. Much like pieces of spaghetti, the lines of code are all interwoven and very difficult to pull apart.

Advantages of Loose Coupling

Even if you rarely encounter bugs, loose coupling still has some pronounced advantages. In fact, one of the main reasons to build loosely coupled apps boils down to another cornerstone of classic engineering: interchangeable parts. Over the course of production, it's often necessary to rebuild portions of your app. Has Google started charging for their translation API? Better patch something else in. Has a component scaled poorly and begun to run slowly under load? Better rebuild it.

If your app is too tightly coupled, a change in one module can cause a ripple effect, where you have to accommodate the change in all the dependent modules. Loose coupling avoids that extra development time, and keeps code changes contained in individual modules.

Furthermore, loose coupling encourages easier collaboration with other developers. When all the individual components are isolated, working on different pieces in parallel becomes much easier. Each developer can work on his or her task without fear of breaking something someone else is working on.

Finally, loose coupling makes testing easier. When each piece of your app handles a separate, specific task, you can easily set up unit tests to ensure these tasks are executing correctly under any number of circumstances. You'll find out more about unit testing later this chapter.

In an ideal world, you'd never have to refactor your codebase. But there will always be unforeseen issues, and even if you could account for every possible scenario, why would you bother? Trying to preemptively solve problems can lead to “premature optimization” and is sure to slow down development. In an agile world, you should only concern yourself with the problems you face right now, and deal with future issues in the future. Loose coupling streamlines the agile development process, and allows your codebase to evolve naturally as conditions change.

JavaScript MVCs and Templates

Continuing the theme of loose coupling, another design pattern emphasized in this book is the use of JavaScript model-view-controllers (MVCs) and templates. These provide a structure to decouple various aspects of your application.

MVCs

MVC is a design pattern that encourages loose coupling. It separates the data that drives an application from the visual interface that displays that data. Using an MVC framework allows you to change the front-end styling of an application, without having to modify the underlying data. That's because MVCs separate concerns into three related components: the...

Table of contents

• Cover
• Title Page
• Table of Contents
• Introduction
• Part I: Starting From a Firm Foundation
• Part II: Building the Front End
• Part III: Working with Server-Side JavaScript
• Part IV: Pushing the Limits
• Apendix: CSS Preprocessing with LESS