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?
SQL support, 1006 votes
Server-side rendering, 598 votes (already satisfied for people willing to use React, and a main rationale behind the Blaze 2 proposal)
Easy joins in subscriptions, 488 votes
Additional database support, 316 votes (I guess this can be lumped in with #1)
Incremental loading, 313 votes
I know that MDG is considering abandoning the Trello board for something involving waffle.io, 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.