What @lpgeiger said maybe Most Used packages. The term decline maybe simply looking at the line chart. If so, yes most of the Most Used packages is declining this week
Great points. …It can be scary to Meteor developers what’s going on now, as change often is, but if we want to have as long of a life as, say, Linux, we gotta become more deeply entangled with the greater ecosystem.
I think, to do that, Meteor will have to do more than just glue a bunch of tools together like it currently does. That was a great initial marketing tactic to bring us all here, but it won’t give it the longevity it needs. It will need one or 2, or however many, core tools that its the best in the business at, which it then offers to the greater NPM community. Currently, Meteor doesn’t offer a thing to anyone that’s not using Meteor! Take Blaze as an example: you can count on your 2 hands how many people used that outside of Meteor! Its homepage and external repo was hardly maintained.
Whether its DDP, or perhaps even Tracker–well, Tracker 2.0–whatever it is, Meteor needs to release something that will stand the test of time outside of Meteor. Now, how does that help Meteor? Well, you get the best implementation of it within Meteor, i.e. a bunch of successfully coupled add-ons.
I think MDG should be the guys responsible for the most popular transport layer for GraphQL, the best-in-class implementations of the GraphQL specification. As it is, the GraphQL spec hasn’t even agreed upon how it will implement Subscriptions. That’s where Meteor comes in. Meteor’s the king of subscriptions. Nobody has ever come close to offering what Meteor offers in terms of “domain state” subscriptions. We need to own that intersection of the stack. We can’t acquiesce because GraphQL has come out. Either fight it or Join them. So let’s join them and get it so F#*!ing right that everybody is forced to use it just like everyone will soon be forced to use GraphQL to begin with. The subscription aspect is worthy of an entire other specification. Nobody knows what would go in that better than MDG.
12 Likes
I see you saw that GraphQL logo in Geoff’s talk 
Couldn’t agree more. I think we need to take most of the best-of-breed stuff from the wider ecosystem (Mocha, React, and others) and really focus on some core parts that we can be best at. I think there will be more clarity around the vision next year and some movement in that direction - things are winding down a bit for the holidays but I think we’re all on the same page.
One huge advantage we have ahead of anyone else who might be trying to do the same thing is a deep understanding of what modern apps look like, and some customers with real apps and data to test out our theories. If we build a new data layer, you can be sure we’ll test it on a variety of real production apps to make sure it works in real life.
19 Likes
that is an interesting twist. We do definitely gotta use that to our advantage. Galaxy will surely help you collect the metrics. Facebook won’t even have anywhere near as much to say in this arena–they can only talk about basically one big monolithic app used by milions of users; they can’t speak to the pains of startups prototying their apps, just trying to go from 1 to 10,000 users. The complexity of the interfaces in their “facebook stack” tools prove that point. MDG can continue to add the veneer that startup application developers need to get going quickly. This time around, let’s just make sure we also offer the path towards the super robust scalable solution–that said, we likely will already have it just by implementing the Foundation/vision/specification set forth by FB.
6 Likes
Probably not. It’s just reached a certain state of maturity where it’s outlived its hype.
1 Like
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
15 Likes
Interesting, I never understood how to interpret the line chart.
2 Likes
@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:
- the number of total downloads
- the number of recent commits on github
- the number of unresolved issues,
- the number of contributors,
- etc.
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.
7 Likes
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?
4 Likes
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?
1 Like
Just curious, what framework are you going to?
pure nginx and static html 4 
7 Likes
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.
1 Like
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:
- Provision a new Linode VM with Ubuntu.
- Security harden the new VM.
- Install mupx to handle deployments (let it take care of node, mongodb and nginx installs via docker).
- Make sure the SSH user that will be used with mupx is in the sudo group and has NOPASSWD (see Additional Setup/Deploy Information).
- “mupx init” in local project; adjust mup.json as needed.
- “mupx setup” in local project.
- “mupx deploy” in local project.
- Profit!
1 Like
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.
3 Likes
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!
4 Likes
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.