Help Tiny: Post Your Most-Wanted Features for Meteor

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 :smiley:
  • 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 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).


Wow, nice work @storyteller!

1 Like

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.


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.


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.


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.


msavin said: Meteor just needs to be modernized, and to be given proper marketing.
I completely agree and I think Tiny has a real skill for that.


Thanks, super fast… 42 points for 142 posts…:blush:

1 Like

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.


I totally agree with you, @sacha, that without new users Meteor will not survive. At the same time, what kind of business can you make out of a… command line bundling tool?

The .NET Framework successful story tells us that there is a lot to gain by delivering a very opinionated system, together with tools, documentation, and professional support.


Also as a continuation of my post above, yes, a transformation and rebranding might be in order.

I still think that providing Meteor as a suite of tools, and with several recommended approaches to building apps, can make a good business. Why not have Minimongo + Tracker + Vue, while in another case you have Grapher (linked to Apollo, say) + React in another. Several boilerplates, documentation, so on.

And all that tied up with the bundling tool, and a nice Galaxy offering, can’t see how it would go wrong.


I want to thank you @sacha for your contribution over the years to Meteor, I’ve started Meteor with your discover Meteor book and also learnt a lot from VulcanJS. Furthermore, you’ve deep insight over the JS ecosystem with your stateofjs surveys, so your opinion has a lot of weight to it. However I’m finding it really hard to agree with you here.

A lot of tech stay in maintenance mode for a very long time, I recall people saying this for GWT/gRPC about 10 years ago and this tech still used today although certainly not growing. With that said, Meteor does have a tremendous room for growth, it started way early within the Node ecosystem and managed to adapt very well, furthermore the NodeJS ecosystem is still growing and attracting more folks from the php land and elsewhere and Meteor is great entry point.

The question is how to move forward and this where I disagree with you. I don’t agree with the assertion that Meteor needs major technical change or adopt react/graphql over blaze or else it will decline . As I said I’m a big fan of Meteor current flexibility and Blaze/DDP/real-time has it’s unique value proposition that Graphql/React simply can’t match. I think the real change need to be in leadership, community management and marketing. Over for the last 3 years, the framework was technically advancing (thanks to Ben heroic work) but there was zero investment in marketing/community management and it was preceded by poor PR communication in 2015 (the infamous we drop blaze post that scared everyone). Either way I think leadership is critical here to settle this debate and align the community going forward.

Meteor has a great opportunity ahead of it, and here is a potential strategy that could lead to growth with zero technical change (needles to stay technical improvement are welcomed specailly HMR and tree shaking).

Again I’m a big fan of your work, so thank you.



Meteor had tried to piggy-back off the growth of other tools, like when they started to support Angular, React, etc. However, I don’t think it did much for them. The people who use React, Apollo, etc, are already comfortable, and prefer to, roll their own stacks.