Great news! It’s something really necessary. I need to get a better understanding of how to make things right the first time in a Meteor app. During these months I went through massive refactoring of my project’s modules more than once. In many cases I thought I fully grasped how Meteor’s components work together, but every time I had to go back to google keep looking for new answers.
IMHO Meteor can be really helpful for small projects, but it can become challenging to use if things get more complex. A guide with patterns and best practices from the community, driven by MDG is what we need.
Happy to help.
From my point of view there is so much stuff mentioned there that I have no idea what it is even about. Which is a good thing. Hopefully this will also be suitable for beginners to give introductions to those topics rather than just giving an overview from the perspective of developers who already dealt with similar concepts! Thanks
I feel like there is a wide variety of information already on the internet for absolute beginners - tutorials, example apps, etc - and most of what I’ve heard is that there aren’t any good intermediate-level resources.
So this isn’t about building your first or second app, and it’s not a resource for super hackers; it’s for someone who has messed around with Meteor for a few days and wants to learn how to do things “right”.
Although we’ll still try to make the content as approachable as possible, and organize so that you get started reading the introductory bits without much knowledge.
I’d start off by asking @arunoda if he’d be willing to sign off his rights to bulletproof meteor and meteor explained literature over to MDG in a deal possibly including a sponsored by kadira link.
That would be a great kickstart to an awesome meteor library.
Also, a curated import from meteorpedia and @awatson1978’s cookbook along with some articles from prominent meteor bloggers getting 301-moved over here and we get a perfect picture of what we already have and what else we need.
Fragmentation (Android, anyone?) is a two-edged sword. Personally, I prefer sticking with the canonical, or in-the-box, approaches wherever possible (Blaze, MongoDB, etc.) To each his or her own, of course.
One of the most important things we need for a good guide that “feels right” is a consistent vision and style. That probably means rewriting and adapting a lot of the content, but it sure is a great starting point. And I think it would make a ton of sense to link to other resources especially if we drew from them in the creation process.
These are going to be extremely valuable resources while we are building this thing, and we should definitely link back where it’s appropriate.
I think this is going to be the biggest thing for the new effort - I think we’ll need a large amount of editorial effort to make something that people can really agree and build on.
Challenges
That’s probably one of the biggest benefits an official guide can bring to the table. My hope is to create a company culture here at Meteor and for contributions in general that if you haven’t updated the guide for it, it’s not done.
I think we are working on this - and it would be great if the guide contained some tasteful diagrams to explain core concepts and mental models.
My plan currently is to model it exactly after the prior art: Rails guides, Django, Laravel, etc. Let’s start with catching up to the state of the art, and we can think about how to surpass it later.
I’m not sure anyone really really follows “MVC” in the strictest sense, and I’m not sure it’s even a good idea. An app isn’t a video driver, nor is it a code snippet from The Art of Computer Programming. I think the React community has shown that there is still a lot to learn in the space of application architecture. While we shouldn’t adopt trendy stuff wholesale, it does make sense to take a look at the new tools we have available and think about how they can be best used to result in maintainable, testable, and reusable code. Perhaps the boundaries aren’t where we think they are.
Hey @sashko, many people often come to me when they have some CPU/load issues and turns out that most of the time is about publishing to much, doing sync stuff on publication or using observeChanges on big collections.
I think it would be nice to have a topic on this
This is fabulous! I had stepped back from doing work on my Meteor app due to other life intrusions, but have continued to follow developments. With all the changes since 1.0, this has me excited again to dive back in and develop a new app that I’ve been thinking about and I’m not brand new to Meteor, the Guide looks like a great idea. I love the approach you’re taking in both the charter and the outlines. Thanks loads!
I think each guide page/topic should have an open list of suggested technologies where anyone can submit a link to their package. And then community can upvote those submitted links. And once a link gets to the top, it gets covered in a guide.
I have the issue that this guide might create an echo chamber which would hide new players on the street. So it would be great for them to be able to submit the package and then early adopters could try them, vote for them, and motivate others to try them as well and so on.
So without a clear way how to deal with changing ecosystem guide will soon be full of old dinosaurs and maybe even not maintained one. (This for example happened to Discover Meteor in some aspects.) And then new people think Meteor has some shortcoming just because they are using a year old unmaintaned package (which was very popular at the time).
I think that’s kind of the point. Keep in mind that this resource is squarely for people who don’t want to play with the newest technology and put together their own stack from the freshest new packages. People who are into that sort of thing will always be seeking out new stuff, and they will be the early adopters that can tell if something good is coming on.
But even so the plan should include having a set of links as part of each article to other options for doing similar stuff. For example, the Router page will hopefully also have a link at the end reminding people the Iron Router is out there as a second option, in addition to React Router and Angular’s UI router.
Let’s cross this bridge when we get there. If something starts feeling outdated in a few months, I’d expect people will open an issue on the repository and we can talk about it. If it turns out we need a process for this, we should figure one out when it’s clear what the issues are rather than trying to hit the target from a mile away.
In the meantime, let’s not forget about the benefits of relative stability - I wonder if there can be an effect where the maintainers of packages that are being officially recommended are more motivated to keep their packages fresh.
I was referring exactly to that. I know how to code an app with meteor. I just don’t know what I could be doing better. From a “non-coder’s” point of view of coding (designer who gets as much done as necessary) those best practices and common paradigms would be nice to see reflected in the guide to learn more about those things.
Those values seem to be quite different when you say things like:
It’s been some years since I read his books, but I can’t remember Donald saying anything about how a video driver is related to an architectural pattern like MVC, or anything about any of these 2. Would have been quite visionary of him.
Thanks. I’m not overly worried about the linkbacks. The version of the Meteor Cookbook that I’m curating is moving towards being documentation for the Clinical track, and is scheduled to get a huge housecleaning in Q1 of next year. A third of it is currently getting moved into packages; and another third will get rewritten to be release specific. So if people want to cannibalize the Cookbook, feel free. Now’s the time to do so.
Mostly, I want to share that much of it’s organization is based on real-world feedback from the NY Meteor Meetups. Take the quickstart for example. Editorially, I’m not sure it sure even be called a quickstart, because what lots of people asked us for was how to diagnose installation problems. So that particular installation script has version checks in it, so an intermediate user can diagnose problems as they do an install and know that they’re accomplishing each step correctly.
There’s a lot of relevant history and knowledge in there that might not be immediately obvious. I’d be more than happy to have a sit down session, and go over what’s worth keeping/migrating, and what’s not. It would help you all move forward with this, while reducing my maintenance load. Just give me a ping. Now that I’m on the west coast; easier to coordinate these kinds of things.
Yup. Glad you’re approaching the effort with realistic expectations. Like I said, I don’t envy you on this. Some of these editorial issues will be super thorny, and need the backing and guidance of the entire MDG (which is one of the reasons my enthusiasm for the project waned; because that feedback loop wasn’t available).
That would be great. Whoever is working on these, please don’t shy away from ‘big picture’ architecture diagrams. Something that shows all the moving pieces for a particular architecture. The following diagram is pretty good for describing a basic Blaze app; but it doesn’t apply to Cordova/Mobile apps; nor does it apply to React based apps. Having these kinds of diagrams will go along way to getting people on the same page about how Meteor is architected; what it does; how it works; etc.
Also, there’s an images directory in the Cookbook. It’s got a grab-bag of different diagrams and illustrations. May be some useful inspiration there.
Cool.
Word. The one thing I learned about MVC while writing the Cookbook is that there is no MVC. It’s an overly simplistic model. If I were to give one piece of editorial advice; I’d recommend scrubbing any reference to MVC and keeping it agnostic to the entire concept. If somebody tries to submit something with the words View, Model, or Controller, scrub it out.
As far as Knuth goes, my comment is equally about the LaTeX typesetting system, and it’s relationship to the CSS subsystem (parts of which happen to be GPU optimized). There’s a large community of server-side programmers and database programmers who simply aren’t familiar with that area of computer science; and don’t understand what’s going on in the CSS rendering pipeline. Or how developers can override/program the “View” using device hardware, browser plugins, client-side stylesheets, and other tools.
I’m curious - why do you need node-inspector, Node, Mongo, and/or NPM to get started writing an app?
I like it! I have the same reaction to a lot of other words. For example, “join” - when people say they want joins it could be one of like 5 different things.
Thanks for giving your perspective on all this. I’m not quite at the place yet where I can incorporate all of it, but it will be super valuable in the future.
