Well said, @arggh 
1 Like
okay. I agree … opinions are the most important. Also, make syntheses, it can be effective for the next steps …
142 posts… I guess this is a good procrastination as any. 
Give me some time guys.
4 Likes
Has Tiny posted anything anywhere about what they plan to do with Meteor? The fact we haven’t seen anything along the lines of “Hey we are Tiny, we love Meteor and want to push it forward.” is making the company I work for consider switching to Nuxtjs/Apollo. Subscriptions would be more work but then would only be used where absolutely necessary.
5 Likes
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.
2 Likes
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.
8 Likes
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.
5 Likes
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! 
4 Likes
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.
13 Likes
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).
31 Likes
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.
6 Likes
“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.
2 Likes
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.
4 Likes
Meteor should be view-layer agnostic. Plugins provide integration with view layers.
This should solve both yours, and illustreet’s concerns.
However, that would require work from Tiny (or someone) to split Blaze out of meteor.
4 Likes
This is not what I was implying.
Ok, then I think you misunderstood what I meant about stopping official support for it. I’m not talking about community support.
Thank you for clarifying.
However…
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.
11 Likes
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.
3 Likes
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.
6 Likes