Full Stack JavaScript Development with MEAN
Close
    • Full Stack JavaScript Development with MEAN
    • Notice of Rights
    • Notice of Liability
    • Trademark Notice
    • About SitePoint
    • About Adam Bretz
    • About Colin J. Ihrig
    • Who Should Read This Book
    • Conventions Used
    • Supplementary Materials
    • Want to Take Your Learning Further?
    • The Rise of Full-stack JavaScript
    • Summary
    • Familiarity with JavaScript
    • The Problem with I/O
    • Your First Node.js Server
    • Summary
    • npm
    • package.json
    • The node_modules Folder
    • require()
    • Writing a Module
    • Summary
    • The Event Loop
    • Asynchronous Coding
    • Callback Functions
    • Event Emitters
    • Listening for Events
    • Exception Handling
    • Promises
    • Summary
    • Command Line Arguments
    • Working with the File System
    • The Current Working Directory
    • Streams
    • Web Programming
    • Summary
    • Server Plan
    • Structuring the Application
    • Getting Started
    • Routing
    • Database Module
    • Querying the Database
    • Response Generator
    • Putting It Back Together
    • Summary
    • NoSQL Databases
    • History of MongoDB
    • Installing MongoDB Locally
    • Cloud Hosting
    • The MongoDB Shell
    • Summary
    • Mongoose Node Module
    • Summary
    • Adding Mongoose Models
    • Populating the Database
    • Accessing the Database
    • Summary
    • Relational Databases and SQL
    • Summary
    • The Building Blocks of Express
    • Putting It Together
    • Generating an Express App
    • Summary
    • Starting the Server
    • app.js
    • Router Object
    • Exercise
    • Summary
    • Updates to package.json
    • The npm start Script
    • Defining Routes
    • Update index.js
    • Summary
    • hapi Overview
    • Express Comparison
    • Summary
    • Single-page Applications
    • Model-View-Controller Architecture
    • Getting Angular
    • Angular "Hello World"
    • Summary
    • One-Way Data Binding
    • Two-Way Data Binding
    • Technical Overview
    • Simple Controllers
    • Data Binding with Lists
    • Summary
    • Overview
    • Creating Directives
    • Summary
    • Syntax
    • Dependencies
    • Expanding on Our Example
    • Simple Service
    • Summary
    • Getting Started with ngRoute
    • Application Overview
    • Code
    • Summary
    • The Home Page
    • app.js
    • Template Files
    • Summary
    • Introducing Gulp
    • Setting Up Gulp
    • Designing a Gulp File
    • Summary
    • The debugger Statement
    • Node’s Debugger
    • node-inspector
    • Summary
    • Testing Node
    • Testing Angular
    • Summary

Introduction

Web programming is a task that takes years to truly understand. Part of the complexity comes from the sheer number of moving parts. Effective programmers need at least a basic understanding of many topics, including networking, protocols, security, databases, server-side development, and client-side development, amongst others. For many years, this also included working with a medley of programming languages.

Client-side programming alone requires an understanding of three languages: HTML for markup, CSS for styling, and JavaScript for functionality. While front-end development has its own complexities, the good news is that development is more or less locked into the “big three” languages. The server side has been a different story altogether. The server has been the domain of languages like Java, PHP, Perl, and just about any other language you can think of. The majority of web applications also utilize a database for data persistence. Historically, communicating with a database has required developers to also understand SQL.

Creating a simple web application requires developers to understand HTML, CSS, JavaScript, SQL, and a server-side language of choice. In addition, there’s no guarantee that the server side will be written in a single language. Optimistically, developers need to understand at least five separate languages to create a simple app, and that’s without considering the data interchange format used for client-server communication. Remember, the x in Ajax stands for XML. Many web applications have recently moved away from XML in favor of the simpler JSON, but this is still another layer that developers must understand.

Although HTML, CSS, and SQL aren’t strictly considered programming languages, they each have their own syntax and quirks that developers must know. Completely understanding five “languages” and constantly context switching between them is a daunting task. If you’ve ever attempted this, you have likely mixed up syntax on more than one occasion.

This has lead to specialization among developers with different teams working on front-end and back-end development. Unfortunately, this doesn’t always ensure that projects are completed faster or with higher quality. In fact, it often results in more back and forth, debates, and programmers who are less knowledgeable about a project’s big picture. There was a very clear-cut need for a language to be used across the entire development stack. The remainder of this chapter explains how JavaScript grew into the role of a full-stack language in a way that no other language could.

The Rise of Full-stack JavaScript

JavaScript has long been the de facto standard for client-side scripting. JavaScript burst onto the scene in 1995 after Brendan Eich developed what was known as Mocha at the time over the course of just ten days. In September 1995, Netscape Navigator 2.0 was released with Mocha, which by then had been renamed LiveScript. JavaScript finally settled into its current name by December 1995. The name was chosen because Netscape was attempting to ride the coattails of Sun’s Java programming language, which was trendy at the time.

During the initial browser wars, Microsoft’s Internet Explorer and Netscape’s Navigator were constantly trying to one-up each other. As a retort to Navigator’s JavaScript, Microsoft released its own implementation, named JScript, with Internet Explorer 3.0 in August 1996. JavaScript was submitted to Ecma International, an international standards organization, in November of 1996 and JavaScript was standardized as ECMA-262 in June 1997.

Earlier on, JavaScript earned a reputation as being a language lacking in performance and only used by amateur developers. Yet browser vendors invested a lot of time, energy, and money into improving JavaScript over the years. The result is that modern JavaScript engines are highly optimized pieces of software whose performance is far beyond anything of the original JavaScript interpreters. On the client-side, it is unlikely that any competing languages (such as Dart) will dethrone JavaScript in the near future, as it's the only language supported by every major browser. Couple that with overall improvements in computing, and the result is a language that is suitable for just about any general-purpose computing task.

Node.js

In 2009, Ryan Dahl created Node.js, a framework used primarily to create scalable network applications. Node.js is built on top of Google’s V8 JavaScript engine (the same one used in Chrome) and Joyent’s libuv, an asynchronous I/O library that abstracts away the underlying platform. Node made JavaScript a viable alternative for server-side programming. Additionally, Node provided a full system JavaScript API that was never really achieved before due to the sandboxed environment that browsers provide. With the advent of Node, JavaScript developers could access the file system, open network sockets, and spawn child processes.

One of Node’s top features is the ability to pack a lot of functionality into a small amount of code. Node flaunts this right on the project’s home page. The code that follows is taken directly from the Node home page, and implements a trivial web server in just six lines:

var http = require('http');http.createServer(function (req, res) {  res.writeHead(200, {'Content-Type': 'text/plain'});  res.end('Hello World\n');}).listen(1337, '127.0.0.1');console.log('Server running at http://127.0.0.1:1337/');

Listing 1-1. A trivial web server written in Node

There’s no need to fully understand the code now, but we’ll provide a quick rundown. The first line requires the http modules, which provide functionality for creating HTTP clients and servers. Next, a server is started that listens on port 1337. When a connection is received, the server responds with the message Hello World. The last line of code simply prints a message to the console in order to let the developer know what's happening.

The Node.js Ecosystem

Node was not the first attempt at a server-side JavaScript implementation, but it has certainly proven to be the most successful by far. One way of gauging a technology’s popularity is by the size of the ecosystem around it. Node has been adopted by huge companies like Walmart, PayPal, LinkedIn, and Microsoft. It has even given rise to completely new companies such as StrongLoop, NodeSource, and npm, Inc.

Perhaps even more impressive than the list of companies using Node is the collection of third-party modules being developed for Node. In the few short years since Node’s creation, over 77,000 third-party modules have been published to npm, Node’s package manager. According to Module Counts, a website that tracks the number of modules in various repositories, the npm registry is growing at a rate of approximately 170 modules per day at the time of writing. The next closest package manager in terms of growth rate is PHP’s Packagist at 73 modules per day. Figure 1.1, taken from Module Counts, illustrates the growth of the Node module system compared to various languages’ package managers. npm has been annotated for your viewing pleasure.

Growth of various package managers

Figure 1.1. Growth of various package managers

With the sheer number of modules available, developers can typically find at least one to solve just about any problem they encounter. (Of course, these modules are in various stages of development, and not all are production ready.) As previously stated, one of Node’s biggest use cases is the development of web servers. So, as you might expect, there are a number of modules that implement web servers. The most popular of these modules is Express, which currently powers more than 26,000 web applications around the world. Based on the Ruby language’s Sinatra framework, Express is self-described as a “fast, unopinionated, minimalist web framework for Node.js.” Express will be explored in detail over the course of several chapters later in this book.

MongoDB

While Node was invading the server space, another movement was gathering pace in the world of databases. For years, the primary method of working with data stores had been to issue SQL queries to relational databases. Yet there’s another type of data store that doesn’t rely on SQL. This class of database, known as NoSQL, doesn’t even use the familiar table structures of relational databases. NoSQL databases store data in a variety of formats, such as documents or key-value pairs, and are less rigid and structured than relational databases. This lack of structure often leads to simpler prototyping and ease of development. NoSQL databases tend to be slightly faster, as there’s no need for them to enforce the rigid table structure of relational databases.

In 2007, a company named 10gen (now MongoDB, Inc.) began working on a NoSQL database that would become a component in a planned platform as a service (PaaS) offering. In 2009, the database known as MongoDB (a play on the word hu mongo us) was open sourced. MongoDB is a document-oriented database that stores information as Binary JSON (BSON) documents. By using a flavor of JSON, Mongo is incredibly simple to read and write objects from JavaScript code. Just as Node replaces another server-side language with JavaScript, MongoDB replaces SQL with queries based on JavaScript objects.

AngularJS

While JavaScript has always been a client-side programming language, its use in the browser has changed drastically over time. Back in the Netscape Navigator days, JavaScript was used for very simple page interactions. Use cases consisted of tasks such as changing an image’s src attribute on mouse over or powering collapsible menus. The effects were simple, but provided a level of interactivity unable to be achieved with HTML alone.

As technology continued to evolve, JavaScript evolved with it. A major breakthrough for web applications came with the widespread availability and adoption of high-speed Internet. This opened the door for Ajax applications that make background requests instead of full page loads. Network performance is key in Ajax applications, as a slow connection will make the page appear unresponsive. Applications gradually transitioned towards fewer and fewer page loads, and more Ajax requests. Eventually, the Single Page Application (SPA) was born. In the strictest sense SPAs have just a single page load, and request all other data via Ajax calls.

AngularJS is one of most popular frameworks for creating SPAs. Angular was created in 2009 (a busy year for JavaScript) by Miško Hevery and Adam Abrons. Angular owes much of its popularity to being backed by Google, Hevery’s employer. It applies a model-view-controller (MVC) approach to web applications, and has several noteworthy features. First, Angular provides two-way data binding between views and models. This saves developer time, as Angular automatically keeps everything in sync. Another interesting feature of Angular is that many tasks, including templating, can be done in augmented HTML.

Angular will be covered in greater detail later in the book, but it’s worth looking at a partial example now to illustrate how powerful it really is. Here’s an Angular controller named PeopleCtrl that sets the people property in the data model:

app.controller('PeopleCtrl', ['$scope', function($scope) {  $scope.people = [    {      firstName: 'Colin',      lastName: 'Ihrig'    },    {      firstName: 'Adam',      lastName: 'Bretz'    }  ];}]);

Listing 1-2. A simple Angular controller that manipulates a model

The people property of the model is an array containing two simple objects representing people. Now here’s an Angular view template that can be used to display the model data:

<div ng-repeat="person in people">  {{person.lastName}}, {{person.firstName}}</div>

Listing 1-3. A simple Angular view template

The <div> is just a standard HTML <div> element, while ng-repeat is known as an Angular directive. This particular directive is employed to loop over the elements of an array, and the double curly braces are used to access data from JavaScript. For now, there’s no need to completely understand what’s going on here, just realize that Angular takes care of a lot of tasks for you out of the box.

Summary

This chapter has introduced the concept of full-stack JavaScript, as well as some of its most popular constituents. Using the technologies described here, it is possible to create a production grade application using HTML, CSS, and JavaScript alone. The combination of MongoDB, Express, AngularJS, and Node.js has become so popular that it has earned its own title: the MEAN stack, whose logo can be seen in Figure 1.2. This titling borrows from the LAMP stack, which consists of Linux, Apache (web server), MySQL, and PHP.

The MEAN stack logo

Figure 1.2. The MEAN stack logo

The rest of this book explores the MEAN stack in detail. We’ll begin by covering Node.js, as it will lay the groundwork for all our server-side work. We’ll learn how to make Node run on your local machine as well as download modules using npm. The key aspects of the Node.js programming model will also be covered.

From there, we’ll move on to MongoDB. We’ll learn how to interact with Mongo from a Node application, as well as how to create, retrieve, update, and delete data from a Mongo store. In covering Mongo, we’ll also learn how to access a MySQL database from Node.js. While not technically inline with the MEAN approach, relational databases are too popular to simply not acknowledge.

After gaining a solid grasp on Node and Mongo, we’ll move on to the Express web server. We’ll cover the basics of Express applications via topics such as routes and middleware. Building on previous chapters, we’ll cover the integration of Node, Mongo, and Express. We’ll also introduce hapi.js, an alternative to Express. hapi is an up-and-coming framework developed and battle-tested at Walmart.

Our coverage of the MEAN stack will wrap up with several chapters on AngularJS. These chapters will cover Angular fundamentals such as data binding, directives, controllers, routing, and services.

Full-stack JavaScript is not fully encompassed by the MEAN stack. There is an entire ecosystem of JavaScript tools to learn about, and this book will introduce a few of them. We’ll cover task runners Gulp and Grunt, which are extremely useful for automating mundane, repetitive tasks. We’ll also address JSHint, a linting tool used to improve code quality. Linting tools analyze source code and report potentials issues, a feature that’s especially useful in non-compiled languages such as JavaScript.

We’ll conclude our exploration of the JavaScript tool ecosystem with discussions on Node Inspector and Mocha. Node.js comes with a built-in debugger that is anything but user-friendly. Node Inspector addresses this shortcoming by allowing Google Chrome’s developer tools to act as a front end to Node’s built-in debugger. Mocha, on the other hand, is a Node.js-based testing framework. We’ll show you how to create and run individual tests and test suites.

If this sounds like a lot of material, you’re right. And if you think it’d make a lot more sense with concrete examples, you’d be right again. Throughout the various chapters, we’ll provide many standalone code samples that you can try out. Yet we’ll also be developing a comprehensive example application along the way. The example app is a human resources (HR) application that can be used for tracking employees and teams in a small- to medium-sized company. This app will be developed over certain chapters sprinkled throughout the book.

It’s worth pointing out that there are several MEAN stack boilerplates in existence, but this book doesn’t use any of them. We feel that it’s better to understand all the technologies independently rather than expect all applications to follow a single format. Once you understand the basics of technology, picking up one of the boilerplates should be a piece of cake.

Community Questions