0 voters
Keep in mind: a faster build tool (faster rebuilds) is on the way, and the idea behind database integrations is to have it as easy as it is with Mongo.
bumping it for more votes
I had a really hard time with this question. I think for me, what I really wish that Meteor had was a true competitor. I mean, we have feathers, ember, pure node, pure js, etc.
But I think that the kind of specific niche that Meteor fills (data layer, accounts, reactivity, etc.) isn’t really filled by anyone BUT Meteor. Which is awesome from a “we made something awesome that nobody else did” mentality. But from the perspective of MDG and the main consumers of Meteor, obviously this can be a bit of a roller coaster.
As odd as it sounds, what I think I ultimately wish is that there were competing mutations for this niche, allowing us (the lucky consumers of OSS 
) to benefit from a multitude of tested, explored frameworks, instead of just one really revolutionary one 
Totally agree with this - there would be a lot to learn from competitors. I think create-react-app is doing some good stuff though, at least for the UI side!
I feel like the MySQL integration, Oplog Scaling, and Build tool are more reasonable tasks for MDG. The rest of the options seem as if the community should be responsible for such things. Regarding Galaxy, I find your statement somewhat ironic. Galaxy was the “Easy non-insert-anything-here deploys” solution for a plethora of archaic deployment options. It seems like you could go back to things like DO, Heroku, Modulus, etc., but why?
Apollo 1.0 
Thanks for whoever did this: https://www.codetours.xyz/tour/partyparrot/GitHunt-API-code-tour
I would also say,
Better build tool: Allow to separate server side from client side to a point, where i could write two client apps (Admin Panel and Main App), publish them through regular ftp upload and let the server side stay on another node-js-only server.
Only one thing: webpack-blaze
I still wish MDG could return free tier deployment as two-week-life containers for instance.
It was great. An ease of seeing any prototype/test/tutorial you want with one command.
Code splitting by default is cool to. Yet webpack is here and now…
I’d vote for RethinkDB, I kinda love new paths with no overhead.
Let’s not ressurect super old threads though - I’d suggest keeping the discussion in here.
Build tool is of course very important and was biggest pain point for some time but also already worked on. So I voted scaling and performance (second place currently so if MDG is listening it should work on it next). Time for meteor to grow up
Nice poll, but it would’ve been nice to be able to select multiple answers.
Indeed - we abandoned the poor thing in its childhood!
With the build tool, production source maps that could be sent to various services on deploy (without being deployed to production themselves) would be great (recently mentioned here). I also hope MDG pushes the envelope for something past route-based code-splitting (demand-/ config-/feature-based, etc. Not sure what it’s all called, but with the idea that over- and underbundling and/or over- and underfetching of actual code is kept to a minimum.)
Indeed - though I wonder if the real solution is something like Fast-Boot by Ember. We actually want all the code/templates to load upfront for performance, we just don’t like how long that takes to render for visitors.
The one thing I need for Meteor to be usable for me is better offline support with service worker
My wish would be a meteor fully transitioned to npm.
Ah that would be cool. I suspect someone can roll this functionality on their own though?