The Meteor team will focus on improvements designed to work well across the two products, including the addition of IP whitelisting to the Galaxy platform as a service. Meteor wants Galaxy-based developers to spend less time on “plumbing” and more time on features, said Meteor vice president of product Matt DeBergalis.
Meteor’s Apollo data layer project and the Meteor framework, meanwhile, will be decoupled from each other. “Eventually, we expect Apollo will become the standard data layer for all apps, including Meteor,” DeBergalis said. “We’re going to manage that transition for Meteor developers gradually, similar to how we’ve handled the introduction of other maturing technologies into the core Meteor stack like ES2015 modules.”
During the past few months. Meteor has had improved project build times, transitioned to Node.js 4, and unpinned individual package versions from Meteor releases to enable more frequent updates of components. Also, Meteor’s Blaze library for building live-updating user interfaces was split out into a community-led project. Although Blaze is currently a Meteor-only technology, plans call for making it available via NPM.
DeBergalis notes that many Meteor developers may not understand the recent changes and thus stick with the older version that he says has too many trade-offs compared to the new one. The company hopes to convince them to adopt the new version through better education.