First of all in the spirit of Thanksgiving, thanks to MDG and the community for the framework!
Lets discuss what new things people would like in Meteor, and what you don’t want to change.
Current strengths that shouldn’t change -
above all, simplicity and ease of use. It should be the answer to JS ecosystem fatigue
more default convention over configuration
CLI/shell
Features already planned for 1.5 or on the roadmap
newer version of Node
data layer based on Apollo to support other db’s
npm installable
Other new features I’d like
Routing - provide a standard routing solution out of the box
State management - Redux needs a lot of boilerplate. MobX is very similar to Tracker in spirit. MDG can and should come up with a nice solution to this, which integrates with Apollo
SSR
Build system based on webpack - webpack is infinitely configurable (its real drawback), I want ‘meteor build’ to use all its power and do its magic, and do automatic code splitting/above the fold optimizations etc.
Official deployment support (mup/mupx, galaxy, other hosts)
Many of these may already be in planning and I don’t know how they align with MDG priorities or if the community needs to do this.
What I would really like is for MDG to take care of developing and maintain a Meteor debugger VSCode extension that works with all source maps and all languages: ES5, ES6, CoffeeScript, TypScript, Spacebar, Jade and Blaze and basic cloud deployment in a few clicks.
Currently, the only genuine IDE that takes into account the front-end and back-end code integration that is the productivity super-power of Meteor is the cheap but buggy and closed-source Webstorm.
Instead of the never ending rat race for new fancy framework features, how about focusing for a change on tooling the consolidated features which made Meteor popular to begin with?
I for one would be more than happy to pay a higher price than Webstorm for an IDE supporting the specifity of Meteor debugging, testing, build, deployment etc.
Meteor made a very educated decision in not supporting routing by default. They would have had to maintain it
FlowRouter is now pratically the “official” routing library.
For SSR, you can do that with React super easily you have ‘react-dom/server’ npm module. However, I don’t know how would it work with subscriptions.
Official deployment is already supported with Galaxy.
Regarding webpack, I’m not so sure…
What I would like:
Code splitting
Support for micro-service architecture by offering ability to specify entry points on meteor run for client, server, cordova, desktop, etc
