📚 Check out the Meteor Guide

Hi Forums!

I know not all of you regularly visit meteor.com, read the Meteor blog, or watch videos from Devshop and Meteor night, so you might not be aware of the Meteor Guide.

The Meteor Guide is about having a stable and opinionated set of guidelines about how to build your Meteor app. It is careful about making specific recommendations for almost all parts of your application, so you don’t have to worry about keeping up to date with every new development in the Meteor ecosystem.

Also, it is written by us, the maintainers of the Meteor platform, with a keen eye for the future and transition paths to future Meteor releases, and will be quickly updated for every Meteor release. For example, in Meteor 1.3 we will have suggestions about how to restructure your application with modules.

If you have a question about how to structure or manage part of your app, there’s a good chance it’s answered in the Guide. Here are the articles included today:

This post was created to live as a sticky, as several community members have suggested that it will be helpful for people to see it there. Hope you enjoy reading the guide as much as we enjoyed writing it!


Do you still suggest of using Blaze?

and for the Performance issues?

1 Like

Yes, we suggest that people use Blaze today because there are so many useful tools and packages built for Meteor and Blaze together. We are working on bringing React and Angular 2 up to par in that regard, but that will take some time, and either way Blaze works quite well for a lot of people today.

If you would like to talk about performance, I’d suggest opening a new thread about it.


I’m still very much looking forward to the SEO section of the guide :slight_smile: !

1 Like

It’s there under deployment! It’s quite simple, you can just use prerender.

How about testing section in guide? Any ideas of timeline when you’ll have it?

The idea is to have testing for Meteor 1.3. We’re actually developing official testing support for the new release alongside the guide article, to make sure that it works for all of the common testing needs.


Will it be chimp or velocity based?

As you may have heard, Velocity is no longer being maintained, so the plan comes down to:

  1. Chimp for end-to-end tests.
  2. Built-in Meteor 1.3 testing support for unit and integration tests - you can pick a driver, mocha, jasmine, tinytest, whatever - more details on this closer to 1.3 release since this is something we are working on right now. We are going to consult with some production users who have lots of Velocity tests to see if this will work for them!
  3. Your velocity tests will continue to work if you have them, and you can migrate to the new recommendation incrementally.

Will you have snapshot-versions of the guide? For example, once 1.3 drops, will you have a guide to go along with that’s somehow tagged/associated/related/versioned to this release, and so on when 1.4 drops?

This is not to say you couldn’t add to meteor guide 1.3 after the software drops. I think this will help with the changing times. So for example, if I decided to start my transition to React with 1.4, but Meteor is then at 1.6, I could somehow “pull” the guide that goes with 1.4 and not get confused with guide material that’s relevant only to 1.6.

1 Like

Yep, that’s what the drop down is for, which currently lists “1.2”. We can publish any branches we want to be in that drop down, we might also use branches for stuff like translations in the future.

1 Like

can’t wait for the 1.3 guide. BTW, just out of curiosity, will the new guide focus on using npm packages or atmosphere packages as for examples demonstration

The 1.3 React guide will be with React from NPM, but we have taken care to make sure it works with all packages from Atmosphere that depend on the Atmosphere React package.

1 Like

So finally Velocity tests will work with Meteor 1.3.X? That’s some good news! :smiley: It will make the migration much easier indeed.

Hi, I tried to reproduce the chapter that calls a Method from a form and I want to point out there is a small error (pun not indended). Every time I try this code it throws error, the helper cannot get the instance of this.errors.

errors(fieldName) {
return this.errors.get(fieldName);

Here is the code that worked for me. Correct me if I did a mistake.

errors(fieldName) {
return Template.instance().errors.get(fieldName);

You’re right! We should fix that. Could you submit a PR?

@sashko please correct me if I am wrong, if meteor 1.3 no longer put Meteor as global, then using profile field in the user is not as risky as before?

No, those two things are unrelated. One is about what is easily accessible in JavaScript code, the other is about data on the DDP level. Keep in mind that your Meteor app might not be the only thing accessing your server - anyone can connect directly to your app server with DDP and bypass your frontend entirely, which is why all of your security needs to operate at the data and network level, not in the UI code.

1 Like

Thanks for pointing out my ignorance :stuck_out_tongue:@sashko