4 ms·

Hi, I'm one of the Babel contributors. I can sympathize the initial fear of transpiling. However, it really is much better than you think. Source maps have mad

Hi, I'm one of the Babel contributors. I can sympathize the initial fear of transpiling. However, it really is much better than you think. Source maps have made big strides in the past year and Babel has excellent support for them. Besides source maps, Babel does a lot to keep the generated code as similar as possible to the input. There are very few features that require complex transpiling. Another neat trick I've learned recently is that when you are debugging in a modern browser that does not require certain features to be transpiled, you can simply blacklist them in Babel and debug them natively. Then when you are deploying you can turn transpiling back on for everything and support every browser. (Note: be careful that you don't blacklist features with buggy implementations) Transpiling is quite nice, and it's very likely that you already do it with something like Uglify or Closure compiler. > npm may eventually support two versions of the same module, which would enable you to deliver libraries as both ES5 and ES6 for Node.js, io.js and client-side module systems that are based on npm. This will actually be necessary in the node environment if we are ever to migrate to ES6+ features without causing breaking changes for module users. ES6 isn't just some nicer syntax/features, it's the future of JavaScript and transpilers are the way we are going to get there.

BinaryIdiot 11y ago
> I can sympathize the initial fear of transpiling. However, it really is much better than you think. Source maps have made big strides in the past year and Babel has excellent support for them. Besides source maps, Babel does a lot to keep the generated code as similar as possible to the input. There are very few features that require complex transpiling. I understand all that but after being bitten by the CoffeeScript transpiler on multiple occasions and Google's closure once, I try to avoid it at all costs. It adds an additional level of complexity to projects (needing to transpile before testing / debugging) and I just don't want to risk it for such little return, in my opinion. I'm sympathetic to the cause of getting more people using ES6 and this is a way to do it today but personally I won't use it until ES6 is native in all of my browser and server targets. > Transpiling is quite nice, and it's very likely that you already do it with something like Uglify or Closure compiler. I've run into an issue with Closure at a point in the past (essentially the optimization to make everything into one statement breaking Opera; that was almost impossible to figure out but thankfully someone else did). But I do use Uglify; I try to limit it to compression only but it still changes things here and there (at least it appeared to; honestly it's been a while since I've dug into that code). Minification, especially without all of the features enabled, should be safer than any other type of transpiler considering it has far less to do and many of the changes should be able to do so without consequence. Even still I do re-run all of my unit tests against minified versions of my code. It also makes me uneasy still but seems to be a necessary evil :) >> npm may eventually support two versions of the same module, which would enable you to deliver libraries as both ES5 and ES6 for Node.js, io.js and client-side module systems that are based on npm. > This will actually be necessary in the node environment if we are ever to migrate to ES6+ features without causing breaking changes for module users. I'm having a hard time believing this will happen. This adds complexity to every module as they now have to maintain an ES6 and an ES5 version should they actually want to use ES6. Yeah they can transpile but they still have two modules to maintain, track bugs in case there is a difference, etc. This is unrealistic in my opinion and I don't get why it's even necessary; simply make a certain version of node be required if you want to use ES6. If users can't do that they'll have to use an older version. Moving to native ES6 on node should happen really quickly compared to the browser space. The browser space is going to be painful.

BinaryIdiot 11y ago

> I can sympathize the initial fear of transpiling. However, it really is much better than you think. Source maps have made big strides in the past year and Babel has excellent support for them. Besides source maps, Babel does a lot to keep the generated code as similar as possible to the input. There are very few features that require complex transpiling. I understand all that but after being bitten by the CoffeeScript transpiler on multiple occasions and Google's closure once, I try to avoid it at all costs. It adds an additional level of complexity to projects (needing to transpile before testing / debugging) and I just don't want to risk it for such little return, in my opinion. I'm sympathetic to the cause of getting more people using ES6 and this is a way to do it today but personally I won't use it until ES6 is native in all of my browser and server targets. > Transpiling is quite nice, and it's very likely that you already do it with something like Uglify or Closure compiler. I've run into an issue with Closure at a point in the past (essentially the optimization to make everything into one statement breaking Opera; that was almost impossible to figure out but thankfully someone else did). But I do use Uglify; I try to limit it to compression only but it still changes things here and there (at least it appeared to; honestly it's been a while since I've dug into that code). Minification, especially without all of the features enabled, should be safer than any other type of transpiler considering it has far less to do and many of the changes should be able to do so without consequence. Even still I do re-run all of my unit tests against minified versions of my code. It also makes me uneasy still but seems to be a necessary evil :) >> npm may eventually support two versions of the same module, which would enable you to deliver libraries as both ES5 and ES6 for Node.js, io.js and client-side module systems that are based on npm. > This will actually be necessary in the node environment if we are ever to migrate to ES6+ features without causing breaking changes for module users. I'm having a hard time believing this will happen. This adds complexity to every module as they now have to maintain an ES6 and an ES5 version should they actually want to use ES6. Yeah they can transpile but they still have two modules to maintain, track bugs in case there is a difference, etc. This is unrealistic in my opinion and I don't get why it's even necessary; simply make a certain version of node be required if you want to use ES6. If users can't do that they'll have to use an older version. Moving to native ES6 on node should happen really quickly compared to the browser space. The browser space is going to be painful.