Meteor 0.9.3: Packaging updates and improvements
meteor.com
meteor.com
I also gave up trying to get my projects to be SEOable because the package that supposedly lets you do this (spiderable) was very hard to use (I got so frustrated with it I started my own version, which I later abandoned).
I started to write a post to the Meteor mailing list about these issues, but stopped as I believed it was too negative and I needed to just take a break from developing with Meteor. Overall I am quite sad with the whole experience as I had a lot of faith in what Meteor was trying to achieve, but feel these massive breaking changes in APIs is just too much for this one dev to cope with.
It's the thing I hate most about the JavaScript ecosystem. Projects throw out huge breaking API changes without a care in the world and devs are expected to just keep up. Things move too fast, break too easily. It isn't like this with other languages I've used.
But remember that this is why Meteor is still on 0.x version. This basically means - "we're still working on this stuff and figuring out the API, things will break along the way before we reach 1.0". And that's exactly what's happening. They are doing something so innovative that it's impossible for them to nail it on the first try - sometimes they're test one solution for one point version, but then listen to user feedback and change it. And this is good, because it means that 1.0 will be more mature all battle-tested.
The good thing is that Meteor team is very active. They are pushing regular updates, listening to their user base, and have up to date documentation. While there's still some road in front of them, I believe that when they reach 1.0, it will be a very solid, production-ready framework for developing real-time applications. Right now, it's also very good quality, but it's not production-ready, so I expect some breakage along the way.
Yeah, this is a good point. I guess what annoyed me though was Meteor had a lot of hype, trying to onboard devs with the message that "Meteor is easy for anyone to build a web app!". It gave off the impression that it was ready for a junior web dev to jump in and start building things, which as it turns out, is quite far from the truth.
One of our goals is to be suitable for enterprise and consulting shops, and that means we will need to declare a point after which we will do everything we can to maintain backwards compatibility. That point will be the 1.0 release.
Good luck with Meteor. :)
It's a very good idea to limit the number of external packages you depend on in any environment. And if you take the time to inspect the source code behind a package before you commit to using it in your project, you can make things easier for yourself in the future. MDG (Meteor Development Group) is very transparent about what they're changing and why - just follow the meteor-core Google group, and/or watch the commits on their github page. If you're paying attention, you will often have a month or two of warning about what a future release will contain.
I've been working on several large projects, and the new things that Blaze has added (mutable, per-template data instances) have made my life a lot easier. The transition between each release has been very, very smooth. Now that it's possible to write sensible UI components, and 1.0 is very near, Meteor deserves your attention.
I'm curious what improvements you are referring to.
Suppose you want to make a widget, such as a drop-down menu that lets you edit the currently selected item. To do that, you need a place to store the currently selected item id. Storing this in a collection is not desirable either. If you rely on session variables, you can't have more than a single instance of your widget running at a time because session variables are globally scoped.
Now with template instances, there's finally a way to store and retrieve that selected item id (or anything else, for that matter) in a way that's conveniently accessible within template helpers and event handlers on a per-template basis.