General feedback on pre-production development from a Meteor newbie

community
1

I don’t really know what to say, but I feel disappointed and I need to vent. Just to say I love Meteor, and everything MDG are doing… but things are a little worrying lately.

Over the last 3 months I’ve been trying to start a business. As an independent developer with no money and small business goals I’ve chosen Meteor as the platform for that business. I’m not the best with javascript, but I understand patterns and web apps and i’m a quick study, working in application development for about 8 years now.

Until the last few weeks, I’ve had a great experience learning and working with Meteor. Figuring out things for myself and really getting stuck in. I’m about to start testing with around 100 users.

But since the recent updates and changes around 1.3… I believe if I was starting developer right now, seeing the 1.3 Meteor Guide and Docs, along with the current example apps and the fragmented nature of the Documentation and support articles - I would just give up on Meteor.

Example apps used to be straightforward and much more intuitive. This file in the current TODOS example…
https://github.com/meteor/todos/blob/master/npm-shrinkwrap.json

is indicative of the overcomplexity which would now send me running for the hills.

If you search for “Meteor js example apps” in google this is the page google returns… https://www.meteor.com/examples.

Things are hard enough for developers… Please be nicer to users and redirect these old links to appropriate new pages.

Here’s a another use case for you.

I’ve been trying to find a useful reference in the Meteor Documentation or Guide or anywhere to allow me to define a Collection of data which will only show the data belonging to the current user. A pretty simple pattern right?
You know… a Collection that isn’t shared with the world… just retrieving data by UserID… what would you search for to find such information? I dare you to try it!

Here’s where I started…

http://docs.meteor.com/#/full/meteor_publish and http://guide.meteor.com/data-loading.html#readiness

No help. I’m just blown away by the level of complexity of language.

You folks can priorities however you want. I know. Who am I to complain? But I feel you are going to alienate new developers and entrepreneurs by increasing the barrier to entry to Meteor. If you are okay with this… I think that’s a shame as I feel the BEST facet of Meteor in the past has been on making things easier for developers from an implementation perspective… to help reaching validation quickly… instead of improving the situation for developers from a commercial or production perspective.

Here is a sample from the Guide called “Patterns for Data Loading”…

"Across Meteor applications, there are some common patterns of data loading and management on the client side that are worth knowing. We’ll go into more detail about some of these in the UI/UX Article.

:link:Subscription readiness

It is key to understand that a subscription will not instantly provide its data. There will be a latency between subscribing to the data on the client and it arriving from the publication on the server. You should also be aware that this delay may be a lot longer for your users in production that for you locally in development!

Although the Tracker system means you often don’t need to think too much about this in building your apps, usually if you want to get the user experience right, you’ll need to know when the data is ready.

To find that out, Meteor.subscribe() and (this.subscribe() in Blaze components) returns a “subscription handle”, which contains a reactive data source called .ready():"

I mean… what is this even? Certainly not what i’m looking for. It’s also very hard to read and understand, even as a native English speaker. Maybe this is all just an information architecture issue… but i’m going bug-eyed from reading the documentation.

Anyway… vent over. I don’t know if anyone is feeling similar. Maybe not. But I hope you can redirect efforts back to people who think traditional ways of making applications are just incredibly over-complicated. Anyway back to reading the Meteor Chef for help.

2

Hey @rross

So what the doc is saying is that when you call subscribe it returns an object (i.e. a handle).
This object is reactive, with a function called ready().

So you would do this:
subscription = collection.subscribe();

So for example, in your helpers

Template.MyCoolPage.helpers({
   data: function() {
      if (!subscription.ready()) return null;
      return collection.find({_id:myId}) ... <and so on>
   }
})

Note: I ignored context / scope in above code.
Now in terms of shooting down to the client what you want, look at the details of the publish() function. There you can set conditions based on userId.

Finally, you are right in what you are saying that it’s slowly becoming over-complicated. MDG has a mandate to make money so they are slowly abandoning the original concepts that made it great for startups / new devs and trying to cast a wider net for developers on other frameworks.

We can talk about predictions on whether this will succeed on another post.

3

@ramez Much appreciated. Thanks.