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.
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.