Meteor 0.9.3: Packaging updates and improvements
meteor.comI 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.
(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.
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. :)
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.
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.
> 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.
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.
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.
Hmm... just how much stuff in the JS universe is actually not 0.x.y?
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.
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.
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.