I’ve come to notice a pattern while browsing Atmosphere, where many “mainstream” packages have declining install bases. At the same time, the repos of many of the packages I consider vital to production applications have declining (or dead) activity levels.
You may argue these are meaningless indicators, but subjectively I’m losing confidence in many core application components.
Please refer the github repo of your favorite package for: testing, routing, task queue, file storage, forms, and DB Admin. IMHO they have too infrequent code updates for the growing list of issues. How does one build real production apps without confidence in these?
I’m truly very grateful for the package authors and maintainers that have volunteered their time. I can’t help but wonder if MDG is providing the motivation or support to make these packages grow.
Any ideas out there for how MDG can better support the package maintainers?
Dedicated full time MDG contributors?
Bounty?
Documentation?
Refactor package architecture?
NPM support is coming, and I think its going to be bigger than most people realize. We should be able to use any database with Meteor. Think of all the people who are holding out because Meteor doesn’t support SQL.
C[quote=“msavin, post:2, topic:14967, full:true”]
NPM support is coming, and I think its going to be bigger than most people realize. We should be able to use any database with Meteor. Think of all the people who are holding out because Meteor doesn’t support SQL.
[/quote]
It’s going to be a bigger headache, as the signal:noise [quote=“msavin, post:2, topic:14967, full:true”]
NPM support is coming, and I think its going to be bigger than most people realize. We should be able to use any database with Meteor. Think of all the people who are holding out because Meteor doesn’t support SQL.
[/quote]
ratio becomes even worse and the community and best practices become even more fragmented. :sigh:
That being said, I’m going through and forking high-quality abandoned packages into Clinical Meteor track as a sort of stable-distro that we can put QA tests on and walk over to other technologies and libraries.
How does one build real production apps without confidence in these?
@lpgeiger, this matter was already talked about in details on the forums not a long time ago. Without a proper research it’s difficult to get confidence in any solution.
Just when I thought there hasn’t been enough threads about Meteor dying, there is a new one.
Can you please elaborate on what packages you think have a declined activity? And what is your threshold for “aliveness” of one? I am curious since no matter when you look at the Atmosphere package page, it would look like its download activity had a spike or two in the beginning and then it is calming down to an even line.
In fact, I believe same is true for most utility software (packages or addons) for other editors, npm, etc. npm package registry is weird because they count downloads through parent dependencies, and they count every time it is installed. So if your app uses package X that is depended by 10 modules in your app directly, it can be counted 10 times every time you run npm install.
That always happens when a community/platform gets bigger. It was nice to be here for the early days!
However - I do think MDG can be more assuring during these times. If we look, the top contributors are diversifying from Meteor instead of doubling down on it, and these threads are another symptom.
For myself - there’s nothing helps me build as quick as Meteor, and its getting better, so I continue to stick with it.
One thing I want to put out there: Every single thing except travel and shopping has a big dip during the “holiday season”. Many people are using Meteor at their job - when they take a vacation, usage takes a temporary dive.
Well, Kadira recently folded their Meteor blog into the Kadira brand. Kadira recently stepped out of the Meteor world by announcing tools and courses for GraphQL, and I’d suppose the eco-system to follow that.
Crater, from Josh Owens, made a similar move. Before it was a radical Meteor website, but now it focuses on real-time web, which covers everything from Node to React to Phoenix.
Sam Hatoum kind of passed Velocity back to Meteor, then built his own testing tools. He went from being a Meteor-only solution to a broader solution.
These guys are still behind Meteor, but they are diversifying. I’m seeing a similar pattern with the Meteorites I keep in touch with, as they’ve gone from being “religious” to discussing other stacks.
Between what’s coming in the near future and my theories about Meteor 2.0, I’m sticking around, but I think we’re all beginning to see some challenges.
I hope that using Meteor is a decision everyone approaches rationally by weighing the pros and cons, rather than being religious about it. In my opinion it’s strictly good that people in the Meteor community have experience with a lot of different technologies, so that they can bring that experience and expertise to their Meteor projects.
I’d be much more worried if nobody in the Meteor community every considered any other tools - it would be a sure-fire recipe for getting wrapped up in our own small universe. It’s super important for Meteor to become a part of the wider JS community, and this is the first step. Ideally some of the things we build soon can be adopted from outside as well, so more people from “outside” can participate in building a cohesive, full-stack platform.
Let’s look at a specific example:
I’d argue that building a testing tool that appeals to wider community is the best way to make sure that the tool is actually good. If someone builds a Meteor-specific testing framework, it’s completely possible that people use it just cause they are tied to Meteor. For example, would anyone use Tinytest if they could be using Mocha, which has insanely more adoption, and therefore has more tools, has worked out more kinks, and has a ton more documentation and tutorials? I don’t think the solution to that is to improve Tinytest, it’s to figure out a transition to a tool that is just better, more adopted, and stands on its own merits rather than existing just because it’s coupled to some of the nice parts of Meteor.
For better or worse, people are looking at package downloads, github stars, and github issues as measures of a package’s ‘aliveness’. Obviously, there’s lots of issues with this:
Github issues can be a measure of either a package’s popularity; or a measure of it’s bugginess.
Github stars aren’t a good measure when packages are forked, and maintenance hops to a new repo.
Package downloads aren’t reliable because of module dependency distortions.
Package downloads aren’t reliable because of spamming from continuous integration servers.
But stars, issues, and downloads are the only metrics people have to work with, so that’s what they use.
Personally, for the companies I work with, we’re more interested in design coherency, package integration, high signal:noise ratios… what we colloquially call a ‘.NET’ approach. So the metric there would be something like
SUM [ number of QA tests / number of methods ]_package(0->n)
Basically a measure of QA test coverage over a predefined package space. When Meteor first published around ~0.3, it had a small package space with Tinytests across all the packages, and had very high internal consistency. When Atmosphere was released, and there were less than a thousand packages, there was high internal consistency. In both cases, high signal:noise ratio.
As we add NPM support, the signal:noise ratio is tanking as everybody adds their preferred library. It’s great for adoption; but lousy for internal consistency and user experience. And that’s where all these threads and discussions are coming from.
Release tracks and distros are one possibility for counterbalancing that trend, and improving the signal:noise ratio. But it’s a somewhat untested approach in the Meteor ecosystem. The Meteor Guide is another attempt at boosting signal. There are various features that could be added to Atmosphere to boost signal; but the latest word is that it’s being deprecated in favor of the sprawling mess that is Npm*.
*A useful mess, to be sure; but I shudder to think of the days of my life I’ve lost in investigating abandoned packages on Npm; it’s got 100,000+ packages; and a Pareto distribution suggests that 80% or more of them are abandoned; ug.
I’m hoping the next versions of the Meteor Guide can be a huge help here - it will be much easier to find some of the de-facto “standard” packages that everyone uses. Right now the guide is mostly covering Meteor-specific stuff (for example, we don’t have moment.js in there anywhere) but eventually it would make sense to cover a wider swath of NPM so that people don’t have to wade through all of the crap.
The fact that concerns that touch on but aren’t specific to Meteor are transitioned to NPM or some other ecosystem, actually bodes well for the Meteor ecosystem, I think. If Meteor packages continue to exist (combining NPM, etc, dependencies with Meteor-specific enhancements), and these are published on (or filtered through) Atmosphere, I think it’ll be a lot better than now. Sure there’s going to be a lot more ‘I can’t get NPM package X to work with Meteor Y’, but you’ll have a much cleaner Atmosphere, and clear community and guide go-to packages. Seems like a big win to me.
I like the built in fibers for much easier coding.
E2E livedata is nice, but let’s be honest - most of the time it is not needed.
A lot of people seems to use it everywhere and then hit the wall in kinda production really fast.
But that feels like full religion approach - when Meteor than use it for everything. Pls dont
I feel like Meteor is nice glue for puzzle. Using it as account system and the realtime oplog mode for few things which need to be in realtime.
And easy connecting pieces as these invisible fibers are really usefull for fast development.
But there are many other usecases where u dont need full realtime mode and want some SQL, or want some relation heavy document store like Neo4j etc etc.
Just use best tool for given job.
There are always packages or ways how to reach non-core subsystems.
I would still love to have some incremental loading etc. Or some pattern where we will have like template level DDP to not be connected to realtime microservice all the time, but just in that 1 time when needed And than disconnect to not waste valuable resources.
While evaluating new tech for business use, I tried out the MEAN stack and was as others have said and implied, in a sea of NPM packages trying to figure it all out. I wasted weeks sifting through outdated packages and conflicting advice.
At the time the community seemed to be gathered around Express, but it seemed the package author had abandoned the package for the “Go” language. Most help I found was using Express, but everyone was on the cusp of using a new framework to replace Express. It was like a turning wheel of never ending tech change, code rewrites, dogma, distractions. I was spending so much time on figuring out what to use and how to use it, I almost turned my back on Node. I needed to get my business idea off the ground!
I come from a C#/F# .Net background where there may be more than one way to do things, but the tech stack is standardized. When I ran across Meteor (of yesteryear) it really made sense and felt comfortable due to the standardization around the tech. It was leaps and bounds more accessible than MEAN.
I ended up taking a chance on Meteor because of the positive first encounter with the tech and the community that seemed to be growing around it. No one was arguing about what tech to use, just how to accomplish.
To me, Meteor takes away the headache of [choosing] and [figuring out the inter-connectivity] of various Node tech, so I as a developer and business owner can instead focus on core business-value functionality.
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.
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.
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.
