4 ms·

Not a fan of transpiling; you go from having one language to having to understand two (ish; ES6 isn't entirely different) while only being able to debug in one.

Not a fan of transpiling; you go from having one language to having to understand two (ish; ES6 isn't entirely different) while only being able to debug in one. It's nice people can write in and actually use ES6 today but I really don't think transpiling is worth it. I've been bitten by weird bugs in transpilers before that wasted far too much of my time. > 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. No, please no. Why would I ever want to deliver a library in both modes just for some better / different syntax? Yes ES6 is nicer than ES5 but doubling the modules isn't worth it at all.

AdamCraven 12y ago
You can debug in both ES5 and ES6 using source maps. The support is very good. You're working in ES6 land most of the time.
cnp 12y ago
I may be wrong, but I feel the anti-transpile crowd hasn't done their research. Comments in this vein have been popping up for years and have been resolved for years. Check out the transpiled Babel code -- it's what you would expect, and sourcemaps take you the rest of the way.
- BinaryIdiot 12y ago
  I've used source maps before but they're not nearly as good or intuitive as simply debugging ES5. Too much of a pain in the ass in my opinion. I just don't see the value of adding an additional layer of possible bugs / issues just so I can use a little bit better syntax; I'd rather wait until more things get updated with the native implementation. I still think a better solution is some sort of byte code so people can use whatever language they want instead of trying to force JavaScript to be the "byte code of the web".
  - tracker1 12y ago
    It's already been tried several times... and unless the big 3 browser makers (google, mozilla and ms) all support a given approach it just won't happen. JS is for better or worse what we get in the browser, and the subset optimizations for asmjs is probably as good as what we will get broader support for. Transpilation is really the only option... And even using a common bytecode, there will still be a compile step which is separate from the source, and requires mapping to be able to associate the bytecode to the source with the same potential for bugs you are complaining about.
    - BinaryIdiot 12y ago
      > It's already been tried several times... and unless the big 3 browser makers (google, mozilla and ms) all support a given approach it just won't happen. Has it really been tried though? I've never seen more than a few half assed attempts without all parties involved. I've love to see them come together to work something like this out; the web as it exists today isn't nearly as snappy or nice as native apps so I feel like something will eventually change here. Whether that's the help of a bytecode implementation or something else I'm not sure. > And even using a common bytecode, there will still be a compile step which is separate from the source, and requires mapping to be able to associate the bytecode to the source with the same potential for bugs you are complaining about. Yes there is always potential for compilation to introduce bugs but compiling into a bytecode is vasty different from compiling into JavaScript. JavaScript is a functional language with a lot of quirks; Java bytecode and .Net's MSIL, for comparison, are very raw and fast with as few features as possible. It's significantly better to compile into some form of bytecode for later execution than compiling into another human-readable language.
tracker1 12y ago
I've been moving towards having my ES6-style code under `./src`, and having the transpile (and module configured) to `./dist` ... when I want to access the es6 version (say from babel-node, I can simply require `mymodule/src`, which is more direct. Also, if you are creating more discrete modules, the transpile time for a given module isn't bad at all. From a given project, I'm just bringing in `mymodule` and don't have to think about it beyond that... using jsparta, I can test against the es6 version for coverage, etc... and with mappings, the merged/minified JS the client sees can still reference the real starting point. for the most part it's much friendlier when you embrace npm/node workflows with browserify (or webpack). With this in place, you always write/work against your es6-style. I use commonjs module syntax instead of imports, but may change my approach in the future.
- Touche 12y ago
  > I use commonjs module syntax instead of imports, but may change my approach in the future. You use commonjs with es6? Why?
thejameskyle 12y ago
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 12y 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.

AdamCraven 12y ago

You can debug in both ES5 and ES6 using source maps. The support is very good. You're working in ES6 land most of the time.

cnp 12y ago

I may be wrong, but I feel the anti-transpile crowd hasn't done their research. Comments in this vein have been popping up for years and have been resolved for years. Check out the transpiled Babel code -- it's what you would expect, and sourcemaps take you the rest of the way.

BinaryIdiot 12y ago
I've used source maps before but they're not nearly as good or intuitive as simply debugging ES5. Too much of a pain in the ass in my opinion. I just don't see the value of adding an additional layer of possible bugs / issues just so I can use a little bit better syntax; I'd rather wait until more things get updated with the native implementation. I still think a better solution is some sort of byte code so people can use whatever language they want instead of trying to force JavaScript to be the "byte code of the web".
- tracker1 12y ago
  It's already been tried several times... and unless the big 3 browser makers (google, mozilla and ms) all support a given approach it just won't happen. JS is for better or worse what we get in the browser, and the subset optimizations for asmjs is probably as good as what we will get broader support for. Transpilation is really the only option... And even using a common bytecode, there will still be a compile step which is separate from the source, and requires mapping to be able to associate the bytecode to the source with the same potential for bugs you are complaining about.
  - BinaryIdiot 12y ago
    > It's already been tried several times... and unless the big 3 browser makers (google, mozilla and ms) all support a given approach it just won't happen. Has it really been tried though? I've never seen more than a few half assed attempts without all parties involved. I've love to see them come together to work something like this out; the web as it exists today isn't nearly as snappy or nice as native apps so I feel like something will eventually change here. Whether that's the help of a bytecode implementation or something else I'm not sure. > And even using a common bytecode, there will still be a compile step which is separate from the source, and requires mapping to be able to associate the bytecode to the source with the same potential for bugs you are complaining about. Yes there is always potential for compilation to introduce bugs but compiling into a bytecode is vasty different from compiling into JavaScript. JavaScript is a functional language with a lot of quirks; Java bytecode and .Net's MSIL, for comparison, are very raw and fast with as few features as possible. It's significantly better to compile into some form of bytecode for later execution than compiling into another human-readable language.

tracker1 12y ago

I've been moving towards having my ES6-style code under `./src`, and having the transpile (and module configured) to `./dist` ... when I want to access the es6 version (say from babel-node, I can simply require `mymodule/src`, which is more direct. Also, if you are creating more discrete modules, the transpile time for a given module isn't bad at all. From a given project, I'm just bringing in `mymodule` and don't have to think about it beyond that... using jsparta, I can test against the es6 version for coverage, etc... and with mappings, the merged/minified JS the client sees can still reference the real starting point. for the most part it's much friendlier when you embrace npm/node workflows with browserify (or webpack). With this in place, you always write/work against your es6-style. I use commonjs module syntax instead of imports, but may change my approach in the future.

Touche 12y ago
> I use commonjs module syntax instead of imports, but may change my approach in the future. You use commonjs with es6? Why?

thejameskyle 12y ago

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 12y 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.