Meteor should bring back the "Principles of Meteor" to its official docs



I found that with the transition to the new documentation system the “Background” and “Principles of Meteor” sections of the original docs were removed.

I believe that an aesthetical statement, such as the one embraced by Python in its PEP 20 aka “The Zen of Python”, is what makes a technology great, as it sets a consistent tone and mission that aligns all the communities involved.

Please consider bringing it back. Checking Meteor for the first time few years ago, it was enough for me to read these sections to know this is a technology really worth checking.


The web was originally designed to work in the same way that mainframes worked in the 70s. The application server rendered a screen and sent it over the network to a dumb terminal. Whenever the user did anything, that server rerendered a whole new screen. This model served the Web well for over a decade. It gave rise to LAMP, Rails, Django, PHP.

But the best teams, with the biggest budgets and the longest schedules, now build applications in JavaScript that run on the client. These apps have stellar interfaces. They don’t reload pages. They are reactive: changes from any client immediately appear on everyone’s screen.

They’ve built them the hard way. Meteor makes it an order of magnitude simpler, and a lot more fun. You can build a complete application in a weekend, or a sufficiently caffeinated hackathon. No longer do you need to provision server resources, or deploy API endpoints in the cloud, or manage a database, or wrangle an ORM > layer, or swap back and forth between JavaScript and Ruby, or broadcast data invalidations to clients.

Principles of Meteor

  • Data on the Wire. Meteor doesn’t send HTML over the network. The server sends data and lets the client render it.
  • One Language. Meteor lets you write both the client and the server parts of your application in JavaScript.
  • Database Everywhere. You can use the same methods to access your database from the client or the server.
  • Latency Compensation. On the client, Meteor prefetches data and simulates models to make it look like server method calls return instantly.
  • Full Stack Reactivity. In Meteor, realtime is the default. All layers, from database to template, update themselves automatically when necessary.
  • Embrace the Ecosystem. Meteor is open source and integrates with existing open source tools and frameworks.
  • Simplicity Equals Productivity. The best way to make something seem simple is to have it actually be simple. Meteor’s main functionality has clean, classically beautiful APIs.



This is the new version:

  • Meteor allows you to develop in one language, JavaScript, in all environments: application server, web browser, and mobile device.
  • Meteor uses data on the wire, meaning the server sends data, not HTML, and the client renders it.
  • Meteor embraces the ecosystem, bringing the best parts of the extremely active JavaScript community to you in a careful and considered way.
  • Meteor provides full stack reactivity, allowing your UI to seamlessly reflect the true state of the world with minimal development effort.

We decided to slim it down, and here’s why:

  1. “Database Everywhere” turned out to not be a good idea. Inside MDG, and in some community resources, people decided it’s better to send modifications to data via methods with arguments, rather than insert and update directly in UI code.
  2. “Latency Compensation” this is more of a feature than a principle - Meteor still has it today but it didn’t really seem to fit with the others.
  3. “Simplicity Equals Productivity” turned out to not be true. Meteor ended up being very complex internally to enable the external simplicity, and this dissonance led to a lot of problems, especially making it hard for people in the community to make meaningful contributions.

As for the preamble, it’s no longer relevant. In today’s world, with technologies like React/Redux, anyone can build a client-side rendered app that feels fast, even without Meteor. This is no longer a unique selling point, so it seems odd to include it in the introduction.

But I’d be open to adding back a bit of flavor to the Guide intro, if someone has some ideas.


It’s like you’re reading my mind about the external simplicity and internal struggle to maintain that. A slippery slope to be sure!


This though, don’t stray from it!


My alternative five principles are here: