Hacker News Reader

Comment by BinaryIdiot | Hacker News Reader

This is the main reason why I don't like using languages that transpile into JavaScript. I don't mind the languages themselves but transpiling into JavaScript now means you have to be effective in both languages instead of one to properly debug and you're also subjected to bugs that may or may not be known in the transpile itself.

Everyone seems to hate on JavaScript but it's really not that bad to use.

View on HN

Have you actually tried TypeScript? It feels just like writing JavaScript, but with a thin layer of type annotations that bring you the familiar advantages of static typing.

It seems to me that JavaScript haters would be better off moving to a completely different language, like ClojureScript. TypeScript rather feels like it's made for people who enjoy JavaScript but wish it provided the peace of mind of static typing.

I tried TypeScript for the first time a few months ago and it was a breeze. I felt "fluent" almost instantly and only had to look up the docs a few times. With ES6+ picking up steam, TypeScript-specific features are being replaced by their ES6+ equivalent, so TypeScript is going to feel even more natural going forward.

I think the problem is that everyone freaked out with the angular 1.x to 2.0 changes. The angular team, not wanting to lose the 1.x momentum, decided to attempt to write a 1.x to 2.0 conversion tool. The major hurdle to doing this successfully is reliably interpreting javascript code such that it can be understand and converted by an automated programming. Now imagine if instead, all that code was written in typescript. Such a conversion tool would be arguably more simple.

It would seem that if you want angular to evolve in possibly non-backward-compatible ways, then conversion tools would be a requirement. And this is going to be a simpler task with a typed language.

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.

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

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

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).

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.

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.

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.

Yeah, Babel and the Babel team is great. I got very suspicious of the project after my first experience with it broke perfectly valid code, but after reporting the issue and then another and having them fix it almost immediately they won my confidence back. :)

For production code I'd still stick to a whitelist of features that have been released for at least a month though. Babel is aggressively pursuing ES6 coverage and new features might not have all edge cases covered when they're released. Give them one month though and with their responsiveness it's 90% likely it's going to be fixed.

The same can be said for Babel, and it is actually very simple to predict or retro-engineer the transpilation from ES6 to 5.

Some people really like static type checking.

"You have a problem with JavaScript. You rewrite your entire code base in TypeScript. Now you have two problems."

Wrong, JavaScript is valid Typescript, so you don't have to rewrite anything.

No, JavaScript is not valid TypeScript. This might be a silly example but there are dozens of similar, small JavaScript programs that are not legal TypeScript (for good reason!).

http://crystae.net/2015/01/22/typescript-is-not-a-superset-o...

Try running jQuery's source through the TypeScript compiler some time.

This is a silly thing to say; why would you use TypeScript if you're going to leave everything exactly as it was in JavaScript? Wouldn't want to rewrite it using TypeScript features? Otherwise there would be zero point to TypeScript.

You seem to be unaware of what TypeScript is. TypeScript is more of a high-powered linter than a new language. If you take Javascript and put it in TypeScript mode, most errors are due to variable reuse (x was a number and now a string) or actually an error in the javascript if you're trying to be well typed.

For a certain style of Javascript, making it Typescript is a no-op

Reply on news.ycombinator.com