State of Meteor: Still Awesome


I’m kind of a nobody, but I fell in love with Meteor a couple year ago. Last year, I officially retired from nearly 15 years working with PHP and committed entirely to Meteor.

After a bit of a break from the keyboard, I have returned. And, I am as confident as ever that Meteor is the right choice not only for my future, but for the future of many aspiring and experienced programmers alike.


I’ve been working my way back into my Meteor projects, but to be honest… it really does take a lot of brain space. And browser tabs!

For some reason, when I am working with Meteor, there is just such a steady stream of awesome new stuff to check out along the way that at times it can be hard to stay focused (I fire links into a to-be-read-later browser profile now).

One thing I have noticed, now as ever… is the endless debate, is Meteor super awesome? Is it still super awesome? Aren’t these other 30 shiny objects awesome tho? And, of course, the haters who couldn’t figure it out because they didn’t have Meteor Guide yet, or want to coerce it to do things they haven’t thought of yet (deal with it, I do!), etc…

Everything has problems.

When I first started exploring Meteor, I experienced a lot of breakage on my app. Lots of it was my fault, but some beyond my control. Packages that flaked out or had major version changes that seemed too much to pile on all the rest of the learning curve. Or worse yet, a Meteor update breaking the crap out of everything.

That was circa .6-.8, so who can bitch about that? I am more prone to writing an API than using an API, so for the most part I rely on very few packages anyway.

I also strive to stay as close to Meteor core as possible. It was my belief that these two methodologies would help me write more stable software.

And it did.

I got back to Meteor circa 1.0+ and got real serious about it. I really poured a lot of time into three projects in particular. I did not 1.0 any of them, but two of them are quite usable and one was… but based on autoforms which has been, for me, just too much to rely on. It breaks too much.

So, after a six month hiatus, I was pretty concerned that everything I had done before would be so broken that I would want to just trash it.

They’re not.

They still run great, and aside from being not having any ES6 code in them, the code is still quite nice. There are a few things here and there that are throwing stack traces that weren’t there before, but big deal.

They point is… Meteor has just gotten better. Many of the problems I had to spend hours figuring out how to solve are solved.

The undocumented features are now documented. The missing features for passing data context and state around have been ‘finished’, or at least now you can complete a full circle around your app without any weird tricks.

Modularizing an app will no longer require painful package creation (not much doc when I was trying). Arunoda has been steady pumping out amazing tools as have others.

And, while the Guide is opinionated and in some ways that I disagree with… it’s a great compliment to the Docs. It’s a great read in general, and would be especially useful diving into Meteor for the first time.

It also shows that Meteor is striving to solve problems in the most efficient way possible and is fully open to integrating alternative options when they may prove to solve problems better, or are so popular as to be considered the One True Way (at the time). All while still maintaining Meteor Core with firm commitment.

And rightly so, because Meteor Core can be relied upon in a much more long-term fashion than can the shiny package of the day.

So, with 1.3 right around the corner… I’m really looking forward to dusting off, brushing up on ES6 & modules, and kicking some more Meteor ass in 2016.

I did a lot of research on Meteor. It took me three times to try it. This will be my third try at living it. I am confident it will define my next ten years, as well as shape our sci-fi-esque-immediate-future in immense ways.

There are a lot of imitators out there, but most of them are held together with spit and glue from a bunch of things written by several sets of disparate developers trying to equal Meteor. But Meteor is a comprehensive package, it’s finally really showing some maturity… and it’s core team is solid. There has not been a lot of turnover internally and their mission has stayed true to itself. Try to find that in a Linux distro, lol.

What is the state of Meteor?

Still awesome. And getting better.

And will one day run my spaceship. :smiley:


“Modularizing an app will no longer require painful package creation” - f*&k… i finally figured out how to do package creation properly.

lol jk - meteor is awesome.

1 Like

Thank you for writing this! I’m just recently trying out this high velocity world, so pretty much of a n00b concerning Meteor (or JS beyond jQuery for that matter).

Coming from PHP and (pretty solid) frameworks as Yii and Laravel, I find it pretty hard to work without the tools these frameworks have.

But I do have the feeling I started at the worst possible moment, since every tutorial, online course or article older than let’s say one month is ancient history. So I’m still undecided what to use as a view layer, use Atmosphere packages or not etc.

For ES6, there are several nice features added, but for some parts it seems sometimes overused (lets import/export everything everywhere whenever possible just because we can but not needed), only adding more boilerplate.

But yeah Meteor is awesome! (I think ;))…

1 Like

Personally, I’m not a big fan of frameworks in any way. I’d much rather write one that use one. However, both Starry Night and Space Kitty look pretty cool. They are both fairly opinionated, and while I personally prefer the opinions of Starry Night (and it is v3.x), I might recommend going the Space Kitty route because they are trying to stick as close to the Meteor Guide & Mantra techniques as possible and the community seems to be coalescing the decisions made therein.

I have not used either yet… but I like what they aim to do, which is just enough and not too much (say like Django to Python). When/if I choose one, it will come down to which one I can customize to do things my way with the least amount of work (I kinda see a fork coming if I get real about it).

Honestly, I don’t read many tuts… by far my favorite are by the Meteor Chef. I always relied upon the Docs, and now that the guide is out… I don’t think one should need any more than that.

Re: ES6… Some of it is really awesome, some of it is short-hand fluffery. The import-export abuse you refer to probably happens in a bunch of new-fangled goodies floating around right now because it does greatly enhance scope-targeting and scoping in JS can be kind of weird if there is nothing overhead managing it for you (say like Meteor, which does it awesomely).

In fact, I would say that nearly perfect scope management is one of the most amazing things that Meteor provides, as well as being the most under-rated. It is so good at it that people seldom even mention it or think about it… because it just acts the way you expect/want it to.

I’ve definitely never had a problem finding current Meteor info, but even the slightly aging stuff is not so bad… Meteor has stabilized quite a bit. Altho 1.3 is right around the corner, there are few breaking changes that should affect most tuts & articles.

After all, it’s not like you need to duplicate someone else’s work…you are probably just trying to figure out how others solved a particular problem so that you can use that method in your work… the principles will still apply. As a for instance, the Meteor Chef used to write a lot of his articles based on Coffeescript, which I loathed… but I could still read them and translate his solutions into my ECMA work with no problem.

So, welcome to the world of Meteor… it can seem overwhelming at times because there are 42 billion thousand awesome things to read and try… but once you get to the point where you can just write code all day solving problems… you will feel like a mad scientist who has perfected alchemy. :sunglasses: