Goodbye CoffeeScript, Hello TypeScript

Is it really that important nowadays to build webapps in pure js or abstractions of it? We read articles about how many smartphones get superslow when executing loads of JS code, how broken the development process is and how framework x tries to solve that broken flow. We make use of super heavy and complicated toolchains that are outdated half a year from now. I often hear and read things like: "You still use bower instead of npm?", "You still use coffee script?! Go with TypeScript.", "BackboneJS? Why not go with Angular?". Some requirements make it mandatory to do lots of stuff in the frontend. For example: SoundCloud is supposed to continue playing songs when users navigate around. Okay they need a pure JS page refresh experience. But the standard CRUD admin panel you write 90% of the time? There it's not wrong if a browser does what it is supposed to do. Load a page when a user clicks on a link. Is this such a bad thing to keep things simple?

<p><pre><code> &gt; It’s reasonable to assume &quot;foo bar and hello world&quot; will compile to either: &gt; foo(bar) &amp;&amp; hello(world) &gt; foo(bar &amp;&amp; hello(world)) </code></pre> Feel free to sprinkle in additional operators to increase the clarity and readability of your code. Coffeescript is extreme in what it allows. But even C code can be made more clear by using more operators than the compiler actually demands.<p>I&#x27;m not really trying to come to the defense of Coffeescript here, but I think it&#x27;s worth noting that adding more operators for clarity is a good thing. I even go as far as adding additional variables for clarity, because the names can show what you&#x27;re thinking as you do the computations involved in a complex expression.<p>Although Coffeescript is worse than most, any language will allow you to write expressions that are hard for humans to parse.

<i>&gt;Variable initialization and reassignment are the same It’s easy to accidentally overwrite a variable from a higher scope as a codebase increases in depth. </i><p>Yep. There was a previous July 2013 article and related reddit thread about it.[1] The CoffeeScript compiler devs themselves were bitten by their own strange scoping rules!<p>As to the other question about why people don&#x27;t just write raw Javascript, Eric Lippert explained why plain Javascript is inadequate if you want to do more than just &quot;make the monkey dance&quot;[3] -- a.k.a. &quot;large complex apps&quot;.<p>[1]<a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;comments&#x2F;1j1cw7" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;comments&#x2F;1j1cw7</a><p>[2]<a href="https:&#x2F;&#x2F;github.com&#x2F;jashkenas&#x2F;coffee-script&#x2F;commit&#x2F;7f1088054c91f5ab3bf1ea1098b6ebffaa29a5a9" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jashkenas&#x2F;coffee-script&#x2F;commit&#x2F;7f1088054c...</a><p>[3]<a href="http:&#x2F;&#x2F;programmers.stackexchange.com&#x2F;a&#x2F;221658" rel="nofollow">http:&#x2F;&#x2F;programmers.stackexchange.com&#x2F;a&#x2F;221658</a>

The advantages of CoffeeScript that TypeScript is lacking aren&#x27;t mentioned. I wouldn&#x27;t casually give up lightweight indentation-based syntax and optional parentheses, despite the confusion both can cause. CoffeeScript makes it easy to create small DSLs that are fairly readable. Implicit hashes make for easy keyword-based arguments, only requiring &#x27;-&gt;&#x27; to make a value lazy is a bit better than () =&gt;, and in particular not needing to end a big block of mixed code and data in a random mix of &quot;)}]});&quot; is a surprisingly big win, aesthetically.

If you&#x27;re an analytics shop (presumably) working with streams of events, I&#x27;m going to go out on a limb and say that not picking a functional language (purescript or elm) is a mistake. It&#x27;s fits the domain so well, take a look at the mileage that slamdata are getting out of purescript for example.<p><i>note</i> I&#x27;m being deliberately provocative with the above statement to promote discussion, not argument. :-)

Not trying to sell CoffeeScript here but most reasons of the author for dropping it looks more like a fault of the developer instead of the tool.<p>* Ambiguous syntax? Just add a few parenthesis.<p>* You don&#x27;t like the existencial operator? Learn some JS, being able to easily differentiate between a truthy value and the existence of a variable with a single character is as sweet as it can get.<p>* Comparing a language to Babel? Doesn&#x27;t make sense. Babel translate ES6&#x2F;2015 to ES5 for compatibility. Comparing ES6&#x2F;2015 to CoffeeScript makes sense.<p>* CoffeeScript is the reason you couldn&#x27;t scale&#x2F;solve data syncing or redrawable views? JS&#x2F;CS&#x2F;TypeScript&#x2F;etc have nothing to do with that! Maybe he was thinking about Backbone?<p>Seems like the guy is confusing tools and languages... and making (bad) decisions because of that.<p>Personally I&#x27;m not going back to writing { }, return and ;&#x27;s :-)

Once you go typed JS you don&#x27;t go back.<p>We had a large existing pure JS codebase, so Facebook&#x27;s Flow was a better fit for us. We still have some portions of our code that don&#x27;t have type annotations, and invariably that&#x27;s where the majority of new bugs are introduced. Now we have a policy of making sure all the files we touch are typed, and adding types to a file if it doesn&#x27;t already have it.<p>Types + React is a whole new ballgame when it comes to front end dev.

I&#x27;ve been playing around with typescript and together with IntelliJ it&#x27;s just great... Fast transpiling, easy to config, easy to debug, typed, the list goes on...<p>The only thing that toke me a while to understand at the start was the whole &quot;Definetly Typed&quot; repo, why and how to use it. It is a bit strange to have to add types as you develop but you can live with it after it sits in.<p>There is also Angular 2 which mergers very well with it, friendly advice, try it!

I&#x27;ve been looking into TypeScript recently, but after having clicked on this article, I&#x27;m thinking that I&#x27;ll stick with ES6.<p>Being able to have code completion in javascript is nice, but it&#x27;s also something that you can work around by developing a good work regiment using browser-based debugging tools. The benefit of typescript is substantial, but circumventable. The drawback, one that I haven&#x27;t seen anyone mention yet, is now having to deal with generics inside javascript. Trying to reason about this code and spending most of my cognitive focus on how the author is dealing with generics adds an entirely different complexity to reading and understanding javascript.<p>On one hand, it&#x27;s helpful to have types. On the other, adding a very Microsofty overhead to programming using meta-data on your data and generics inside javascript makes me want to pass on this.

After Coffeescript, it&#x27;s really hard to go back to excess brackets everywhere. I really wish there was a Coffeetypescript.

This is being portrayed as clear code &#x2F; a helpful pattern??<p><pre><code> class GraphQuery extends Query { static parse(object: any): Try&lt;GraphQuery&gt; { return TimeRange.parse(object.over).flatMap((timeRange: TimeRange) =&gt; { return Filter.parse(object.where).flatMap((filter: Option&lt;Filter&gt;) =&gt; { return GroupBy.parse(object.by).flatMap((groupBy: Option&lt;GroupBy&gt;) =&gt; { return new Success(new GraphQuery( filter, groupBy, timeRange )); }); }); }); } }</code></pre>

The biggest advantage of TypeScript is that the output is unminified Javascript that closely resembles the input. In fact, you could show someone the output and convince them that you wrote the Javascript manually (rather than generating it from the TypeScript).<p>This makes it really easy to interop with existing Javascript code, but it also makes it really easy for non-Typescript developers to pick up.<p>For me, learning Typescript was pretty quick, because valid Javascript is already valid Typescript. All I had to do was remember the syntax for (optional) type annotations.<p>Learning ES6 was actually the bigger hurdle, not Typescript.

<p><pre><code> )); }); &#x2F;&#x2F; I }); &#x2F;&#x2F; love }); &#x2F;&#x2F; TypeScript } } </code></pre> Actual code from the article above. Just added comments.

I&#x27;ll never understand why people don&#x27;t just use javascript.

I typically don&#x27;t get into these types of conversations but here we go. CoffeeScript is a lovely language by all means and at my company we use it extensively because it reduces the amount of boiler plate code by a factor of 10 maybe even 20.<p>Here is a simple example:<p><pre><code> some_func = (callback) -&gt; callback new Error &#x27;boom&#x27; some_func (err) -&gt; return console.log err if err console.log &#x27;everything is fine&#x27; </code></pre> The alternative JavaScript version is just too much to read.<p>This makes huge difference when you write async code and no amount of TypeScript can really help it.

Did you also consider Flow[0] as an alternative? I&#x27;m now using ES6 with Babel to build some small side-projects and it has been a great experience. But as the codebase grows, I&#x27;d appreciate to add some Flow type annotations. Typescript looks great but it&#x27;s still not JS. I wonder what will happen to all those compile-to-JS languages once ES6 becomes supported everywhere.<p>[0]: <a href="http:&#x2F;&#x2F;flowtype.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;flowtype.org&#x2F;</a>

I <i>do</i> wish CoffeeScript had stronger type support, however, I don&#x27;t want to give up indentation, optional object brackets, optional function parens and easy loops.<p>There are a ton of other CoffeeScript features I love like the string interpolation syntax, comprehensions, implicit return, @ for this, improved switch syntax, ranges and a ton of other stuff, but I&#x27;m going to hang on to those first four for as long as its practical to do so.

From the cons the author listed for typescript, this article is way too generous with this language. Like CoffeeScript it is just an intermediate solution to the problems JS has. We are still far away from inventing a good language for UI logic development. IMO Elm is pointing in the right direction, Scala.JS is getting some interesting traction and momentum.

Kind of feels like they&#x27;re trying to jump from one popular thing to the next. The JavaScript world is exhausting.

You can have my CoffeeScript when you pry it from my cold, dead hands.

I wonder by Babel was ruled out, in conjunction with Flow. DefinatelyTyped was a game changer for us, as it already has a large repository for popular libraries.<p>But except that, typescript has some catch up to do in terms of typesystem with Flow.

There&#x27;s no need to choose between TypeScript or Babel!<p>You can use TypeScript with --target es6 and then use babel as a secondary transpiler.

Migrating away from CoffeeScript too. I&#x27;ll be happy to have the ternary operator back. The existential operator was handy but became a source of land mines as the project grew. Will miss list comprehensions though.

Why not Haskell? If you&#x27;re going to be transpiling to JS might as well get all the power of purity and robust typing.

Typescript looks great until you realize you need special files that match types in third-part libraries:<p><a href="http:&#x2F;&#x2F;www.typescriptlang.org&#x2F;Handbook#writing-dts-files" rel="nofollow">http:&#x2F;&#x2F;www.typescriptlang.org&#x2F;Handbook#writing-dts-files</a><p>Will your third-party-lib that doesn&#x27;t use Typescript keep a dts file? Who knows...

How about using JavaScript with flow?

Have they fixed the issue where it was really hard to work with third party libraries unless they have type definitions?<p>One problem I saw that it was heard to try out release candidates for React when they were lacking type definitions.<p>Apart from that I really like TypeScript.

After using ES2015 patterns for a while now CoffeeScript looks utterly barbaric in comparison. That said it&#x27;s really for Ruby programmers (or those who know&#x2F;want to know Ruby) who write JavaScript so I guess it will continue to fill that void.<p>It adds no utility outside of that niche anymore however.<p>TypeScript is great but I honestly prefer ES2015&#x2F;ES6 + Flow comments. It means I write native JavaScript (ok, for now a transpile step, but <i>that will go away in time</i> and I&#x27;ll still have valid JS code) but get all the benefits of typing like in TypeScript.<p>However TypeScript is still pretty awesome, though I find the syntax rather verbose.

interesting. we use coffeescript at nootrobox.com, but as you noted, it doesn&#x27;t have a lot of hand rails. many a time, i&#x27;ve run javascript through a js2coffee translator to verify. will look into typescript.

Embrace, extend, extinguish. TypeScript doesn&#x27;t implement ES6 fully.

<a href="http:&#x2F;&#x2F;www.walkercoderanger.com&#x2F;blog&#x2F;2014&#x2F;02&#x2F;typescript-isnt-the-answer&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.walkercoderanger.com&#x2F;blog&#x2F;2014&#x2F;02&#x2F;typescript-isnt...</a> so this blog is arguing typescript is not that good either.<p>Can we have a typescript-alike tool that integrates the &quot;best parts of javascript&quot; and defaults to &#x27;use strict&#x27;? if there is one I&#x27;m in.

&gt; Existential operator accessor (?.) is a leaky abstraction for null<p>I found this out the hard way when using it in groovy a while back. The Options abstraction you describe is better, or the one in Java 8, which Groovy <i>still</i> hasn&#x27;t brought into its syntax. Groovy&#x27;s creator James Strachan talked a lot about how he designed Groovy to avoid the &quot;leaky abstractions&quot; in Java.

Is Typescript a good language for someone that has done very little in Javascript? Are resources available for newbies? I&#x27;ve programmed in dozens of languages over the last 30 years, so I&#x27;m not a beginning programmer, but have simply never messed with Javascript.<p>How does Typescript compare with Dart? Is Javascript the place to start?

If you want to migrate a coffeescript codebase to typescript, try out <a href="https:&#x2F;&#x2F;github.com&#x2F;palantir&#x2F;coffeescript-to-typescript" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;palantir&#x2F;coffeescript-to-typescript</a> which should do it for you automatically

I am trying desperately to understand why TS. How does lumping in the baggage of Java&#x2F;C# onto a functional language like JS make it better?<p><i>We have to wait for the previous generation to retire or die before we can get critical mass on the next idea.</i> - Douglas Crockford

I heard Wikia gave up on TS - wondering why people are leaving TS ? Too much friction ?

Where is the developer community going 2 years from now? I think we can derive some sort of Moore&#x27;s law for new languages&#x2F;frameworks for JS&#x2F;Web&#x2F;Mobile. Objective C and now Swift. Coffee script and now Type script. JS frameworks and more frameworks. What can be the tighter bound Moore&#x27;s law alternative for new frameworks and languages for Web &#x2F; Mobile&#x2F; IOT. It almost always doubles every two years for sure.

Anyone know if TypeScript will ever be included in ECMAScript standard? If it is I will love Microsoft forever.

&gt;Non-mainstream syntax seems like this author already knew what they were looking for from the beginning.