Warning: this post is old and might not reflect the current state of the art


The term isomorphic identifies a framework where client-side code and server-side code are written in the same language. This implies that any piece of code could run both on the server and on the client, unless it’s tied to a context-specific action.

In the past 10 years Web Applications have been built by clearly separating the server and the client code. Server code run PHP, Ruby, Python code. That code could never work on the frontend-side, because the browser does not support those languages. Modern browsers are only capable of executing code written in JavaScript.

With the meteoric rise of Node.js in the last few years, and what was built on top, now we have the chance to build an entire application in the same language: JavaScript.

Meteor takes the isomorphic concept even further, by transparenly running every file in your project, unless you don’t want it to do it, on both sides of the platform, doing different things based on the context, clearly explained by the Meteor documentation.

This is an amazing opportunity and advantage that Meteor enables by building a “super-platform” on top of Node.js and the Browser platforms, enabling you to build applications faster and better than ever.

Isophormic is a term coined by Charlie Robbins at Nodejitsu. It refers to JavaScript code that runs with little to no modifications on the client and on the server. It’s code that takes care of both what runs inside the browser, and the what runs on the server.

Meteor is an isophormic framework. This is great because we can write concise and tighgly coupled applications that now even share some pieces of code between client and server code.

It enables you to become a Full-Stack developer, because you no longer need to deeply know two separate stacks to work on both sides of the application.

The classical example is the one of an HTTP request. On the browser you’d do an AJAX call. On the server you’d use your stack-specific code. Using Meteor, you can use the same function HTTP.get() provided by the http package. On both sides.


You can write a package that does amazing things just because in a single package you can manage everything.

Meteor calls it an Isopack, the result of an Isobuild.

There are already thousands of Isopacks available for you to use. When installing an Isopack, Meteor installs code that runs on the client AND on the server. And optionally on other platforms too, something we’ll talk about later.

Meteor.isServer, Meteor.isClient

Meteor exposes two boolean variables to determine where the code is running:

  • Meteor.isServer
  • Meteor.isClient

Put them inside an if statement to run some code part just on one side of the platform.

For example:

if (Meteor.isClient) {
    alert('Hello dear user!');
} else if (Meteor.isServer) {
    //running server-side

Special directories

Putting lots of Meteor.isServer and Meteor.isClient checks in the application is not ideal of course.

First, the code can quickly grow complicated and not nice to read. Second, even the server code is sent to the client. This is bad because you’d better keep server-side code private, and also because you send unnecessary code which slows down loading times.

That’s why Meteor has two special folders that automatically take care of the distinction for us: client and server

Whatever you put in the client directory is not loaded on the server side.

Whatever you put in the server directory is not sent to the client.

Another advantage of keeping this distinction is that assets put in the client folders are never taken into consideration during the build phases.