

Meteor 0.9.3: Packaging updates and improvements - yaliceme
https://www.meteor.com/blog/2014/09/25/meteor-093-packaging-system-updates

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

------
maxharris
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
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
[http://docs.meteor.com/#template_instance](http://docs.meteor.com/#template_instance)
[http://docs.meteor.com/#tracker_autorun](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.

