Through lots of discussion, I've found that people are generally opposed to using Meteor for any sort of professional or production work for a number of reasons, which aren't really related to Meteor's usefulness as a tool. Let's spend some time looking at Meteor more closely in regards to these concerns.

Meteor is a JavaScript framework that enables developers to quickly create reactive, highly accessible applications. Drupal is a great content management system that makes it really easy to create well-structured content models and interact with data. Why not combine the two and let Drupal provide Meteor with semantic data with Meteor rendering that data in a reactive way?

In this post I'm going to show you how to use the Meteor build system, and how to deploy a Meteor-based application to a Linux environment.

In this post I'm going to show you some techniques for building performant Meteor-based applications. I won't dig into server optimization or JavaScript optimization. Those are two completely different subjects that merit another (much longer) blog post. However in this post I am going to show you how to manage large data sets properly, and give you some basic optimization tips that will help you makes sure your app is quick and useable.

In this post, I'm going to discuss the importance of enforcing a strict and clear coding standard in your Meteor applications, and then provide you with some tools that will make the process easy.

In this post, I will discuss the importance of implementing proper structure patterns in Meteor applications, and give some advice that may help you organize your codebase.

There's been a lot of talk recently about a new JavaScript framework called Meteor, especially since the project just reached version 1.0. I’ve had the opportunity to build several Meteor applications using the beta, all of which are now running in a production environment. Through these experiences I’ve learned a lot about about how Meteor works, so I thought I'd share some of my knowledge.