Earlier this week, we released Meteor 0.9.0 and with it the official Meteor package system, including Isobuild and the Meteor Package Server. Today, I want to dig a little deeper. Why does Meteor have its own package system? Why is it growing so rapidly (over 1800 packages today — it seems like just yesterday it was 1000)? What’s wrong with npm, Jam, Bower, Ender? Why the heck do we need another one of these?

Though we’ve covered some of the other benefits before, the main answer is “Isomorphic JavaScript.” A term coined by Charlie Robbins at Nodejitsu and popularized by Spike Brehm of Airbnb, this has come to refer to JavaScript code that can run equally well on the client or on the server, meaning that you can write your JS once and run it anywhere.

Here’s an example. Say you want to access a REST API, to retrieve Facebook friends for example. In the browser, you have to do that with XMLHttpRequest , or a wrapper around it such as jQuery.get() . Under node.js, you could use the core http.request() API or a wrapper such as the request package. Even though the browser code and the server code are both JavaScript, it's not portable, because the APIs are different. You'd have to maintain two different versions of the code for the two environments.

But with Meteor, you can add the http package and use the HTTP.get() function on both the browser and the server. It works everywhere, so now your Facebook friends-fetching code can be used anywhere in your app. That's the idea behind Isomorphic JavaScript. And, packages that other people build on top of your friend-fetching package will also work everywhere. Support for isomorphic APIs in Meteor extends from simple packages like 'http' all the way up to complete isomorphic database bindings, making it possible to run your app's core business and rendering logic on both the client and server.

What enables all of this is Meteor Isobuild, a complete build system for isomorphic distributed systems, whether in JavaScript or other languages. The Isobuild package file format, called isopack, can contain code that targets multiple execution environments, such as a browser and a node.js-based server. Isopack files can contain code that’s shared across environments (portable code) and code that’s specific to just one environment (architecture-specific code). They can even contain architecture-specific binary code.

Isobuild understands how to combine the right bits of code for each target, using the appropriate build pipeline for that target (transpiling, minifying, determining load order, resolving imports and exports, and propagating debugging info such as source maps from one stage to the next). And the build process itself is extensible and programmable, so you can add support for other languages and preprocessors just by linking in an isopack containing a plugin for the appropriate build phase. Plus, Isobuild can work not only with isopacks, but also packages from other package systems such as npm.

With over 1800 isopacks now available on the Meteor Package Server (and growing exponentially), Isobuild is here to stay. And Meteor provides some great tooling around Isobuild, including a full optimizing constraint solver to assist with release engineering, a package librarian that incrementally syncs the package catalog from the server for local use, and a distribution management system that lets you pin your project to premade groups of package versions that have been tested together (such as an official Meteor release) — all firsts for the JavaScript ecosystem.

But now I’m really going to blow your mind — and give you a hint about a little surprise that we have planned for 1.0. Isobuild can target mobile apps too. With Isobuild and Cordova, you’ll be able to add a camera package to your app and use one simple Camera.takePicture() API to take a photo, and then type one command to build your app not just for the browser, but for the iOS and Android app stores too. You just might be able to find a recording of a recent Devshop talk that shows a sneak peek of this unreleased functionality.

See where this is all going? Hope you’re getting psyched up for Meteor 1.0, and don’t forget to star Meteor on Github!

ps. Want to work on cool projects like Isobuild? We’re hiring core developers, San Francisco or remote.