I think the core (meteor tools) will be maintained/improvement for a long time,
most of the innovation right now in the industry is in the bundlers and the data layer (GraphQl/Apollo) so it’s no surprise that this is the focus.
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 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.
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.
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.
Haha they had an unofficial one, Josh Owens. He did a lot to promote Meteor and help beginners. It’s a shame, there were a lot of good people in the community that were pushed out.
Meteor’s community is awesome and have long awaited manifestation of the multiple possibilities of the Meteor framework. It seems it gets closer and closer with every update. I can see MDG strategically planning Meteor’s future nicely especially with the Apollo integration as the booster. Apollo will allow many connections to variable amounts of data; therefore, Meteor won’t have to be tied to MongoDB. TypeScript will reveal more recognizable Meteor API extensions and open Meteor up to switching out APIs like the user system. Meteor’s build system will continue to improve and possibly allow more ease of use custom settings. Meteor server and Apollo can simply befriend React Native more and give developers easy access to app data to include reactivity with Meteor/Apollo subscriptions.
Also upcoming Meteor contributions like in this comment will excite the community more. I can see it turning into a free and paid Meteor marketplace that can easily replace Atmosphere and offer up a way for community member to receive revenue from their hard work. Ultimately, I believe Meteor has a culture that helps developers learn and grow, and it’s hard to forget a platform of this manner so it is believable that anyone that have left are still keeping an eye on Meteor.
) can handle it. Also keep an eye at Github for new releases!
