So instead of keeping the old API and treating React as a low-level implementation detail, we want to embrace its strength (the component model and related JavaScript API) and providing on top of it what people like about Blaze (templating / reactivity).
Seriously, don't change the existing API if possible. Not right now. The API isn't perfect, but that doesn't matter. Use the existing API as a baseline; swap out the underlying functionality; and make sure it's feature compatible. It's a classic refactor. It's not as fun and glamorous as producing new functionality or stomping out bugs; but it's the boring, responsible, professional, and trustworthy thing to do. Once Blaze 2 is proven to be feature compatible with Blaze 1, then lets start adding new features in Blaze 2.1 and later.
Meteor 1.2 introduces official support for many features of ECMAScript 2015 (formerly called ES6) on client and server, such as classes and arrow functions, using the popular Babel transpiler. ECMAScript 2015 is the new official standard for JavaScript, and the new features are already being rolled out in web browsers. You can use many new features today, with little to no impact on code size or performance, thanks to source-to-source transforms that turn the JS you write into JS the browser can run.
var test = () => { console.log(this); }
var _this = this;
var test = function () {
console.log(_this);
}
var _this = this:
call at the top of the transpiled code assigned the window object, which obviously already has jQuery, so the selector worked, but is very dodgy. (I think you alluded to this in your talk?)