Interviewing Meteor.js core developer Sashko Stubailo on the Meteor Guide

Robert: You’re working on a new project called the Meteor Guide. What is it?

Sashko: The guide is going to be a series of roughly 15 articles, with each one representing a particular aspect of building an app in Meteor. I’m currently working on it with Tom Coleman, who recently joined Meteor, and is one of the authors of Discover Meteor. We’re also trying something pretty cool with this project, which is that we are going to develop it completely in the open on GitHub from start to finish. The goal is that everyone can be informed about the process if they are interested, and nobody will be surprised by the content when it is officially released. Let’s talk a little more about content — to give two examples of articles we might write, there will be one about forms, user input, and validation, and also one about how to build out the user account functionality of your app. The idea is to focus on what people are trying to accomplish using Meteor, and explain the most common tasks in those topics in readable terms. So it’s not really a getting started tutorial, and it’s also not an advanced, cutting edge resource, but more of a record of best practices. I’m very impressed with the Rails Guides, so that would be a good template to look at to see where we want to end up.

Robert: Why did you want to do this guide?

Sashko: Well, one reason is that there are so many places where information about Meteor is hidden. You have docs.meteor.com, of course, but you also have wiki articles, package readmes, blog posts, and lots of other things in different places. I want to make a place where the information is organized by what you’re trying to do, not by technology type or where someone happened to publish it. You don’t start with “I really want to use a Meteor method on this.” You start with something like “I want to add a form to my app, and I want it to have validation.” Topics like this can get complicated. For validation, you might need live validation while the user is typing, another kind of validation when they submit, and yet another on the server. Developers should know about all of the tools they need to create a great app experience, but right now there isn’t one place to find this information. Another factor is that I don’t think Meteor has done a great job of promoting community packages. The Meteor documentation shouldn’t just include packages that MDG has written. It should include all the things you need to actually build an app. Meteor isn’t a complete framework without all of the community packages out there. We need a place to document not just Meteor itself, but also the larger world of proven packages that a lot of people are using.

Robert: A developer I respect said that Meteor is great for beginners, and it’s great for people who are really advanced, but people who are intermediate or who are just getting beyond the basic demos of Meteor are finding a big gap where there really isn’t much practical advice available.

Sashko: Yeah, and that’s exactly what the Meteor Guide is for. It’s not for a person who’s trying Meteor for the first time, and it’s not for someone like Arunoda, because he could probably write all of it himself! It’s for people in the middle who are like, “Okay, I did the tutorial. Now what?” One option has been to buy a book like Discover Meteor, but you might not want to necessarily do the whole book in sequence. It takes quite a lot time to do that. I’m personally not a fan of just reading books start to finish. The other thing is it costs money. You shouldn’t have to pay somebody to learn the basics of how you are supposed to use Meteor.

Robert: Discover Meteor has really nice flow in terms of building an app and takes you most of the things you need to know. Personally, I haven’t found it as good from a reference standpoint. I don’t go back to it to learn how to do subscriptions because the subscriptions are in the context of the app.

Sashko: Yeah, and the book context also forces the author to fit all of the content in to some master narrative. The guide will not have those restrictions. If there’s some content about subscriptions that we didn’t put in, we can just add another section at the bottom. It’s very flexible.

Robert: So what’s your plan in terms of building it out, and how do you see the role of MDG and the community? How can people contribute to this?

Sashko: I think right now we’re somewhere in the stage of discussing the initial ideas and outline of the content. I think that it’s important to start with what content people will need — and not what content is easy to write — because some of the points in the outline we have created are super hard to answer. That’s good, because it will identify gaps where we should be providing help.

Robert: You’re actually driving forward the discussion about what the holes are in the Meteor ecosystem, or at least peoples’ knowledge of Meteor.

Sashko: That’s right. If there’s a bullet point in our outline, and there’s not actually a good way to write that code, that sounds like a gap which somebody needs to fill, whether it’s MDG or a community member. Or maybe, now that that gap is obvious, somebody can write a package for it. There has never been a catalog of these gaps. Sure, there are a bunch of issues and feature requests in the Meteor repo, but it’s hard to prioritize them against what people actually need, so hopefully this can be a step in the right direction.

Robert: Yeah. That’s interesting, actually. Someone with ambitions to grow in the Meteor community could actually look for holes, places in the guide that where there is no solution or not a really good solution, and they could actually target that as something to either build a product around or get their hands dirty in the Meteor ecosystem.

Sashko: Right. Any of the guide articles or even bullet points could be its own tutorial. We’re probably not going to go super in-depth, at least in the first version, on every topic. We’re just going to be like, “Here’s an opinion. Here are a few code samples. Hopefully you can figure out how to apply that to other stuff.” Somebody could go there and be like, “Okay, I think this is a little confusing,” and write a whole 10 step tutorial about just that one thing. We can link to it. That would be awesome.

Robert: Yeah. Anything else we should try to cover? Things that we should say, that we want people to know about this?

Sashko: So if people want to read more in depth about the plans for the project, join the discussions about different topics, or contribute by starting new conversations, the place to go would be meteor/guide on GitHub. On there we have an article progress board, a charter that outlines the vision and goals for the project, some short term plans, and a lot of great conversations in the issues.


Author: Robert Dickert, Community Engineer Meteor Development Group

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.