The recent discussion on the MDG Tracking Package got me thinking about packages which are Opt-Out.
What is the first thing you do when you start a new project? For me it is to run the command meteor remove autopublish insecure. I’m pretty certain this is the same for the vast majority of developers who aren’t just playing around, or having a look at a new technology.
To that end, I am creating this topic to open up discussion on, and petition for, the removal of the packages autopublish and insecure from a new project.
I feel that this is a necessary step forwards for the Meteor platform as these packages face similar issues to the new census package. These two packages provide a useful function for demonstrating the power of Meteor, but I feel that a developer should have to explicitly add them to a Meteor project.
The vast majority of applications which will go anywhere past a demonstration to someone will have these eventually removed, and any new project by a developer with some experience will have these immediately removed. Having to manually remove these is adding an extra step (albeit a very small one) each time a project is created.
I propose that the meteor commandline tool have a new example project created which skeletons with this, i.e. meteor create --example demo, which has a message telling you about the inclusion of autopublish and insecure, what they do, and the risks of having them in your project.
I totally back it up. Like I wrote in another topic:
I notice new Meteor developers not wanting to learn how to do proper publications and subscriptions, because it adds complexity to their applications, even when they start to write their real life app.
Then, they suddenly have many collections and different finds() and findOnes() in their application without optimizing it for publications, so it becomes difficult for them to refactor this code to use subscriptions, because they have to deal with complex use cases from the beginning instead of simple ones, like in official tutorial.
And let’s face it, sadly many new developers don’t go through this tutorial or stop in the middle and jump straight into writing their code.
I believe the census package, for MDG’s usage, as well autopublish and insecure should be auto-included if the project is explicitly being generated as an example or prototype with a meteor create --example demo or meteor create --prototype demo command, but the experienced developer, and the silent majority, as @sashko had referred to, typically remove these packages as the first thing they do after creating a new project.
As far as rapid prototyping, if you use the protoype flag, you’re explicitly indicating you want to build something quickly and include all of the default scaffolding, packages, etc. Making this explicit rather than implied is a step toward clarity as well as sensible defaults for the other instances, the ones where you’re creating a new project and not explicitly marking it as a prototype.
Couldn’t agree more! The tutorial can just add them at the beginning to maintain the same learning curve.
To elaborate, I think these are artifacts of a time when Meteor was optimized for flashy demo videos, I think now it’s more important to point people towards best practices, even if it is a tiny bit more code to write.
@tmeasday could/should this be part of updating the skeleton app to match the guide?
We turned this over a few times (not specifically about insecure and autopublish, more about whether to have a large and boilerplate-y “realistic” meteor create) recently, and decided that instead we’d create a boilerplate example.
So sort of the inverse of what’s proposed here — if you want to do a demo / tutorial / repro / etc, you meteor create. If you want to create a real project, you use the boilerplate.
Thing is, it’s way more common to do the first than the second (how often do you start a serious project—kind of by definition not that often); and the best boilerplate is a moving target, which means it’s best outside of the tool.
Thanks for your input, @sashko, @tmeasday - It’s nice to get a quick and direct response from you guys.
I can understand your response, @tmeasday, but I do disagree with it being best outside the tool. How about adding a meteor boilerplate <name> command? I think that would be a very welcome addition to the command line client. Off the top of my head, here are a few considerations:
Have a publicly viewable repository or listing for the source code for each boilerplate
Have some MDG created basics, i.e. some skeletons for using a package only approach, importing a particular, common node package
Have a user submitted boilerplates available, or a way of specifying a git URL so people can build their own boilerplates (this should also be able to use SSH, as I can see some companies wanting to create private boilerplate for their projects)
Providing this allows Meteor to bring in a central location for users to look for boiler plate code, it can have a like and comment system so that more common boilerplates can rise to the top and be discussed. It would be great to have an indexed library, so people could search for a boilerplate which includes a particular package, for example.
That’s definitely a fair point, but the Guide/Todos app will be demonstrating a particular methodology/boilerplate, and they are hopefully going to be updated pretty often to stay up to date to current best practice, so could there be a meteor --boilerplate type of command that spins up a project based on the Guide’s recommendations?
Having said that though, as soon as you start talking about boilerplate you immediately get into thinking about React, React/Redux, Angular 2 etc., all of which are arguably even more in need of boilerplate due to the extra moving parts and then I quickly see your point about boilerplate being best outside of the tool.