Meteor Development Priorities


Reading @gschmidt’s post about Blaze 2, my initial reaction was “why is MDG rebuilding something that isn’t broken, when there are so many hotly-desired features that haven’t been built at all yet?” Leaving aside the question of Blaze 2’s design or whether it’s a good idea or not, why is it a top priority, compared to the top-voted requests on the Meteor Roadmap Trello board?

  1. SQL support, 1006 votes

  2. Server-side rendering, 598 votes (already satisfied for people willing to use React, and a main rationale behind the Blaze 2 proposal)

  3. Easy joins in subscriptions, 488 votes

  4. Additional database support, 316 votes (I guess this can be lumped in with #1)

  5. Incremental loading, 313 votes

I know that MDG is considering abandoning the Trello board for something involving, but until they do, or until they make regular announcements on this forum with subject lines like “What MDG is considering for Meteor 1.3” or “What MDG is prioritizing for December” (is it too much to ask for such posts?), the Trello board is all we have to go on. Even when or if it is retired, MDG would be wise to continue to provide a place for the community to vote on their most-desired features. It would also be really nice if said site had a way for MDG to add comments under each feature to regularly update the community about MDG’s progress or lack thereof. Come to think of it, what I’m describing sounds a lot like the Trello board that hasn’t been updated in months. Can that please get updated, at least until its replacement arrives?

But anyway, MDG, where do we stand on at least these top five requests? I saw the post about official SQL support back in August—what’s the update on that? Has anyone given any thought to making joins easier? Wouldn’t that be relatively easy to knock out, at least compared to Blaze 2? And incremental loading is a pretty important feature too, for sites that use Meteor but aren’t apps, and therefore might not want all templates and jQuery plugins and so on loaded on every route or template/component; can incremental loading be hashed out as part of refactoring Meteor to use modules?

I’m all for Meteor to continue developing the future of its view layer, but seeing as that’s refactoring a piece that already has three good options, I would hope that MDG might prioritize some of the database and load-order/modularization features. And please open up about the overall priorities, so the community can weigh in.


Actually with ‘Blaze2’ they will automatically solve:

  • New, object-oriented API for UI components - 281 votes - Nr6 in the list.

So It’s 598 + 281 = 879 votes.


I believe all that MDG would need to show meteor is progressing would be to do a short blog post at the end/beginning of the month with a quick overview what the current priorities/plans are. Of course, an update trello board would also work. A good example is this one by Epic, which gives you an idea when things are going to be worked on:

I agree that is is very, very hard at the moment to see what the priorities are. I’d also love to find out what channels are the right way to work closer with the meteor team.


Yes @chompomonim, but both of those requests are already solved by the integration with React. Blaze 2 simply solves them a second time, albeit with an API that more Meteor developers would prefer. I’m arguing that perhaps building new features should take priority over refactoring already-built ones.


I would love to see votes for consitency. How should we convince clients on infrastructure choices if core Meteor is in doubt or shaking all the time? Why MDG for example not simpy says: “Flow = core” and “Blaze = core, React / Angular is community override” Would make it much easier to pull in the bigger corps as clients. They are leaving now…


That is a very important thing. I can’t understand why Meteor doesn’t show off its activity in a way like that or like that, with weekly/biweekly/monthly post about what’s going on.