Is any development being done on meteor itself any more? The last blog post is nearly 12 months old, last code commit some time ago and that doesn’t look like a code change.
Is this dead in the water, or are the ducks just swimming quietly somewhere?
Peter.
The last PR has been accepted 20 days ago: https://github.com/meteor/meteor/pulls?utf8=✓&q=is%3Apr+is%3Aclosed+is%3Amerged+
and was related to the builtin Typescript compiler. Development has been slowed down but is still intact, it seems.
I’m not to worried after watching Ben’s keynote and checking out the logic:
That said, I don’t think MDG is going to add any significant new features to the framework, but I’m happy so long as the core stays there and continues to be maintained. The rest, I can do myself.
Simply checking out the Meteor repo on GitHub will ease this FUD that has been common in the Meteor world lately. MDG has stated it plans on supporting development on Meteor long-term and has no plans on abandoning it. I run a small software consulting company and we use Meteor for most, if not all, new products we make for our clients. IMO, it is great for getting a startup or entrepreneurs product to market fast, with the reliability of the JS ecosystem.
I will second @msavin, I am also happy so long as they keep the core and it continues to be maintained. Everything else I can handle.
Where did you get this number from?
https://www.meteor.com/hosting
JOIN 1,000’S OF COMPANIES THAT HAVE MIGRATED THEIR METEOR
DEPLOYMENTS TO GALAXY
It’s been there for a long time
You can usually find a PR on the latest versions and watch that for updates.
I couldn’t find it, would you have the link?
@msavin summarizes it pretty well.
From Ben’s talk:
Many successful business/products are build on top of Meteor tools but I think it’s better than everything else out there, I’ve both webpack and Meteor projects and I firmly believe that Meteor is the tool for startups, right now the choice in the NodeJS ecosystem seem to be either a highly opinionated boilerplates and frameworks (typically coupled to a view layer) or you pretty much have to assemble/configure everything yourself from many packages, Meteor is sitting in that sweet spot.
For the rest, I think the community (which includes you 
) can handle it. Also keep an eye at Github for new releases!
Half a million per year – revenue – in the context MDG’s $30 million of venture capital, is 2 orders of magnitude short of success. Account for expenses (dev salaries are 100K+), and the picture looks even worse. Normal management practice for a unit like this would be to shut it down.
Meteor could massively boost its customer numbers and revenue with one weird trick (it rhymes with “prequel”), but they seem drawn to shiny trends.
Edit: I see a new raise of $22 million in June, so $53MM total. Seems likely that the money will be mostly deployed towards new products.
It’s a very conservative estimate. For all we know, most customers average two or three containers each, and maybe Galaxy has 5,000 customers and growing, so maybe it’s bringing in a few million per year. In any case, it seems to be enough to pay Ben’s salary.
At a big company, yes, but for a small company, a couple of million could still matter, especially if there are long term plans / growth.
Keep in mind, Apollo Engine runs on Meteor, and maintaining Meteor might be easier than re-writing the whole thing from scratch, especially if that maintenance is profitable.
I guess now meteor is not the only one having modern and legacy browsers bundles anymore
I know NextJS is couple with the view layer but you have nuxtjs as well. I’m not saying NextJS is better. And for developers, having more options is always better than having none
Copying is the ultimate flattery, more respect to Benjamin for pioneering this and pushing the industry forward more than a year ago.
Also the idea is having a full stack framework for every view library is absurd, I actually only considered Meteor seriously after the view layer was de-coupled. Those frameworks lifespan is decided by the hype surrounding the view layers and as we have seen in the past few years, JS developers love to switch views and re-write from scratch haha.
Meteor is still the only one doing it right.
Next.js is just using the module/nomodule-pattern. What happens in three years, when all browsers support modules, but only the most recent ones support your beloved features in ES7/8/9/10… ?
Meteor, as far as I know & understand, has a mechanism that works now and in the future.
Ok, my two cents. MongoDb has version 4.2 GA (see eg: The Long-Awaited MongoDB 4.2 GA Has Landed - Percona Database Performance Blog). Where is Meteor on that one? Not even transactions which is really important for a professional app.
Same for the Meteor driver, version 3.1.2 vs 3.3 on npm (see mongodb - npm) and actually giving us a headache right now because of some unexplainable transient transaction error (yes, we have gone ahead to use transactions already in a massive re-write of our app).
So this is the core package. What is done on it? Nothing much IMO, one guy, as good as he is, isn’t enough.
Maybe it’s time to give Meteor to the community and just concentrate on Apollo. Just look at what has happened to Kadira’s Storybook. He did the right think when they concentrated on something else. Same for their APM. But yet, MDG holds on to something but doesn’t update core package and drivers like MongoDb.
But yeah, why should they make MongoDb work better with Meteor when they are developing Apollo. Hmmh 
Though I do agree that keeping Meteor updated with latest node and mongo packages is essential, I think it’s also important to consider that there is no indication that MDG would not accept high quality relevant PRs from the community right now. So if anyone feels like rolling up their sleeves, there’s nothing stopping them. Though this being pivotal code for Meteor, the expected level of quality should be very high and rightfully so.
And by saying this I definitely don’t want to downplay the importance of updated mongo. I’m hit with mongo transaction problems as well.
I don’t see how small and bootstrapped SW development companies like mine are contributing to MDG’s bottom line by submitting high quality code.
Just pull out of it and the situation changes. You can’t sit on it (and do nothing to very little) and have control over it whilst expecting others to work for you. It doesn’t work that way IMO.
I mean the world has moved on, we’re not talking about some cosmetic changes that MongoDB did to it. TXN is a significant step up and it has done wonders for our app in terms of avoiding data integrity problems due to errors happening midway through operations that are all part of a larger transaction.
Now we just rollback and we can concentrate on replicating the error on the exact same data vs spending days on trying to fix all the complicated relationships in our NoSQL db (yes, there are many relationships between the collections).
The current version of Meteor is a nightmare and like we all have written many times it is excellent for quick MVP development but it clearly is no longer ready for large scale, professional development with heavy duty on the backend. If you have a simple backend it is probably still ok to use.
I once heard it opined that view platforms have about a 5 year cycle. Server tech is longer, between 10-20. React in many feels like it’s at peak, and now they are making ideological choices at the cost of practical solutions (see their absolute insistence that no “side-effects” be created in render methods, and corresponding refusal to create any kind of practical tool to help manage cases when we do need to create side effects). We are at 6 years, so I guess that makes sense.
