Meteor 0.9.3: Packaging updates and improvements

Meteor 0.9.3: Packaging updates and improvements(meteor.com)

64 points by yaliceme 11 years ago | 12 comments

davedx 11 years ago |

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 11 years ago | |

(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 11 years ago | | |

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

M4v3R 11 years ago | |

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 11 years ago | | |

> 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 11 years ago | |

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 11 years ago | |

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 11 years ago | | |

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

maxharris 11 years ago |

Meteor has gotten a hell of a lot better since I started using it (back in the 0.6.5 days about a year ago, in the fall of 2013). Performance and stability have improved dramatically, both on the client and server.

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.

sgarrity 11 years ago | |

Can you elaborate on this statement? "Now that it's possible to write sensible UI components"

I'm curious what improvements you are referring to.

maxharris 11 years ago | | |

http://docs.meteor.com/#template_instance http://docs.meteor.com/#tracker_autorun

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.