Help Tiny: Post Your Most-Wanted Features for Meteor

Realistically, it would be a major footgun for Meteor to reject Apollo/React/Vue. So the only question is whether to continue support & development of DDP/Blaze. Since that support is already in place, it may be possible to do both.

1 Like

Another new post, under a different thread, that fits very well with this perspective: Some Exciting Meteor News

I think it suits under this thread.

Edit: I originally pasted the wrong URL.

After reading a lot of the feedback here I can certainly see the case for the other side of the debate. And there’s certainly very good arguments for it. But I remain a bit skeptical… If MDG didn’t succeed with Meteor then I feel like just doing more of the same but with better marketing might not be enough.

Hopefully I’m wrong though. But I’d be willing to bet that when that “Meteor for GraphQL” does arrive (and I’m sure it’ll arrive sooner or later), it will eat Meteor’s lunch, and conquer a large share of the JavaScript ecosystem at the same time.


Their funding dried up, so they had to pull out/pivot. If they would continue with the energy they were working on before 1.0 release, any issues or shortcomings would simply be blown away with share brute force on all other fronts.

Now one could say that the issues with funding show the issue with technology, but I think this is more a problem of traditional VC models which expect return in few years and not in 10 years, or even they expect a profit and not just to sustain a development team.


Thanks for pointing out. Copy / pasted the wrong URL and didn’t even look.

But is the solution drastically changing the technology, or drastically changing the perception?


Grapher seems to be a wrapper for defining Mongo queries. Even though they strongarmed their way into the Meteor Guide, I think it’s incredibly niche.

Depends on which of those you think is easier/possible

I don’t disagree with you in that it’s niche. My point in that post was, if someone wants Meteor to work with Apollo (which seems to be all the rage these days), that that’s already possible, using the linking package with Grapher.

Really? That is your main criterium? :thinking:

The point is, changing perception isn’t just a matter of investing in marketing. I think changing perception is a very challenging problem and not one to be taken or looked at lightly.

Everyone in this thread is going to have their own perceptions of where to go based on their own needs and experience. I speak from my own point of bias.


The problem is less related to the perception than the lack of knowledge of Meteor. It is paradoxically very positive because there is everything to do for the construction of a positive image.

The fact that the founders never did marketing will help Tiny build an image and a perception.

1 Like

True, Grapher does a nice job of packaging and documenting how to get set up. And to say it’s a wrapper was a huge overstatement on my part. If users like a graphql-like API that’s similar to Mongo’s query API (as I think of it), as well as relational support, and even an ecosystem of other tools around it, then that data stack is a good fit.

1 Like

Grapher is awesome, my only concern is that even its creator stopped using most of its features. Which means most likely we’ll never have updates for that parts. E.g. it’d be awesome to fetch documents from network only when they’re not fetched with the same params/body without having to use apollo.


Any ideas on the best way to change this? does it require installing a local version and modifying the source or are their any flags available?

1 Like

One idea that I would like to try on Meteor build system would be to not re-scan and re-evaluate dynamic modules if they are not changed.

I don’t think Meteor is doing this because I applied dynamic modules broadly in a huge app and the rebuild time still the same.

Would that be very hard? I think we could then cross the file watchers info with dynamic modules info and just re-evaluate the changed ones.

1 Like

We need a official DDP client include minimongo, so we can use any frontend framework with Meteor backend by DDP.

because it is still hard to integrate frontend framework. for example. nuxt. when set up a new project, I want to use meteor as backend. but when integrate the frontend, it always to get limitation and spend lots of time to make it work.

What really worries me is how many different directions people want to take things.

In my opinion what made Meteor so awesome, and why it grew so fast at the beginning was that it was incredibly simple and made it ridiculously easy to get s**t done compared to other frameworks.
What killed it, was when people started overcomplicating things… breaking off bits of meteor to mix with other frameworks, pushing aside Blaze so they could hook up that shiny new React thing - even though React wasn’t designed to work in the same way and it needed a ton more boilerplate.

The community just got fragmented with people all doing things differently, none of it properly integrated or documented, but no-one really giving any love to what was there originally.

Personally I’d like to see meteor return to its roots. A very simple, clean framework with a very low on-ramp, where people don’t need to learn React or Vue or [insert latest front-end craze here] to get started. Blaze was awesome for that and is perfectly capable of making a solid UI. With a bit of TLC it could probably be a lot better too.


Agree… mostly. Meteor should be improved not change drastically how it works now. Improve the core technologies. Since it would be hard for people like myself who still are still learning and using the framework. Maintaining and making it easier to use react and other front-ends frameworks would be nice.Also keep support windows and perhaps improve speed on windows


My two cents,

I am first and foremost an entrepreneur, and I believe that is where Meteor shines. In being a tool that allows you to take an idea and turn it into a product. This has always been the appeal of Meteor, being a straightforward path from idea to execution.

However, an important benefit of being an entrepreneur in this industry, is having a solid backup plan. If my products don’t generate revenue, I can always go get contract work to pay the bills. This is the balance that I feel has kept me in the Meteor community. For me it’s not about the new shiny thing, as some suggest has become an issue here, it’s ensuring that I can use new technologies so my skills remain marketable, whether it’s React, Vue, or GraphQl.

A fundamental product belief of mine, is things don’t need to be simple, they need to be clear. So my Most-Wanted Feature for Meteor is to continue to become more clear, straightforward, yet adaptable.