As the person who implemented the line chart on Atmosphere I can let everyone in on a secret–it pretty much always looks the same. The line is graphing Atmosphere Score which is a freshness index based on how popular it is (mainly based on downloads) vs how long it’s been since the last release.
It probably isn’t the best thing to graph (especially over a week), because almost always it just trends downwards. One day we’ll get around to plotting something more useful there. cc @domyen
Interesting, I never understood how to interpret the line chart.
@tmeasday Sorry to say that, but I think that the decision to use the Atmosphere Score in the current form for evaluating packages quality was a bad choice after all. Probably, It would serve the community much better if you had considered using some less opinionated metrics, like:
I understand they all have their place in the formula for computing the Atmosphere Score but it does not change the fact that the “model” is arbitrary.
Hmmm … baked in npm support is on it’s way, and @tmeasday just mentioned that someday Atmosphere might be updated … this can only mean one thing - Npmosphere is coming! 
I think it certainly feels like it’s dying. It’s not something one can easily quantify, but on the whole I feel like MDG isn’t really delivering best-class solutions for the problems web developers face. Meteor was a big help, but now there are many other options and if feels Meteor is a laggard. And it seems they are increasingly silent on matters and out-of-step with the community i.e. who isn’t disappointed by Galaxy?
I for one have stopped using Meteor - the main issues was the slow build time, the difficult deployment and also I wanted a stable system - not one I had to keep updating because Meteor changed the way things worked.
I didn’t get the memo, what’s disappointing about Galaxy?
Just curious, what framework are you going to?
pure nginx and static html 4 
Correct me if I’m wrong, this makes it sounds as if they’re going to replace the entire stack (over time) and rewrite the glue (to be best in class) as their competitive edge.
I hear you with regards to the slow build times, but I’ve never understood the “difficult to deploy” issue. As a quick example, here are 8 steps for getting a self hosted Meteor app deployed on Linode:
I’m new here, and even I get the sense that I missed the peak. I started doing a Meteor project (I have done 2 shipping projects) in May this year, and when I did that I found so much cool stuff that all worked out of the box. In particular, Aldeed and Yogiben’s stuff, but plenty of others. I started to notice problems when Meteor 1.2 was released. Folks just didn’t seem to update their packages, even when doing so was very very minor, like updating the less dependency (and I provided patches that languished for months).
Other than that, I still think Meteor has something, but it’s really the focus on developer experience. The package manager is so much easier to use than npm or bower, and creating and forking new packages is even a breeze.
I’m not sure if the activity has died down, or if there are just some very very popular packages (and package authors) that have been dropped (like Meteor Admin and some autoform packages - and judging by how many package yogiben and aldeed have produced, I can’t say I blame them), but being relatively new to this table, I hope Meteor sticks around for a while.
Finally, React is all the rage these days, but it does feel like it’s shoved in side ways a little bit into Meteor. Meteor could do something things to make it better. For example, a set of helpers as an object on a React class instead of just having the one reactive method. I also wonder if there might be a better Blaze like way to bind methods instead of putting everything inline the React way. And having some Blaze template tags (handlebar style) would be real nice in React. Ternary if statements and self invoking ES6 functions are ugly and less readable. If it were me though, I’d leave React basically the way it is, and add the Blaze stuff on top of that, rather than trying to go back to the Blaze way. It’s nice having an entire component (or even a set of components) in one file.
Switching to React also has it’s costs - there is no autoform for React (I know you can wrap it, but still).
Also, let’s get some React Native. And yes, some GraphQL, and PostgresQL. 1.2 was about multiple view layers. Maybe 1.3 can be about multiple databases.
Just curious, what framework are you going to?
I went back to node and express with mongoose for the db link - build times in Meteor was around 15-20 seconds - now it is less than 1 second if not nearly instant. Using Bluemix for deployment - extremely easy to use and has a lot more features.
I only thing I will miss is this forum - the users have always been very helpful.
The good news is that you can still hang out here if you’re not a Meteor fan … I’m looking at you, Phoenix Posse!
With Bluemix the steps are
1: login to Bluemix
2: Click on the app to update.
3. Click on "start coding"
4 - log into command line interface
5 - enter cf push
It worked first time I tried it and every other time afterwards.
Don’t get me wrong there is nothing wrong with Meteor - just that in my case I did not need 3 way data bindings so many of Meteor features were not being used.
Nice! To be fair though, I was providing quick steps for getting a fully self hosted solution in place (with all of the flexibility that comes from controlling the complete server/VM/container). Using Galaxy, Modulus.io, Scalingo, etc. is much more in-line with the Bluemix steps.
It looks like they will have to, but maybe unlike react they can keep the same subscription interface for those who want it, just built on top their new super robust graphql implementation.
I don’t think MDG will be able to suffer the same response as the blaze vs react fiasco when it comes to their subscription interface.
…now I don’t know that they r building this. @sashko hinted above. Care to elaborate @sashko lol? …but basically they were late to the party on the react thing, graphql is an opportunity for them to redeem themselves, while also fixing long time issues with LiveQuery.
Basically this is the opportunity to publish events prior to writes, rather than tail oplog. Graphql seems to be built specifically for that. So that’s why graphql is likely a lot more appealing than react ever was to them. Graphql provides a playground where they can focus on getting implementation perfect. Whereas before when it came to subscriptions they had to worry about interface and a lot of other things.
So as far as mongo subscriptions go, there is mongoose + graffiti By rising stack. But what’s missing and what’s also missing from graphql altogether is subscriptions. That part of the spec isn’t complete. I assume it will be complete any day now. But I also don’t think it needs to be complete for MDG to start implementing what’s under the hood there. Their are proposals for the interface and it can likely by adapted near the end of completion of implementation. So basically MDG can put DDP and the best of LiveQuery to use plus long time ideas to fix performance, eg observe writes and propagate those to subscriptions instead of oplog tailing, in order to do the subscription stuff graffiti does not do, and likely will never do, and honestly what’s the most complex part.
Graphql is all fine and dandy but without subscriptions its worthless. I really don’t understand why subscriptions weren’t a first class priority. Along with relay it feels like it was, but in fact those queries u specify in ur react components run once! It also seems ur gonna have to specify them again in subscription form, which seems stupid. We do that in meteor but the way relay works is it populates props of the precise component where its used rather than universally give the client the data–so u shouldn’t have to specify both a query and a subscription; I hope it works out that way in the end.
So anyway my overall point is that MDG has an opportunity to shine here. Be the first one to make a subscription implementation for a major database for graphql and that will be a big deal. Think about it–this intersection of the stack ties so much together, u basically will need to come to meteor. I do think they should abstract it out of meteor as discussed above so they can have a product appealing to a larger audience and therefore has potential for more longevity. But with the best implementation of it, ie the most coupled addons in Meteor, it will make the most sense to try it out in Meteor itself, especially in the early days.
If this wasn’t meteor, u need node, npm, express, mongo, react, relay, ddp, isobuild, etc to demonstrate this. Thats what I mean by “intersection of the stack.” It covers that middle ground where the client perfectly touches the server and is connected over the wire via ddp. There’s competitors to ddp such as that Json tokens library, so it’s not like at this point Json over a sockets library is that big of a deal. But collectively it’s a lot to put together. This gives meteor an opportunity to learn from its mistakes and apply all it’s knowledge about isomorphic apps nobody else has.
My hope is they get the marketing aspects right. That means building this irrespective of meteor so it becomes the defacto mongo graphql subscription LIBRARY. And maybe while they are it, the rethink db one. But more importantly a pluggable subscription transport library for NPM apps. So where meteor requires u to buy into a huge stack, they offer Meteor.publish/subscribe for easy use outside of meteor–and of course I’m referring to whatever the graphql interface ends up being.
As long as they continue with the proprietary approach that only works in meteor (or at least is mainly used there), more general packages for smaller portions of the stack will gain more popularity on NPM. That’s the NPM vision in general. I think MDG should entertain partaking in that vision. The question becomes: will people just use our package and not in fact adopt meteor? Will we be giving something out and not getting anything in return? I think the net results will be better. U will get more overall lock-in toward something they built. Just as graphql is seemingly gonna garner a lot of lock-in or as react already has, this library I’m proposing could as well. More lock-in than an opinionated full stack framework ever could in the post-rails npm world. With that lock-in they have the best possible hook to motivate people to come to meteor proper via value adds.
…maybe it’s pie in the sky that we could become THE GRAPHQL SUBSCRIPTION TRANSPORT LAYER, but it’s worth a shot. At the very least if would mean a hell of a lot more community contribution than meteor is used to. It’s time to branch out into the world. NPM dictates this building block vision.
In a perfect world, at this point, I would start with a plain old node.js project. If they were node modules, I’d import ddp, minimongo, and a few other things that Meteor does great. Then I’d do my own thing. I anticipate that, with more time, managing a meteor project will be eat into my ability to innovate. I’ll get sucked into tasks like switching from Blaze to React, and whenever the DB layer becomes abstracted, there will be some sort of ORM to migrate to as well, and when atmosphere inevitably closes shop and gets folded into NPM, that will just create more work for me.
How will this be different if you start from a plain Node.js project?
Better to say Meteor is dissolved.