[davedx]

I used Meteor intensely for two projects up to where they introduced the new templating system (blaze), which broke both of my projects extensively including some third party Meteorite packages that I couldn't fix myself (believe me I tried) and seemed to be abandoned by their authors.

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.

[djmashko2]

(Disclaimer: I work at Meteor) I'm sorry that you had such a bad experience with the transition to Blaze. We have been moving very fast on changes trying to nail down a good API for 1.0, which is coming very soon at this point. Hopefully you will give it another try when 1.0 comes out, and the API becomes stable.

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.

[davedx]

Thanks for the considerate reply. I'll wait until 1.0 and come back and have another look around when the dust has settled. Backwards compatibility is such a big deal for so many people, I hope you guys can keep things stable post-1.0.

Good luck with Meteor. :)

[maxharris]

I wrote a pretty complex app on 0.6.5. It wasn't hard to bring up on 0.8 when that came out last March. I haven't touched it since May, except to run "meteor update" and start the service up again. I have it running on 0.9.3 now without any issues.

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.

[M4v3R]

I know how you feel, I have a pet Meteor project that was also broken with new Blaze templating system and it wasn't very easy to fix it, I needed to dig into the documentation, understand on a lower level how things work and then make necessary changes in various places in my app. Fortunately for me I don't need the page to be indexable, because it's an internal application.

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.

[davedx]

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

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.

[anandsatyan]

We just deployed our site using Meteor 0.9.3. Everything seems to be working fine for us. Was initially a little anxious to deploy on 0.9.3 but managed to do it without any hassle. Its now live on http://map.boutline.com/. I must say Meteor has gotten much better in a short span of time. Im sure they are working day and night to ship a stable V1.

[Igglyboo]

Meteor isn't even version 1.0 yet, I would hope they would do breaking changes and standardize their api before their first major release.

[russtrotter]

Hmm... just how much stuff in the JS universe is actually not 0.x.y?