That still can be done with OpsCaptain around. It will be impossible and misguided for whomever runs Meteor to think they can control all the monetization avenues. For example Wordpress has their hosting and thriving but it doesn’t mean there are not like some 5 other dirt cheap Wordpress hosting companies out there. Believe it or not a $7 USD per app hosting strategy if MDG had pursued would have been a waste of their time because you are talking about a min of 10k apps to even make something decent. Which is simply a number of apps that does not exist in the Meteor.js community. MDG knows this but you guys sitting on the forums talking don’t. MDG is very smart do not underestimate this simple fact.
So yeah MDG can focus on the Apps generating revenue, OpsCaptain will focus on the apps just getting started and require a tight budget. I think this in the end helps the Meteor.js community than harm it.
Those acquisitions take time to settle and Tiny has a lot to sort through so I think we need to give them some space. Nuxt/NextJS are not comparable to Meteor, they’re are front-end frameworks and mostly for creating websites, we use them create static websites and fetch from an API but that’s pretty much it.
I really think there is a big opportunity for Meteor to bounce back, I think Tiny got Meteor at the best state and timing, the hype around webpack/static websites/graphql and serverless are slowing down and rate of change within the NodeJs ecosystem is slowing as well. Meteor has a strong base and community around it, a little push and I’m sure it’ll pick up again.
Galaxy, can simply do what Heroku does here and open it up for Addons. I am sure there will be many companies who will get on board. As I run a hosting company myself, I can guarantee you, running a large fleet of MongoDB instances is not a walk in the park. Just provide addons and take a 30% cut like Heroku does.
Come on, man. The explicitly stated in the Meteor blogpost that we’re to take things slowly. Second, they actually are listening closely, I mean they started Some Exciting Meteor News - #121 by florianbienefelt to get feedback from us!
I think we’re all getting a little crazy here. Geoff said it well in the announcement post:
No other set of libraries can offer an integrated experience like Meteor’s, and Meteor’s advanced technology, like live database queries that “just work”, is still unmatched by any other platform.
That’s where the magic is. Meteor just needs to be modernized, and to be given proper marketing.
–
A “Meteorized” GraphQL is Apollo, and it will never be as simple as Meteor’s LiveQuery stack just because GraphQL is way more complex.
A lot of the changes suggested here are too drastic… there’s no need to change a formula that works. For a lot of these suggestions, it would be better to just create an entirely new project.
First of all a reminder that a similar discussion has already happened. Please read my summary there:
As @msavin said, we have gone a bit crazy here. I’ve tried to sort through things to get a bullet point summary as much as possible. Obviously I didn’t get everything, I tried to get the ideas that were most present and/or hit me as important/interesting enough to mention.
Non technical things
Hire important people from existing team and community
Marketing
LTS version
Update docs/guide
More active with community
Merch store
Refresh tutorials and more of them
Tech stuff
Finish and release Meteor 1.8.2 and 1.9 ASAP.
Keep working on what is on the Meteor roadmap (continue migration to NPM, ontinue improving rebuild performance)
Update React packages
Full Typescript support (beyond what is in coming in Meteor 1.8.2)
Official testing (Nightwatch.js and/or Webdriver.io integration among other improvements)
Better integration with Apollo (especially accounts => accounts decoupled from Meteor)
Update the mongo packages to take advantage of the new MongoDB functionality. Especially transactions (and optimize oplog, possibly with change streams).
Improve Cordova
Official package for SQL
PWA support with default to prevent common issues or as @arggh put it “mitigations against the most common footguns”
Additional SSR support
HTTP/2 Websocket Support
Tree shaking
Support for JsonSchema (From Medical Meteor Track - @awatson1978, plus could be integrated with other MongoDB tools)
GitHub Package Manager as an alternative to Atmosphere
Official Svelte integration (from out Svelte evangelist @captainn )
Official Vue integration
React Native support
WebAssembly support
Offline first capabilities/capacity mainly to support cordova apps
Improve code splitting
Consider an official package for payments integration
Develop patterns around serverless
Build target: Electron
Revisit Windows development experience
Refactoring Tools / Build Tool GUI
Keep support for Blaze (while they are some who want to abandon it)
Improvements to Galaxy
2FA
Improve APM
Cheaper tear for hobbyists and possibly a free tier (could be tied with MongoDB Atlas free tier)
Speed-ups
APM should be its own product for non-Galaxy apps
More regions and hosting options (add Azure and Google)
Firewall
On the note of Galaxy, I think the inspiration here should be MongoDB Atlas. It has everything I could have ever wanted in hosting. Beside what was specified above I would love to be able to run one deploy command and then my app would deploy across multiple regions and with the new MongoDB connection string there wouldn’t be any need for separate regional configs (though there will be need for other databases).
IMO focusing on Blaze would be a very bad idea. Sure it’s great and it works. But not many devs are using it, aware of it or for the large part interested in learning another front end framework when it doesn’t offer something that amazing over the existing ones. If they are looking to grow Meteor and evolve it, focusing on such a niche framework would be wasted time.
I’m very aware that opinion upsets people still using Blaze. Even though there are plenty of apps still using it (anecdotes not needed), I personally don’t feel it would be the right avenue to renew interest in Meteor.
If the goal isn’t to renew interest and it’s just to make the existing platform better, then sure. But my angle is more about making Meteor something non-Meteor devs would consider using.
“Focusing” is a big word, no offence. In my opinion, backward compatibility with Blaze, which is more likely the issue here, isn’t such a money hog. If anything, as you know, Blaze has actually been spun off long ago by MDG and many fixes have actually been provided by the community.
Evangelising so much about dropping support for it suggests that you see Blaze as the main problem preventing large scale adoption - which I think is a bit of an exaggeration.
I’m not evangelizing anything. Just offering up my opinion as to what would make Meteor more appealing to outside developers. Right now we have a bit of “survivors bias” going on in the Meteor community, where those that are still around really love how things are. But I think it’s important to look at a wider view point of the outside community and non-Meteor devs. That’s mostly where I’m coming from.
Having Blaze continue to be a community package is cool, I’m totally okay with that. I’m just seeing a lot of people suggesting Tiny re-invest in Blaze itself. IMO that would be a bad idea. Community support, aok.
This does more harm than good, and I recognise the same point as one made by @sacha in his article - with which point, despite my respect for the author, I disagree very strongly,
There is no ‘us’ versus ‘them’. The survivor bias term is condescending, sorry to say. What I recognise in most of the posts by “survivors” and in my own attitude is the desire to preserve Meteor’s status as a reactive, real-time full-stack framework. Whatever its components.
If there is a technology that needs to be left behind, I doubt anyone would complain much if there’s a migration path. What we want to avoid is Meteor whittling down to nothing more than an enhanced Parcel. I want to be building apps with Meteor, not stitching them.
I hope Tiny recognises the value in offering a full stack version, as well as separate components (e.g. the build tool), to grab as large an audience as possible.
I put survivor in quotes because the word here very loosely applies. The concept is however very applicable. Meteor as a platform has lost developers over time. So therefore, weather or not the word “survivor” is appropriate, those who remain will inherently have a bias. It’s 0% intended in any condescending way.
The post I made was simply my thoughts. The community at large, Tiny or whomever doesn’t have to agree or take them seriously. I was just presenting them as is. No offense intended.
I think maybe another aspect of the debate is whether you think about the issue in terms of doing what’s best for existing users (preserving Minimongo, maybe Blaze, etc.) or what’s best to gain new users (piggy-backing on the success of GraphQL, React, etc.).
An assumption that I should’ve perhaps voiced more clearly in my post is that in my opinion, there is no future for Meteor without gaining new users. So from my point of view, even if you consider Apollo/GraphQL to be “worse” than DDP/Minimongo (although of course that’s very subjective), that’s almost besides the point because we need to adopt these new technologies anyway just to be appealing to people outside the current Meteor community.
I totally get the idea that we’ll keep Meteor on the same slowly improving path and just let its ease of use and great developer experience speak for themselves, but sadly I just don’t think it’ll work. Outside this community, the perception of Meteor and its assorted technologies isn’t great, and it’ll take something drastic to change this.
It is this type of misconceived reasoning that led to the fiasco of New Coke, now an infamous cautionary tale in business about the perils of chasing popularity and tampering with a successful product.
From the beginning, Meteor has defined itself as an “opinionated framework”.
The Meteor community are those who share its opinions - yes, sometimes with reservations (I include myself in that category) but the level of agreement is far greater than the disagreement.
In our case, Meteor has provided sufficient flexibility to deal with our main difference of opinion (being able to use MySQL instead of MongoDB). Other people have disagreed over the view layer, and Meteor has provided the flexibility to use Vue, React, Angular and others.
Those who don’t agree with Meteor’s philosophy or need its functionality use (or should use) other frameworks.
Likewise, those who believe Apollo & GraphQL are development nirvana should either use Meteor with the Apollo & GraphQL packages or use Apollo & GraphQL standalone.
In all cases, Meteor must remain true to itself and the community who were won over to Meteor, incorporated it into their businesses and rely on it today.
Now with Tiny backing Meteor, I expect more attention to be given to PR, evangelism and keeping online documentation up to date - things that are seen by outsiders like heartbeats.
Us Meteor users have a big part to play by sharing our Meteor success stories outside the Meteor forum. More people need to showcase their Meteor-based solutions and stories of success at technical conferences and developer meetups and events - especially those that concern NodeJS, MongoDB, MySQL, Databases, IoT and WebApps in general. I previously posted about this here.
Well, here in Sydney, Australia the most common reaction I get when I tell other IT people that we use Meteor is: “Meteor? I’ve never heard of that”. I then tell them how much it has done for us.
The upsettig truth is that, yes, Meteor has lost users over the years. However, having witnessed the neverending debacle when Blaze was dropped in 2015, it looked like there was a succession of bad decisions afterwards. Instead of marking the moment as a point of transformation in the life of the framework, MDG made it look, mostly through non-action in some cases, non-communication in others, as if the ship is being abandoned.
Then at some point they simply decided that Meteor the framework is not worth investing in. The rest (FUD, influencers leaving, etc) followed.
