You are here: Home / Blog / A First Look at a Basic Application Created by Meteor

A First Look at a Basic Application Created by Meteor

Posted by Fulvio Casali at Nov 10, 2014 03:10 AM |
Filed under:

After installing Meteor itself, the Meteor tutorial instructs you to create your first application with the following command:

meteor create simple-todos

The result is an application made up of three files (an html template, a javascript file for the application logic, and an empty css file), plus a folder of "internal Meteor files".

After spending a couple of minutes to see how the javascript file is structured and how it ties into the html template, I got curious about the magic that makes it all work.

The .meteor folder

The first level of the "internal Meteor files" folder looks rather harmless, with ids, lists of packages used, etc.  One hint of the submerged portion of the iceberg is given by the versions file, which lists 52 packages or libraries or whatever these things are called in the javascript world.

Initially, that's all you get from running the meteor create simple-todos command.  However, things get more interesting when you start the application:

> cd simple-todos
> meteor

When meteor starts, another folder is created, called local, which in turn contains two more folders, build and db.  This is where things get interesting.  But before diving in, let's see what the application sends to the client.

The client point of view

If you load the application in the browser as instructed by the tutorial and by Meteor itself at the command prompt, by navigating to http://localhost:3000, you can then inspect the resulting page with Firebug or your browser's developer tools.  The resulting html closely mirrors the application template, but don't be fooled!  Do an old-fashioned "view source" instead, and you'll see something rather different:  your browser actually received an html file with a <body> that is completely empty!  The <head> on the other hand, loads something like 40 different javascript resources, plus a dictionary of application constants.

What this means is that the page's entire DOM gets generated on the client by scripts.  Indeed, at the bottom of the list of the 40 javascript files that are loaded we can see something interesting.  The last one, /simple-todos.js, is the same as the one in our project top-level directory, except that before being sent to the client it got wrapped inside a

(function(){ ... })();

The <script> just before that is even more revealing.  It's called template.simple-todos.js, and contains:

(function(){
Template.body.addContent((function() {
  var view = this;
  return [ HTML.Raw("<h1>Welcome to Meteor!</h1>\n\n  "), Spacebars.include(view.lookupTemplate("hello")) ];
}));
Meteor.startup(Template.body.renderToDocument);

Template.__checkName("hello");
Template["hello"] = new Template("Template.hello", (function() {
  var view = this;
  return [ HTML.Raw("<button>Click Me</button>\n  "), HTML.P("You've pressed the button ", Blaze.View(function() {
    return Spacebars.mustache(view.lookup("counter"));
  }), " times.") ];
}));

})();

It's easy to see the correspondence with our html template:

 

<body>
<h1>Welcome to Meteor!</h1>
{{> hello}}
</body>
<template name="hello">
<button>Click Me</button>
<p>You've pressed the button {{counter}} times.</p>
</template>

In other words, our template gets parsed by meteor and compiled into a script, which is sent to the client, and upon execution builds the DOM.

I feel a little uneasy about this.  Granted, a DOM inspector (like Firebug) shows me the rendered html, so it should be debuggable just like in the old days, but what if something goes awry in this whole chain?

 

 

Filed under: