Hacker News Reader

Comment by smegel | Hacker News Reader

The most underrated feature of TypeScript is not the language itself, but the transpiler. With the flick of a switch you can support ES3, ES5 and in future ES6 and beyond - without changing your code (not entirely true, but it is possible to write code that transpiles well to all JS standards).

Decoupling your development from the shifting sands of JS support - across multiple browsers and platforms - is a dream come true, and a good enough reason alone to use TS.

View on HN

Totally agree. After doing a bunch of code with TypeScript (transpiling to ES5 and ES3), I decided to give Babel a try. It took me awhile to set it up properly with the right presets and plugins. It did a fine job transpiling, but I wondered why people just don't use TypeScript. It's so much easier to use.

because I enjoy writing pure JS. Typescript feels like Coffeescript, which always felt like a hack to make Rubyists more comfortable. Similarly TS feels like a hack to make C#'ers more comfortable.

Ultimately, if you're going to program in JS then get comfortable in JS, rather than trying to make JS more like your favourite language.

You can type absolutely pure JavaScript, change the file extension to .ts and still get some of the benefits of the typescript compiler for absolutely free.

That's probably why a lot of people are excited about typescript. It basically is JavaScript, but optionally annotated JavaScript. It's not a new language.

Not when using the billion-dollar-mistake-fixing `--strictNullChecks` flag. :)

Some people like types, other people don't. Some people like indenting with 4 spaces, other like 2. I was a die hard 4 space guy until today, when I was debugging a bunch of 2 space code and decided I like it better.

I have a solution for hardcoded spaces that is sure to blow your mind.

8 charwidth tabs in Go are a sight to behold - what decade is this?

Your editor will however default to 4 charwidth tabs, but you can change this whenever you feel like it and that's the point. It's just a setting, so we can all have our own and then we don't have to argue about it. This morning you like 2 spaces of indent because you can see more code; but this evening you like 8 spaces because the beer makes the code hard to see. It's true that the code appears locked to 8 spaces when you view it in a browser on GitHub (and that's basically why a majority of developers use spaces still in this decade) but you can also change this whenever you feel like it by placing an ".editorconfig" file in the root of your GitHub project, little known fact. In your case, you would simply change the tab width to 2 and then you don't have to commit all your files again and ruin it for everyone who prefers 4. Serious answer.

But if you're going to transpile, why not transpile from a real language, not a Turing tarpit?

(1) The transpiled JavaScript closely resembles the source TS, making debugging easier (source maps allieviete this to a certain extent).

(2) Transpiling from a whole different language means you have to port the standard runtime, otherwise you'd lose portability and familiarity, which are the two key advantages of transpiling from another, widely used language. Also, as JavaScript often runs in the browser this means downloading the runtime.

(3) The more different the two languages are, the more likely you'll run into surprising situations where feature X in language Y cannot be implemented in its original form in JavaScript, causing subtle incompatibilities between Y code written for the "original" Y compiler / interpreter and Y code that was meant to be transpiled.

(4) As someone else mentioned, TS is almost a superset of JS, which means mixing in JS code into TS code is much easier.

(5) What is a real language anyway?

> The transpiled JavaScript closely resembles the source TS, making debugging easier (source maps allieviete this to a certain extent).

High-level languages look nothing like machine code, but we still compile them to it.

> Transpiling from a whole different language means you have to port the standard runtime

That's true, but it's not a reason not to use a good language instead of a horrific one.

> The more different the two languages are, the more likely you'll run into surprising situations where feature X in language Y cannot be implemented in its original form in JavaScript

I contend that any feature of a Turing-complete language can be implemented in JavaScript.

> As someone else mentioned, TS is almost a superset of JS, which means mixing in JS code into TS code is much easier.

'I still get to use JavaScript' doesn't sound very appealing. But, of course, many high-level languages offer an escape to assembler: a high-level language compiling to JavaScript can offer an escape to JavaScript.

> What is a real language anyway?

Haskell, CaML, Lisp, Python, Go — not JavaScript, though, which is an embarrassment to our profession.

Because you can paste in your favorite JavaScript code snippets and they work without modification. One can gradually add types to a JavaScript project at a pace of your choosing. I think a more interesting question is why add types when there is Facebook's flow. My answer: because flow doesn't help with the refactoring and other IDE tasks.

Ask HN: If TypeScript is so great, how come all notable ReactJS projects use Babel? https://news.ycombinator.com/item?id=12537614

One answer is the strong compatibility story for existing JavaScript libraries. You can use d3 or three.js from TypeScript; that's a big advantage over something like Elm.

Compatibility with JavaScript source (instead of libraries) is a disadvantage. The most dangerous parts of TypeScript are the JavaScript parts: arithmetic, bracket notation, etc.

Elm has ports to interop with javascript. it's really not that difficult

Well Google already did that with Java and GWT, but it never caught on.

I guess TS being a superset of JS itself might be an advantage...otherwise it is still a new language designed for web browser programming unlike Java.

I suppose it is a fair question why they didn't just use C#.

> Well Google already did that with Java and GWT, but it never caught on.

ClojureScript uses the Closure(sic) compiler from GWT to compile Clojure/Java to JavaScript (not that I defend this technological train wreck).

> I suppose it is a fair question why they didn't just use C#.

This would have been superb, but I think Microsoft wanted to show that they "get" web developers; just mentioning C# causes the JS pundit get jittery because someone wants to limit the amount of write-only code he is able to spit out.

What exactly don't you like about ClojureScript? The tooling may be kind of weird (and I believe you're out of date) but once you're set up with figwheel and something like om/reagent/re-frame you start approaching the bottom-up, truly dynamic, interactive approach to building things. Every time I hear stories of "we couldn't scale our JS until we switched to TS" it's always the case of they were developing their JS in IDEs and structured similarly to a Java application, but without having to declare types and having slightly nicer data literals...

>>Closure(sic) compiler from GWT

false.

Closure does not compile java to js and closjurescript does not use any tech from gwt.

Clojurescript compiles to JS itself and then uses the Closure compiler (which is an incredible piece of tech) to compile js to js (not transpile, but actual compile).

There were already open source projects that tried to do this some paid projects, but they never gained traction. Microsoft also had the hind sight of DART and GWT to help point them in the TypeScript direction.

There's also Scala.js, which takes it even further than GWT.

And of course Dart.

> Well Google already did that with Java and GWT, but it never caught on.

Actually it did catch on in the enterprise world, just like Typescript. Will Microsoft be as "dedicated" as Google regarding its language? wait and see.

Just a warning, people said the same thing about coffeescript.

I love TS, and am finding more and more ways to inject it into old codebases. However I remember what happened with coffeescript and am sure to always clearly document my build pipeline in case someone needs to move away from TS in 5 years.

Reply on news.ycombinator.com