What About Traceur?
joezimjs opened this issue · comments
I watched the video and it got me thinking:
Traceur already transpiles ES6-ES5 for a LOT of the upcoming features. Wouldn't it be better for Facebook to work with Google to make one tool better rather than developing separate tools? We're experiencing enough tool/library/framework bloat in the JS space. We need to start working together to create singular ubiquitous tools rather than having multiple tools competing for user attention.
I know competition is generally great for driving new ideas but when it comes to free and open source tools, that's not really the case.
The Traceur team has different goals.
One of those goals is completeness of ES6 support, which might seem worthwhile at first, but it leads to a large, monolithic runtime with support for lots of features you don't actually want, making it difficult to evaluate the independent merits of each new feature you choose to adopt. Maybe you already have a module system that works, and you aren't ready to switch to ES6 modules. From my point of view, that modularity is important, but it's also hard to write truly independent transforms, so I understand why Traceur doesn't bother.
Facebook is more concerned with performance than Traceur, because we run transpiled code in production, on facebook.com. The Traceur team describes Traceur as a language prototyping tool, and cautions against using it in production. Facebook only supports an ES6 feature if it can be transpiled into efficient code, whereas Traceur tries to support everything, even if the generated code is verbose and/or slow. It takes a lot longer to develop production-ready features, of course, which is part of the reason Facebook doesn't have nearly as much to show for our efforts so far.
Traceur makes little effort to preserve the formatting of unmodified code. If you play around with their online transpiler, you'll notice comments and idiomatic formatting are stripped from the generated code, which makes debugging the generated code (or just figuring out what line of source code corresponds to the current line of generated code) much harder. Source maps help, but using a tool that supports non-destructive partial source transformation, such as https://github.com/benjamn/recast (which also supports source maps, to be clear) would be even better.
I would challenge your assertion that competition is bad for the community. Since Facebook released http://facebook.github.io/regenerator/, Traceur's support for generator functions has improved in ways that were clearly inspired by that project. For instance, yield expressions can now appear anywhere an expression can appear, whereas previously Traceur allowed yield expressions only on the right-hand side of assignment statements, or as standalone expression statements. You could argue that Facebook should have built Regenerator as part of Traceur, but it would have taken us much longer, and we probably wouldn't have done it the way the Traceur team has ultimately decided to implement those features. Instead, lessons have been shared (in both directions) between our separate implementations, to the benefit of both projects.
Working together is important, but sharing the same goals is even more important. I believe the most productive ecosystem for ES6 experimentation would be one where everyone is working together to develop abstract syntax tree transformation functions for individual ES6 features. The best implementations will be those that produce minimalistic, efficient code, with limited runtime support where it makes sense. I think https://github.com/square/esnext currently shows the most promise in this direction.
Niether Google nor Facebook has this problem space completely figured out, and I very much look forward to productively disagreeing with the Traceur team in the future.