Live data from Hacker News

How we failed, then succeeded, at migrating to TypeScript

heap.io

11–20 of 60 posts

Re: How we failed, then succeeded, at migrating to TypeScript

#11
post #6

I was looking at some of my old repos today. Enjoyed the nostalgia. Lots of CoffeeScript there. I had to switch to ES and then TypeScript because CoffeeScript was abandoned at the time and I was stretched over other projects to be able to help maintain it. 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…

> 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 ins…

Don't want to invalidate your experience. For me though, I rarely struggled with ambiguity.

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

Function call syntax doesn't require parens so to make multi-line calls punctuation-free. Especially if some args are objects.

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

Well commas are not optional.

> implicit returns are a terrible idea

They're especially elegant in writing declarative code. It takes some getting used to though.

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

Agreed.

These are all tradeoffs though. For me, they struck the right balance between ambiguity (very little) and expressiveness.

LiveScript in comparison was much more sugary (which I preferred): https://livescript.net/

Re: How we failed, then succeeded, at migrating to TypeScript

#12
post #7

I was looking at some of my old repos today. Enjoyed the nostalgia. Lots of CoffeeScript there. I had to switch to ES and then TypeScript because CoffeeScript was abandoned at the time and I was stretched over other projects to be able to help maintain it. 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…

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/

I love Elm. Never got to use it in production though. Can't afford to get even further from the metal :)

Re: How we failed, then succeeded, at migrating to TypeScript

#14

We’re now considering switching from coffeescript to ES6 (or maybe also Typescript). But coffeescript is seeing a bit of a revival, and I’m starting to wonder if we should stick with it?? Tooling seems a bit behind and also lacking things like tree shaking etc (??). But coffeescript is so clean and fun... Any tips/thoughts??

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

Re: How we failed, then succeeded, at migrating to TypeScript

#15
Typescript seems to be approaching C++ levels of syntax and expressiveness. The main difference seems to be the existing tooling, tutorials, libraries, etc for node.js and others.

But if compiled languages like C++ or Go had as many dedicated libraries for webserver management as JavaScript, would there really be a benefit to using Typescript?

Re: How we failed, then succeeded, at migrating to TypeScript

#16
post #3

I was looking at some of my old repos today. Enjoyed the nostalgia. Lots of CoffeeScript there. I had to switch to ES and then TypeScript because CoffeeScript was abandoned at the time and I was stretched over other projects to be able to help maintain it. 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…

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…

Interesting. I sometimes wish to only see the types and get rid of the rest.

Re: How we failed, then succeeded, at migrating to TypeScript

#17
post #15

Typescript seems to be approaching C++ levels of syntax and expressiveness. The main difference seems to be the existing tooling, tutorials, libraries, etc for node.js and others. But if compiled languages like C++ or Go had as many dedicated libraries for webserver management as JavaScript, would there really be a benefit to using Typescript?

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

Re: How we failed, then succeeded, at migrating to TypeScript

#18
> The most important realisation we had going into this renewed effort was that a successful migration has to be centered around people, not just tech.

Key insight. It’s always people first, code is a far distant second. Love Kent Beck’s series on this, so insightful https://medium.com/@kentbeck_7670/software-design-is-human-r...

Great read, Heap team! Thanks for sharing :-D

Re: How we failed, then succeeded, at migrating to TypeScript

#20

We’re now considering switching from coffeescript to ES6 (or maybe also Typescript). But coffeescript is seeing a bit of a revival, and I’m starting to wonder if we should stick with it?? Tooling seems a bit behind and also lacking things like tree shaking etc (??). But coffeescript is so clean and fun... Any tips/thoughts??

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

What would you say are the most useful features of coffeescript?
Post reply on HN