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
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?
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.
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
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.