Building Single-page Web Apps with Meteor

Meteor is not just a JavaScript library such as jQuery or AngularJS. It's a full-stack solution that contain frontend libraries, a Node.js-based server, and a command-line tool. All this together lets us write large-scale web applications in JavaScript, on both the server and client, using a consistent API.

Even with Meteor being quite young, already a few companies such as https://lookback.io, https://respond.ly, and https://madeye.io use Meteor in their production environment.

If you want to see for yourself what's made with Meteor, take a look at http://madewith.meteor.com.

Meteor makes it easy for us to build web applications quickly and takes care of the boring processes such as file linking, minifying, and concatenating of files.

Here are a few highlights of what is possible with Meteor:

With Meteor, we never have to link files with the <script> tags in HTML. Meteor's command-line tool automatically collects JavaScript or CSS files in our application's folder and links them in the index.html file, which is served to clients on initial page load. This makes structuring our code in separate files as easy as creating them.

Meteor's command-line tool also watches all files inside our application's folder for changes and rebuilds them on the fly when they change.

Additionally, it starts a Meteor server that serves the app's files to the clients. When a file changes, Meteor reloads the site of every client while preserving its state. This is called a hot code reload.

In production, the build process also concatenates and minifies our CSS and JavaScript files.

By simply adding the less and coffee core packages, we can even write all styles in LESS and code in CoffeeScript with no extra effort.

The command-line tool is also the tool for deploying and bundling our app so that we can run it on a remote server.

Sounds awesome? Let's take a look at what's needed to use Meteor.

Meteor is not just a JavaScript framework and server. As we saw earlier, it is also a command-line tool that has a whole build process for us in place.

Currently, the operating systems that are officially supported are as follows:

This book and all examples use Meteor 1.0.

Installing Meteor is as easy as running the following command in the terminal:

$ curl https://install.meteor.com/ | sh

That's it! This will install the Meteor command-line tool ($ meteor), the Meteor server, MongoDB database, and the Meteor core packages (libraries).

$ git

To create our first app, we open the terminal, go to the folder where we want to create our new project, and enter the following commands:

$ cd my/developer/folder
$ meteor create my-meteor-blog

Meteor will now create a folder named my-meteor-blog. The HTML, CSS, and JavaScript files that Meteor created for us inside this folder are already a fully working Meteor app. To see it in action, run the following commands:

$ cd my-meteor-blog
$ meteor

Meteor will now start a local server for us on port 3000. Now, we can open our web browser and navigate to http://localhost:3000. We will see the app running.

This app doesn't do much, except showing a simple reactive example. If you click on the Click Me button, it will increase the counter:

For later examples, we will need Google Chrome's developer tools. To open the console, we can press Alt + command + I on Mac OS X or click on the menu button on the upper-right corner of Chrome, select More tools, and then Developer tools.

The Developer tools allow us to inspect the DOM and CSS of our website, as well as having a console where we can interact with our website's JavaScript.

- my-meteor-blog
  - server
  - client
    - styles
    - templates

Packages in Meteor are libraries that can be added to our projects. The nice thing about Meteor packages is that they are self-contained units, which run out of the box. They mostly add either some templating functionality or provide extra objects in the global namespace of our project.

Packages can also add features to Meteor's build process such as the stylus package, which lets us write our app's style files with the stylus preprocessor syntax.

For our blog, we will need two packages at first:

less: This is a Meteor core package and will compile our style files on the fly to CSS

jeeeyul:moment-with-langs: This is a third-party library for date parsing and formatting

$ meteor add less

$ meteor add jeeeyul:moment-with-langs

$ meteor add jeeeyul:moment-with-langs@=2.8.2

$ meteor add jeeeyul:moment-with-langs@1.0.0

$ meteor update –-packages-only

$ meteor update jeeeyul:moment-with-langs

To understand Meteor's build process and its folder conventions, we need to take a quick look at variable scopes.

Meteor wraps every code files in an anonymous function before serving it. Therefore, declaring a variable with the var keyword will make it only available in that file's scope, which means these variables can't be accessed in any other file of your app. However, when we declare a variable without this keyword, we make it a globally available variable, which means it can be accessed from any file in our app. To understand this, we can take a look at the following example:

// The following files content
var myLocalVariable = 'test';
myGlobalVariable = 'test';

After Meteor's build process, the preceding lines of code will be as follows:

(function(){
  var myLocalVariable = 'test';
  myGlobalVariable = 'test';
})();

This way, the variable created with var is a local variable of the anonymous function, while the other one can be accessed globally, as it could be created somewhere else before.

Though Meteor doesn't impose restrictions concerning our folder names or structure, there are naming conventions that help Meteor's build process to determine the order in which the files need to be loaded.

The following table describes the folder and their specific loading order:

The following table describes filenames that have created a specific loading order:

So, we see that Meteor gathers all files except the ones inside public, private, and tests.

Additionally, files are always loaded in the alphabetical order, and files in subfolders are loaded before the ones in parent folders.

If we have files outside the client or server folder and want to determine where the code should be executed, we can use the following variables:

if(Meteor.isClient) {
  // Some code executed on the client
}

if(Meteor.isServer) {
  // Some code executed on the server. 
}

We also see that code inside a main.* file is loaded last. To make sure a specific code only loads when all files are loaded and the DOM on the client is ready, we can use the Meteor's startup() function:

Meteor.startup(function(){
  /*
  This code runs on the client when the DOM is ready,
  and on the server when the server process is finished starting.
  */
});

Assets.getText(assetPath, [asyncCallback]);
// or
Assets.getBinary(assetPath, [asyncCallback])

// Synchronously
var myData = Assets.getText('data.txt');

// Or asynchronously
Assets.getText('data.txt', function(error, result){
  // Do somthing with the result.
  // If the error parameter is not NULL, something went wrong
});

Now that we know already about Meteor's build process and folder structure, we will take a closer look at what we can do with the command-line tool that Meteor provides.

As we saw when using the meteor command, we need to be inside a Meteor project so that all actions will be performed on this project. For example, when we run meteor add xxx, we add a package to the project where we are currently in.

$ meteor update

$ meteor update –-release 0.9.1

$ meteor deploy my-app-name

In this chapter, we learned what Meteor requires to run, how to create a Meteor application, and how the build process works.

We understand that Meteor's folder structure is rather flexible, but that there are special folders such as the client, server, and lib folder, which are loaded in different places and order. We also saw how to add packages and how to use the Meteor command-line tool.

If you want to dig deeper into what we've learned so far, take a look at the following parts of the Meteor documentation:

You can find this chapter's code examples at https://www.packtpub.com/books/content/support/17713 or on GitHub at https://github.com/frozeman/book-building-single-page-web-apps-with-meteor/tree/chapter1.

Now that we've set up our project's basic folder structure, we are ready to start with the fun part of Meteor—templates.