{"action":"created","issue":{"url":"https://api.github.com/repos/babel/babel/issues/2168","labels_url":"https://api.github.com/repos/babel/babel/issues/2168/labels{/name}","comments_url":"https://api.github.com/repos/babel/babel/issues/2168/comments","events_url":"https://api.github.com/repos/babel/babel/issues/2168/events","html_url":"https://github.com/babel/babel/issues/2168","id":99282253,"number":2168,"title":"6.0","user":{"login":"sebmck","id":853712,"avatar_url":"https://avatars.githubusercontent.com/u/853712?v=3","gravatar_id":"","url":"https://api.github.com/users/sebmck","html_url":"https://github.com/sebmck","followers_url":"https://api.github.com/users/sebmck/followers","following_url":"https://api.github.com/users/sebmck/following{/other_user}","gists_url":"https://api.github.com/users/sebmck/gists{/gist_id}","starred_url":"https://api.github.com/users/sebmck/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sebmck/subscriptions","organizations_url":"https://api.github.com/users/sebmck/orgs","repos_url":"https://api.github.com/users/sebmck/repos","events_url":"https://api.github.com/users/sebmck/events{/privacy}","received_events_url":"https://api.github.com/users/sebmck/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-08-05T19:39:15Z","updated_at":"2015-08-05T19:52:16Z","closed_at":null,"body":"**Foreword:** None of this is really set in stone. Feel free to argue and discuss. This is kinda a long issue so I added some gifs, I hear developers love that kind of stuff. This post is also a bit rough, figured it's better to get it out there ASAP, I'll improve it as more feedback is collected. Thanks everyone for your (potential) participation!\r\n\r\n## What is 6.0 going to look like?\r\n\r\n**No internal transformers. None. Zero. Zilch.**\r\n\r\nThis will be coupled with the **removal** of the following options:\r\n\r\n - `whitelist`\r\n - `blacklist`\r\n - `optional`\r\n - `loose`\r\n - `stage`\r\n\r\nAll of these options are redundant when you're manually specifying transformers.\r\n\r\nThis dramatically reduces complexity in the transformer options. Right now there's way too many ways to change the state of a transformer. This will reduce friction and make it easier to reason about what's actually enabled.\r\n\r\nThere's also a **major** problem with including very experimental syntax/transformers in core. If a big change was made to their semantics it would be a breaking change and would require a major version bump of Babel. In the interest of stability and being reactive to changes in the standardisation process, it makes sense to version them independently.\r\n\r\n## When?\r\n\r\n![idk](http://cdn29.elitedaily.com/wp-content/uploads/2014/08/anigif_enhanced-25283-1406070814-1.gif)\r\n\r\nidk whenever\r\n\r\n\r\n## Where will all the current builtin transformers go?\r\n\r\nInto userland plugins.\r\n\r\n## Wont this make it harder to use 6.x like we use 5.x?\r\n\r\nNope! 6.0 will also introduce the concept of **presets**. These are modules distributed via npm that specify a set of options (plugins etc) that will be merged into your main configuration.\r\n\r\n### Recommended\r\n\r\nThis means that the current ES6 to ES5 configuration would be distributed on npm via the `babel-preset-es2015` package. It would have the `index.js` of:\r\n\r\n```javascript\r\nmodule.exports = {\r\n  plugins: [\r\n    require(\"babel-plugin-arrow-functions\"),\r\n    require(\"babel-plugin-classes\"),\r\n    ...\r\n  ]\r\n};\r\n```\r\n\r\nTo use this you'd just specify the following in your `.babelrc`:\r\n\r\n```json\r\n{\r\n  \"plugins\": [\"preset-es2015\"]\r\n}\r\n```\r\n\r\n### Community-specific\r\n\r\nThese can be even more specific. For example, the React community may have an official preset called `babel-preset-react` that will have the following `index.js`:\r\n\r\n```javascript\r\nmodule.exports = {\r\n  plugins: [\r\n    require(\"babel-plugin-jsx\"), // enables jsx syntax\r\n    require(\"babel-plugin-flow\"), // enables flow syntax\r\n    \r\n    require(\"babel-plugin-react-jsx\"), // transforms jsx to flow\r\n    require(\"babel-plugin-flow-comments\"), // transforms type annotations to flow\r\n  ]\r\n};\r\n```\r\n\r\nJust like the `es2015` preset, this could be enabled with the following `.babelrc`:\r\n\r\n```json\r\n{\r\n  \"plugins\": [\"preset-es2015\", \"preset-react\"]\r\n}\r\n```\r\n\r\n## Isn't this a dramatic shift in focus?\r\n\r\nNope, this is a part of the long term vision for Babel and everything has been leading up to this (cue dramatic music). I bought this up in #568 back in January where I said:\r\n\r\n> Ideally I'd like for 6to5 to be a more general JavaScript of the future transpiler. 6to5 already supports Flow/JSX as well as experimental ES7 features so the name isn't even representative of the project in it's current state although it is in how it's widely used.\r\n>\r\n> A JavaScript transpiler based on future standards and specifications, whether ECMAScript or not, I think is an extremely noble goal. I think there's a large use case for 6to5 beyond just ES6. Having an interopable platform to base code transformations on I think is a very powerful idea. This may mean exposing a very feature-rich core that contains transforms or even exposing a public API.\r\n\r\n## What about syntax extensions?\r\n\r\nI'll be holding out on allowing arbitrary syntax extensions for the timebeing. If we're going to do them at all, we're going to do them right. No point half assing a very critical and fragile piece such as syntax extension.\r\n\r\n### But if there's no syntax extensions then how would existing transformer that enable special syntax work?\r\n\r\nSo, the syntax would be implemented in the Babel parser [Babylon](https://github.com/babel/babel/tree/master/packages/babylon), the \"syntax plugins\" would just toggle some parser options via an API. So the actual parser code would still live in Babylon. It's a neat solution until we support syntax extensions properly.\r\n\r\n## Post 6.0 AKA the future future\r\n\r\n![future](https://media.giphy.com/media/KayVJ5lkB84rm/giphy.gif)\r\n\r\n### Way to provide the entire dependency graph to Babel\r\n\r\nAnother thing that I want to provide is a way to give Babel your entire dependency graph. This will allow cross file transformations. It'll allow us to catch more bugs (such as importing something from another module that wasn't exported).\r\n\r\nThis also allows us to simplify code (thus making it more performant) with access to other files. For example, we can drop the module interop output if we know that a file imported is ES6.\r\n\r\n### Minification plugins\r\n\r\nI believe we can do minification better (if not equivalent) as [UglifyJS](https://github.com/mishoo/UglifyJS2). With the potential type information available this has the potential to lead to huge wins. I've already written [quite](https://github.com/babel-plugins/babel-plugin-merge-sibling-variables) [a](https://github.com/babel-plugins/babel-plugin-simplify-comparison-operators) [few](https://github.com/babel-plugins/babel-plugin-dead-code-elimination) [plugins](https://github.com/babel-plugins/babel-plugin-minify-booleans) [already](https://github.com/babel-plugins/babel-plugin-constant-folding) and I believe with some time investment and the help of community plugins we can have a kickass minification pipeline.\r\n\r\n### Optimisation plugins\r\n\r\nBabel plugins put a lot of potential for optimisations on the table. These optimisations fall into two categories:\r\n\r\n#### Unreliable transformations\r\n\r\nThese transformations modify JavaScript semantics, they're pretty dangerous and fairly irresponsible. If you're a small devshop or independent developer it's probably way too risky to do this but if you're a largish tech company then you can weigh the risks and it may come out in favor of doing these sorts of transforms. The engine can't infer these kind of changes, you have to tell it that you don't care.\r\n\r\nWant to assume all function expressions are constant value types and hoist them? Do it via a plugin.\r\n\r\nWant to turn all function expressions that don't use `this` or `arguments` into arrow functions? Do it via a plugin. (Arrow functions are currently faster than normal functions in [Firefox](http://www.jandemooij.nl/blog/2014/04/11/fast-arrow-functions-in-firefox-31/) and likely all other browsers in the future)\r\n\r\nWant to manually inline functions, removing the overhead of adding a frame to the call stack, potentially improving perf even if the function has been JIT inlined? Do it via a plugin.\r\n\r\nWant to lazy load modules, assuming that the order they're imported doesn't matter as they're side effect free? Do it via a plugin.\r\n\r\nYou can kinda see how these assumptions can lead to fairly large wins. You just have to decide whether or not it's a good idea to do them.\r\n\r\n#### Reliable transformations\r\n\r\nThese are transformations that can be done with 100% confidence. These can be performed without possibly breaking any code. With Flow integration and access to the dependency graph a lot of code can be statically inferrable.\r\n\r\nBut don't engines already do these? Different engines do different things. Some optimisations are too heavy for JITs to do but we have a bit more leeway since we're preprocessing offline. We also potentially have access to more information than engines (type annotations) and so can do some smarter things.\r\n\r\n### Performance\r\n\r\n5.x performance has improved **drastically** since 4.x. It could be better though. Performance will never stop being an issue.\r\n\r\nIf there's one part of Babel that is quite slow due to the overhead of JavaScript, there's the potential to provide two implementations of it. A fast version implemented via a native module that's used in Node and a pure JavaScript one that can be used in the browser. If parts of Babel get implemented as native modules there will **always** be a pure JavaScript version available.\r\n\r\n### Async API\r\n\r\n#### Why?\r\n\r\nThis will allow an RPC with a long running server such as Flow. This will allow access to a large amount of type info. This will also allow IO to be done.\r\n\r\n#### What about integrations that only allow a synchronous API?\r\n\r\nA synchronous API will still be available for those limited integrations. If you attempt to use the synchronous API with plugins that have async visitors then an error will be thrown. Most of the systems that Babel has to integrate with are already async so this shouldn't be a concern for 90% of developers.\r\n\r\n### Syntax extensions\r\n\r\nSee [syntax extensions](#TODO).\r\n\r\n## Anything else?\r\n\r\nProbably forgetting something, I'll add more to this issue as I remember and feedback is collected.\r\n\r\n---\r\n\r\ncc everyone"},"comment":{"url":"https://api.github.com/repos/babel/babel/issues/comments/128129073","html_url":"https://github.com/babel/babel/issues/2168#issuecomment-128129073","issue_url":"https://api.github.com/repos/babel/babel/issues/2168","id":128129073,"user":{"login":"glenjamin","id":151272,"avatar_url":"https://avatars.githubusercontent.com/u/151272?v=3","gravatar_id":"","url":"https://api.github.com/users/glenjamin","html_url":"https://github.com/glenjamin","followers_url":"https://api.github.com/users/glenjamin/followers","following_url":"https://api.github.com/users/glenjamin/following{/other_user}","gists_url":"https://api.github.com/users/glenjamin/gists{/gist_id}","starred_url":"https://api.github.com/users/glenjamin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/glenjamin/subscriptions","organizations_url":"https://api.github.com/users/glenjamin/orgs","repos_url":"https://api.github.com/users/glenjamin/repos","events_url":"https://api.github.com/users/glenjamin/events{/privacy}","received_events_url":"https://api.github.com/users/glenjamin/received_events","type":"User","site_admin":false},"created_at":"2015-08-05T19:52:16Z","updated_at":"2015-08-05T19:52:16Z","body":"This all sounds ace! it would be cool to bake-in per-plugin perf profiling from the start, so slow plugins can be identified & optimised/disabled."}}