I would like to highlight this part of the document:
PRs to the roadmap are welcome. If you are willing to contribute please open a PR explaining your ideas and what you would be able to do yourself.
Ideally, every item in this roadmap should have at least two leaders, leaders are people that are interested in the item and would like to help. If you are interested please open a PR including yourself and describing how do you want to help.
We have many different areas for contributions: Core, Cordova, DB, Documentation and include new content for Technologies that we consider first-class citizens in the platform.
Please involve yourself on at least one item and be part of this new chapter of Meteor.
Everybody is qualified to work on Meteor, if you need help deciding the best item for you to be a leader let me know, I can help you choose.
I would like to centralize on Github if possible then we could have one main issue for every topic and then when the PR is started we switch all the discussions to the PR, what do you think?
The road map looks like it has incorporated alot what people have expressed an interest in building on from the earlier posts where feedback was collected, and its a good sign that Ben will still be present and involved but with a chance for other people to help out as well.
We have recently switched our client bundle from Meteor to webpack and reduced the Meteor part to a one-liner that simply loads the webpack bundle.
Using this technique, we already solved most of the points on the new Meteor roadmap (tree shaking, service worker, page load performance, rebuild performance, and hot module replacement). Would it maybe make sense for Meteor to embrace webpack (like it embraced Babel) and save time re-inventing major parts of the wheel?
The great thing about Meteor’s build tool capability, is that is low- to zero-config. Ideally Meteor will get all of these features included and have it continue to be low- to zero-config.
At the same time, I’ve never used Webpack. How long would it take someone starting from scratch to learn webpack well enough to do tree shaking, service worker, page load performance, rebuild performance, and hot module replacement?
Webpack is pretty suitable for zero-config nowadays. The most prominent example might be create-react-app—with all the above features included out-of-the-box.
I guess you can have a hello-world running with near-zero-config with webpack, but for a more real-world example, this appears to be the config for create-react-app.
edit: sorry for derailing the conversation. I think the roadmap looks great, especially with tree-shaking coming up next!
You can eject a create-react-app app for this exact purpose. It gives you access to the dev and prod webpack configs. We had to do this at work almost immediately because at the time you had to to get decorator support.
There is no need for Meteor to embrace Webpack. It sure has it’s drawbacks as well. I just looked at the roadmap and figured that most of the points could be solved by using it. It’s up to Tiny to decide in which direction they want to push Meteor. And implementing tree-shaking, hot reloading, service workers, etc. in Meteor is definitely an option.
I think the PWA Documentation is a great one that was added, without people using meteor to build PWA’s it might be seen as a dated piece of technology in 1-2 years.But If people start using it to build them they can then make public their experiences and help shape the framework (through feature requests, pull requests, blog posts, etc). So that was a smart thing to put on the road map in my opinion
oh do we need this
