How we failed, then succeeded, at migrating to TypeScript (opens in new tab)

> How easy it is to digest

I’ve not had this experience. I’ve found the ambiguity in coffeescript a maddening adventure in syntax confusion.

- function call syntax doesn’t need parens except if a 0 parameter method

- commas are largely optional both in arrays and function parameters. How do you parse: [f, f(), f a b c]

- implicit returns are a terrible idea.

- the @ syntax refers to either a ‘static’ method or an instance variable depending on the context.

- I have to do a double take for the object literal syntax every time

You just gave me an idea.. because we've shared a similar experience.

I really miss the elegance of Coffeescript. ES6 is great, Typescript is great, but sometimes I feel like I have to visually parse a lot of static cruft to read the essence of the program.

What if one's editor had a toggle hotkey to hide typescript typings. Maybe you could turn it off to visually parse the program real quick, before turning it back on to edit it.

Hmm...

TypeScript is so syntax heavy. But my perspective is that there are costs incurred at time of development and maintenance in return for stability at runtime. And I think the latter is far more important if you're writing production code.

When it comes to experimentation, I love Javascript and Python because of how fast they are to write when you're not thinking hard about types.

Then it's just discipline to know how to promote experiments to production code. TypeScript is beautiful because you can just turn it on and add them in. Same with Python type hints.

If you want the quiet syntax of CoffeeScript and even better type safety than TypeScript, you might be interested in Elm.

https://guide.elm-lang.org/

CS is what happens when you let Ruby devs write JS.

TS is what happens when you let .net devs write JS.

Let's see how that turns out in the long run.

> Reading my old code, I was surprised by how clean it looks. How easy it is to digest. There is a certain sense of calm when your brain doesn't have to process all the visual clutter of a C-style syntax. I miss that.

Indeed, Coffeescript is one of the finest languages I wrote in. Consider that 95% of the time we are reading code, what is the win of TS with a linter? The TS codebases I've worked on really hurt my eyes and brain, and that for some stupid website where type safety hardly makes any difference at all. And all those average web developers I've worked with bragging about type safety while the code they are producing is full of wrong constructs, bad naming, dependent on heavy tooling, etc..

YMMV, but I’m less worried about “clean and fun” and much more worried about rugged and correct. TypeScript makes it easier to unambiguously express intent both inside an application and when talking to external modules. Some parts of the syntax are unfortunate but I care about that a lot less than I do not having my systems break.

I’d switch and I wouldn’t look back. I did switch my focus of learning and use, albeit from Ruby and Kotlin (which is better than nothing but nominative typing is insufficient IMO) to TypeScript, and it was among the best decisions I’ve made in my professional career.

Why do you say "But coffeescript is seeing a bit of a revival"? Many metrics (such as https://github.com/jashkenas/coffeescript/graphs/contributor...) suggest otherwise...

I've written an enormous amount of code in CoffeeScript since 2013, but have been migrating it to Typescript during the last year, after it became very clear that CoffeeScript is a dead end. One thing that helps a lot with all the braces (instead of whitespace) is using prettier. My editor is heavily integrated with prettier, so with the touch of a key my code is always formatted in some (almost) canonical way.

Depends on your team size. 5+ engineers and need to refactor things? Typescript will make those needs far easier. Tooling support is amazing, for things like autocomplete, module import insertion and sorting, symbol renaming, function extraction, linting capabilities, correctness of code after changing designs.

There’s some learning around how to type things, but not too hard and very worth it. Need at least one teammate / leader who has used c++/java/c#/etc. extensively on large codebases to mentor others.

Teams of one, es6 is fine, typescript setup is probably overkill, especially for an mvp.

For me the scale tips heavily towards type safety and tooling of TypeScript. Then again, I wish we didn't have to choose.

If you've learned to appreciate the elegance, expressive power, readability and overall speed of development of Coffeescript, tell me, are you going to drop that for some virtual type safety that doesn't even exist at runtime? There's no way you'll write a medium to large codebase in TS without the use of 'any' or 'undefined', otherwise you'll get completely stuck. Don't believe the hype.

When you are not writing critical code where lives or huge amounts of money depend on, then I'd say stick to Coffeescript. And when you find a type related bug in your code, fix it and write a test so the bug cannot occur again. Otherwise, first check out Elm, Dart and Livescript. TS is really the last on my list, I've had my share of pain there.

> Typescript seems to be approaching C++ levels of syntax

I've been a bit traumatized by C++ so I can't help but see this as a bad thing.

A lot of the insanity in C++ is because template metaprogramming made a lot of micro-optimizations possible. You can use CRTP to achieve static polymorphism. You can use SFINAE for tag dispatch to choose a different algorithm at compile time. You can even fold entire algorithms down to a constant with constexpr.

This is great if you care about low level control of your code, but this is usually premature optimization in the JS world.

Luckily typescript will be immune to this because the types can't affect runtime at all. So far I haven't seen any truly monstrous generics that are so prevalent in C++.

Yes, build times of a few seconds instead of minutes. Easier and more robust "write once, run everywhere". Integrating third party libraries in a matter of minutes instead of hours, sometimes days. Generally much faster prototyping capabilities. And so on.

Yes, because you can't run C++ in the client, while some Node libraries can now use the same code for pre-rendering pages on the server or rendering new pages on the client. This gets you the best of both worlds, where a first load or refresh has the page content baked in like a traditional static site, but once it loads you get faster naetvigation and live content updates.

(WASM and WAPI might eventually let you run WASM-compiled C++ in the client, but there's still a lot up in the air for interop purposes there.)

I routinely bore people with the Abelson quote that programs are written for humans to read and only incidentally for computers to execute.

> It’s always people first, code is a far distant second.

I'm afraid that's kinda political. In order to get the migration successful, hmm.. I assume developers did not have much of a choice, either accept it or leave. You can try to brainwash them by impose your subjective point of view in a friendly way, but in the end it's all about power, that's the untold story.

Lisps exist on all the runtimes. LFE (liso flavored Erlang) is a good example.

Another interpretation would be that a majority still picked Coffeescript out of familiarity and interop issues in their specific codebase. Iteration speed could be comparable or better in Typescript too, we don't know.

Often the reason is as simple as "This file I'm adding to is in coffeescript and I don't want to convert it right now"