6 ms·

Transpiling may actually be the safest way to use JavaScript, especially given its rate of change. Take, for instance, a number of features trickling down the E

Transpiling may actually be the safest way to use JavaScript, especially given its rate of change. Take, for instance, a number of features trickling down the ECMA2015 pipe: modules, classes, "let", etc. Using these features without a transpiler, such as Babel, is simply not possible. A transpiler allows you to use these features now without any worry. Not all transpilers may be to your taste, but they have their place.

BinaryIdiot 12y ago
> Transpiling may actually be the safest way to use JavaScript, especially given its rate of change. [..] A transpiler allows you to use these features now without any worry. I disagree and my original statement applies as much to TypeScript as it does to an ECMAScript 6 transpiler. If you want to use the new features and you're transpiling now you need to have a good understanding of the differences between ECMAScript 5 and 6 and you open yourself up to possible bugs in the transpiler. Instead you could just write ECMAScript 5 until 6 is more widely available. Sure no one likes to wait but it requires the least amount of expertise and lower chance of bugs from a 3rd party interfering with your application.
- spion 12y ago
  I feel more comfortable writing TypeScript rather than using an ES6 transpiler, really. The compiler is built really well - you can observe the team's development process on github and I have to say the level is quite impressive (extensive code reviews and great discussions on the issue tracker).
  - hokkos 12y ago
    The same can be said for Babel, and it is actually very simple to predict or retro-engineer the transpilation from ES6 to 5.
  - BinaryIdiot 12y ago
    I'm sure the compiler is well built but stability is my main concern. JavaScript, even with its many flaws, is used by millions of people every day and is one of the most used programming languages in existence. That's a ton of testing through real world use. Since transpilers just compile to JavaScript, they can take advantage of some of the same stability of JavaScript for its output but the act of transpiling is only used by maybe a few thousand users. Sure they'll find bugs and fix them but that's nowhere near the same level as simply writing in native JavaScript (native JavaScript, is that an oxymoron? lol). Besides all that everything ever created has bugs; why risk introducing bugs from a JavaScript engine and from a transpiler when you can risk a single one? As an aside my first and last time using CoffeeScript I ran into an issue that, since this was about two years ago, has already been fixed but at the time it cost me hours of debugging time. It really soured my experience with any transpiler.
    - peferron 12y ago
      You have a very valid point regarding bugs. Transpiler bugs definitely happen. When I first tried using Babel - still named 6to5 then - instead of Traceur, it immediately broke my code because of an incorrect TCO implementation in Babel. Babel's maintainer (sebmck) is insanely responsive and the bug was fixed almost immediately, but still. If I used Babel or any other transpiler for critical production code, I would only enable a whitelist of features that I thoroughly understand: for example, how a fat arrow is translated into a regular function. This vetting would be time-consuming, but that's a price I'd be willing to pay because I enjoy writing ES6 much more than ES5. That's highly subjective though, so I completely understand how some other people would rather just stick to ES5 and get stuff done with the lowest possible risk of weird things happening.
      - zghst 12y ago
        Babel is a completely different transpirer than all the others. It's goal is readable, understandable transpiled code and Sebastian (sebmck) is a genius robot wunderkind. I check the repo everyday and see new updates, bug fixes, etc. It is heartening to see someone give a project so much dedication. I have an affinity for Babel unlike any other JS project (except React). They team works really hard to keep it interesting.
- path411 12y ago
  > Sure no one likes to wait but it requires the least amount of expertise and... I would argue that knowing some of the implementations of features such as module/export/class/extends of TypeScript in native javascript requires a lot more expertise to create coherent OOP code than just opening up TypeScript and using a syntax for OOP that most people are already familiar with.

BinaryIdiot 12y ago

> Transpiling may actually be the safest way to use JavaScript, especially given its rate of change. [..] A transpiler allows you to use these features now without any worry. I disagree and my original statement applies as much to TypeScript as it does to an ECMAScript 6 transpiler. If you want to use the new features and you're transpiling now you need to have a good understanding of the differences between ECMAScript 5 and 6 and you open yourself up to possible bugs in the transpiler. Instead you could just write ECMAScript 5 until 6 is more widely available. Sure no one likes to wait but it requires the least amount of expertise and lower chance of bugs from a 3rd party interfering with your application.

spion 12y ago
I feel more comfortable writing TypeScript rather than using an ES6 transpiler, really. The compiler is built really well - you can observe the team's development process on github and I have to say the level is quite impressive (extensive code reviews and great discussions on the issue tracker).
- hokkos 12y ago
  The same can be said for Babel, and it is actually very simple to predict or retro-engineer the transpilation from ES6 to 5.
- BinaryIdiot 12y ago
  I'm sure the compiler is well built but stability is my main concern. JavaScript, even with its many flaws, is used by millions of people every day and is one of the most used programming languages in existence. That's a ton of testing through real world use. Since transpilers just compile to JavaScript, they can take advantage of some of the same stability of JavaScript for its output but the act of transpiling is only used by maybe a few thousand users. Sure they'll find bugs and fix them but that's nowhere near the same level as simply writing in native JavaScript (native JavaScript, is that an oxymoron? lol). Besides all that everything ever created has bugs; why risk introducing bugs from a JavaScript engine and from a transpiler when you can risk a single one? As an aside my first and last time using CoffeeScript I ran into an issue that, since this was about two years ago, has already been fixed but at the time it cost me hours of debugging time. It really soured my experience with any transpiler.
  - peferron 12y ago
    You have a very valid point regarding bugs. Transpiler bugs definitely happen. When I first tried using Babel - still named 6to5 then - instead of Traceur, it immediately broke my code because of an incorrect TCO implementation in Babel. Babel's maintainer (sebmck) is insanely responsive and the bug was fixed almost immediately, but still. If I used Babel or any other transpiler for critical production code, I would only enable a whitelist of features that I thoroughly understand: for example, how a fat arrow is translated into a regular function. This vetting would be time-consuming, but that's a price I'd be willing to pay because I enjoy writing ES6 much more than ES5. That's highly subjective though, so I completely understand how some other people would rather just stick to ES5 and get stuff done with the lowest possible risk of weird things happening.
    - zghst 12y ago
      Babel is a completely different transpirer than all the others. It's goal is readable, understandable transpiled code and Sebastian (sebmck) is a genius robot wunderkind. I check the repo everyday and see new updates, bug fixes, etc. It is heartening to see someone give a project so much dedication. I have an affinity for Babel unlike any other JS project (except React). They team works really hard to keep it interesting.
path411 12y ago
> Sure no one likes to wait but it requires the least amount of expertise and... I would argue that knowing some of the implementations of features such as module/export/class/extends of TypeScript in native javascript requires a lot more expertise to create coherent OOP code than just opening up TypeScript and using a syntax for OOP that most people are already familiar with.