Up to date as of August 11, 2017
This document describes the high level features the Meteor project maintainers have decided to prioritize in the near- to medium-term future. A large fraction of the maintainers’ time will be dedicated to working on the features described here. As with any roadmap, this is a living document that will evolve as priorities and dependencies shift; we aim to update the roadmap with any changes or status updates on a monthly basis.
Contributors are encouraged to focus their efforts on work that aligns with the roadmap as maintainers will prioritize their time spent reviewing PRs and issues around these contributions. This however does not mean that PRs against other features and bugs will automatically be rejected.
Items can be added to this roadmap by first getting design approval for a solution to an open issue, as outlined by our contributing guidelines. Then, when a contributor has committed to solving the issue in the short to medium term, they can submit a PR to add that work to the roadmap. All other PRs to the roadmap will be rejected.
Tracking pull request: meteor#8728
Upgrading Node will allow Meteor to take better advantage of native support for new ECMAScript features on the server, which should speed up build performance and also improve runtime performance, thanks to performance improvements in Node itself.
Perhaps even more importantly, newer versions of Node support a vastly improved debugging experience. Not only can you use native Chrome DevTools and many other debugging clients (WebStorm, VS Code, etc.) to debug your app (no more node-inspector), but also the Node process runs at full speed while debugging, so you don't have to wait as long for problems to manifest themselves.
React is the most popular way to build UIs in JavaScript today, and a great companion to the rest of the features provided by Meteor. Meteor's zero-configuration environment provides a great opportunity to make features React apps depend on work out of the box. This includes features like:
- Automatic selection of development vs. production build of React (completed)
- Abstraction for isomorphic server-side rendering (ongoing)
- Integration of dynamic imports with React SSR
- Full support for optimized CSS-in-JS features of libraries like styled-components
We think Meteor has a clear set of benefits when compared to other popular React frameworks like Create React App and Next.js.
Tracking pull request: meteor#8728
See above. Developers deserve to use the latest underlying technologies, and Meteor is uniquely able to smooth over any rough edges in early/experimental versions of technologies like Node. A number of developers are already using beta versions of Meteor 1.6 to deploy their apps, because the benefits outweigh the risks for them. Just as Meteor 1.5 climbed to more than 50% usage in less than two months, we expect Meteor 1.6 to become the most widely used version of Meteor soon after its release.
Preliminary solution: meteor#8999
Meteor has depended on Mongo for as long as the Meteor project has existed. However, we care deeply about supporting other data storage systems (especially via GraphQL), and would like to make it possible to avoid using Mongo altogether.
When Meteor 1.3 first introduced a module system based on CommonJS and ECMAScript module syntax, we had to provide a way for developers to migrate their apps from the old ways of loading code, whereby all files were evaluated eagerly during application startup.
The best solution at the time was to introduce a special imports directory to contain modules that should be loaded lazily (rather than eagerly), when first imported.
Most other Node applications work this way by default: every module is lazy, and therefore must be imported by another module, and evaluation starts with one "entry point" module (typically specified by the "main" field in package.json).
It should be possible for Meteor apps to opt into this behavior, and optionally get rid of their special imports directories. The mechanism for opting in will very likely involve putting something in your package.json file that specifies entry point modules for both client and server.
Installing meteor from npm would enable developers to use it as build tool for npm-based projects, and would simplify the Meteor release process by getting rid of the "dev bundle" (essentially the npm dependencies of the command-line tool).
The biggest blockers to this project are
- deciding whether/how to preserve Meteor release versions, and
- changing the API of the package server so that you don't have to download the entire package database locally.
Ongoing
Speeding up page load times will require a combination of new tools for asynchronous JavaScript delivery (code splitting), dead code elimination, deferred evaluation of JavaScript modules, and performance profiling (so that developers can identify expensive packages).
Making it possible to remove (or dynamically load) large dependencies like jquery, underscore, and minimongo will have a significant impact on bundle sizes.
Using Cache-Control: immutable to cache the initial JavaScript bundle will reduce the amortized cost of downloading the initial JavaScript bundle in newer browsers.
Dynamic import(...) benefits dramatically from storing previously-received module versions in IndexedDB, though it may be possible to use IndexedDB in a faster way.
Although Meteor minifies JavaScript in production, and modules that are never imported are not included in the client bundle, Meteor could do a better job of removing code within modules that will never be used, according to static analysis. The static syntax of ECMAScript 2015 import and export declarations should make this analysis easier.
Status: We encourage publishing Meteor-related packages to npm where possible. We are investigating ways to make it possible to move some parts of Meteor core onto npm without making the installation process more complex.
The community has rallied around npm as the de-facto standard package manager for JavaScript. We believe committing fully to npm will strengthen the entire JavaScript ecosystem by removing fragmentation, will benefit existing Meteor developers by making it seamless to use any JavaScript package and increase Meteor adoption by aligning it with JavaScript best practices.
1.3 introduced npm install support along with ES2015 modules. In the future, we would like to transition the Meteor package ecosystem over entirely from Atmosphere to npm. We are still in the early conceptual design phase and expect to update the roadmap once we have a design in place that will underpin further development.
Status: In progress at http://dev.apollodata.com/
We're building a next generation GraphQL-focused data stack for modern applications called Apollo. We believe that this spiritual successor to the data part of the Meteor stack is impactful enough to deserve it's own fully fledged project that is compatible with other languages and frameworks. Apollo is born from the Meteor project and works perfectly with Meteor today.
Apollo is our approach to giving Meteor developers SQL and other database support, the ability to choose between realtime and static data, and improved performance analysis. We are working on providing better tools and documentation for Meteor developers to integrate Apollo into their apps, and welcome contributions in this area. The next priority for Apollo and Meteor is enabling Meteor developers to choose to replace MongoDB entirely with GraphQL on top of other storage engines.
Even though Apollo could eventually be a complete replacement for Meteor’s included Mongo/DDP data stack, you should feel good about Meteor’s existing data system. We are currently open to ideas around performance and stability improvements.
Status: Shipped in 1.5
The banner feature of this effort will be first-class support for dynamic import(...), which enables asynchronous module fetching.
Read the recent blog post for an overview of how this system will work in Meteor 1.5.
Remaining work can be found here, though not all of those ideas will necessarily block the initial 1.5 release.
Status: Shipped in 1.4.2
Rebuild performance refers to the length of time between changing a file in development and being able to reload your app in a browser. After extensive profiling to identify performance hot-spots, and with careful caching of previously completed work, Meteor 1.4.2 takes substantially less time to rebuild most apps, especially larger apps.
Status: Shipped in 1.4
The mongo driver that currently ships with Meteor is old and doesn’t reliably work with connecting to MongoDB 3.2 databases (e.g #6258). We want to update to the latest driver #5763. In addition, we'd like to update the dev bundle to ship with the latest stable version of MongoDB (3.2) #5809 as MongoDB 2.6 will be officially sunsetted at the end of October, 2016.
Status: Shipped in 1.4
We want to be able to update the version of Node that ships with Meteor to 4 and eventually 6 #5124. #6537 lays the groundwork to overcome the main blocker for updating to Node 4, that is, needing to rebuild all existing Meteor packages that contain binary dependencies.
Status: Blaze split into new repository and can be published independently as of 1.4.2
Our plans around the view layer are to maintain strong integrations (along with guidance) with React, Angular and Blaze. We'll make essential fixes to Blaze but most likely won't be adding new features ourselves. We encourage you to help build the features you need at the meteor/blaze repository.
Status: Since this topic was added to the roadmap, we have introduced completely new contribution guidelines that outline exactly how to contribute to Meteor in several ways, including triaging issues, improving documentation, submitting designs for new features, and submitting PRs for bug fixes and improvements. We encourage proposals about how to make the process better via new GitHub issues.
Currently, it’s difficult for external developers to make meaningful contributions to Meteor as there is no clear guidance on what to work on, how best to do that work and signals around what will/won’t get merged. We plan on fixing this by creating tight documentation around how the project is developed (e.g the Swift contribution guidelines) and giving contributors a path towards earning increased privileges that culminate in full commit access. We’re also aiming to move more sub-projects into their own repositories that can be released on their own release schedule and more easily maintained by the community.
For more completed items, refer to the project history here: https://github.com/meteor/meteor/blob/devel/History.md