Since the Meteor 1.0 release last year, there’s been an incredible pace of innovation in the JavaScript ecosystem, with exciting work in reactive rendering and mobile development taking shape, and a new language specification landing just this month. No other language is moving as quickly or is as well positioned for modern web and mobile app development. Our goal has always been to build the best possible JavaScript application platform, and we’re excited about the next step in that quest to integrate the best parts of the ecosystem and orient them around a modern application architecture, making the best way to build full stack apps in JavaScript.

We’ve also seen thousands of new Meteor apps since 1.0, and heard from many of you about what you’re most excited about and what would be most helpful. So here’s what we’re focusing on in Meteor 1.2:

Universal JavaScript: Adopting ECMAScript 2015 (aka ES6)

ECMAScript 2015, also known as ES6, is going to be huge for the JavaScript community and for JavaScript adoption. The new version of the language is “the best JavaScript we’ve ever had,” with classes, block scoping, and many other additions. We’re excited that it will bring many new developers to JavaScript by addressing the objections that developers from other backgrounds sometimes raise.

We think anyone writing an app in JavaScript should be using ES2015. So we are making ES2015 the official JavaScript of the Meteor platform. Our goal is to make Meteor the best way to use ES2015, and to provide a seamless ES2015 experience across the whole platform and across the client and the server. Meteor 1.2 will be the first step in making that seamless development experience: we’re adding support for all its features except for modules, automatically transpiling JS files with Babel so they work on all of Meteor’s supported devices and browsers, and changing all our examples and documentation to ES2015.

We hope that you’ll make the switch to ES2015 today, especially given how easy this new support makes it. It really is a huge improvement on JavaScript. But if you’re not ready to switch, or want to transition your codebase gradually, you’ll have that option. You can write some parts of your app in ES2015, some parts without, and adopt ES2015 at your own pace.

Special thanks to Ben Newman, Meteor core developer and Ecma TC39 standards committee member, for his leadership in this area.

Reactive Rendering: First-class support for Angular and React

Users expect a reactive and responsive app experience, so it’s not surprising there is significant excitement in reactive rendering frameworks and growing momentum behind options like Angular and React. This is great news for developers using JavaScript, and we want to ensure whether you’re using Blaze, React, or Angular you have a great experience with Meteor.

Meteor goes with Angular/React like peanut butter goes with jelly. Reactive rendering is only part of the solution for a fully reactive app with an ‘Optimistic UI’. Meteor provides everything else that you need to build a complete app, from secure server logic, to a full-stack reactive data system, to PhoneGap build support. And unlike BaaS options, it’s open source.

So Angular and React are joining Blaze as official, supported view layers for Meteor. In fact, the official Meteor tutorial is already available in both Blaze and Angular editions, with React coming soon. For more information on the Angular integration, see the Angular Meteor site. For more on React + Meteor, see our Getting started with React in Meteor page and Sashko’s forum post.

Developer Experience: Faster and more flexible build pipeline

We are always focused on ensuring a great developer experience, which means having a great toolchain. For 1.2, we’re working on making Meteor’s build toolchain faster and more flexible.

Faster is about supporting bigger, more complicated apps, plus ensuring we can accommodate advanced JS build tasks like ES2015 and JSX. And we’re building a sophisticated caching system, so even if there is lots of transpiling happening, Meteor does the minimum number of build steps to get your app up to date.

More flexible is about deeper, richer hooks into the build process for plugin authors. This opens up new opportunities for package authors to extend Meteor, like an awesomely integrated way to do custom Bootstrap builds right from inside your Meteor codebase, or linters (code style checkers) that you drop into your app just by adding a package. It also allows us to fix a long-standing limitation with LESS includes that required an awkward workaround.

This toolchain work isn’t always the most glamorous work, but often has some of the most striking impact in delivering a complete end to end solution that takes care of all of the details and works right out of the box, and the great experience that comes with that.

Timeframe for Meteor 1.2

Meteor 1.2 will ship later this summer. Along the way, you can see our progress and try the new features by following our PRs on GitHub and checking in on the Meteor forums.

Considering the road ahead

Beyond what’s in the box for Meteor 1.2, there are many other areas of focus that we’re investigating.

Integration

SQL. Official SQL support opens up Meteor to another large population of developers. Expect SQL support to be released incrementally, starting with SQL `observeChanges` and building up to Meteor’s customary full-stack treatment.

REST and microservices patterns. We’ll be looking into better ways of working with data that is coming out of existing backend services. This may take the form of core features or it may take the form of connector packages and pattern guidance.

Application Architecture

Building up the stack. We’ll be pulling features such as routing into core and taking a more opinionated stance on how to structure large Meteor apps. These opinions will be optional but available for teams that want them. Our approach here is to look at package popularity on Atmosphere and the production codebases of Meteor Developer Subscription customers, and “pave the cowpaths” — while also providing any necessary new features that would make life easier.

ES15 modules. We will replace Meteor’s homegrown, pre-ES15 namespacing system with shiny, modern ES15 modules. We’re going to try to do this in a way that preserves Rails-style “do what I mean” automatic symbol resolution for developers that want it, while also allowing strict, explicit control of namespacing in situations where that is preferable.

Testing improvements. We plan to move Velocity into core and simplify and streamline it.

Mobile advances. There are many exciting possibilities in the mobile build toolchain, from new technologies like React Native to a wide range of tooling opportunities relating to cross-platform building and debugging.

With your help, we’ll have more to say about these over the coming months.

Getting involved

We want to hear from you. Please let us know what you think on the Meteor forums and chime in on Meteor PRs. The best way to explore most new ideas is to publish an Atmosphere package; check in on the forums to let everyone know what you’re writing and see what others think.