Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we failed, then succeeded, at migrating to TypeScript

heap.io

Post reply on HN
Print view View original

31–40 of 60 posts

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

#31

Post by throwaway_bad »

seieste wrote: 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?

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

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

#32

Post by k__ »

AriaMinaei wrote: post #11
sa46 wrote: post #6

Earlier quoted context omitted.

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

Haha, yes. LiveScript should have won. It were awesome times.

Well, guess it's Reason for me now :D

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

#33

Post by k__ »

AriaMinaei wrote: post #2

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…

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.

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

#34

Post by eropple »

The_rationalist wrote: post #30
eropple wrote: post #9

Earlier quoted context omitted.

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, albei…

What do you think about nominal typing vs structural typing? My friends that have been only used to statically typed, nominal programming languages, thinks this is the worst feature of TypeScript.

I don’t hate nominative typing but TypeScript has definitely coached me towards thinking more about data and operations on data. It does a lot to encourage you to move away from the traditional OOP patterns that make most people dunk on Java.

If I had to directly compare the two I think nominative typing is superior only in the case where you have two identically-shaped (down to the property name) classes that have different semantics. I feel like if you are in this situation you should take a very large step back and re-think your decisions.

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

#35

Post by eropple »

davidjnelson wrote: post #10
gingerlime wrote: post #5

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

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

Dunno about you, but I do all of the things you mentioned, regularly, on a solo project. My test burden is greatly shrunken (getting rid of all those “did I pass sane args?” tests that one needs between modules) and I have much more confidence that I’m not shipping broken stuff.

I don’t think writing TypeScript actually takes longer once you’re practiced and it eliminates entire categories of error. YMMV, of course, but in 2019 it’s hard for me not to think of a new JavaScript project as somewhat unserious.

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

#36

Post by desert_boi »

throwaway_bad wrote: post #31
seieste wrote: 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?

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

There's some Typescript type stuff that can probably get close.

https://stackoverflow.com/a/47914631/1924257

https://stackoverflow.com/a/53229857/1924257

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

#37

Post by yladiz »

pointerpointer wrote: post #26

> Yes, we were adding TypeScript code, but we were adding CoffeeScript at a faster rate. Unsurprisingly. > how do we get our coworkers to buy in to this new paradigm? By forcing them? > and we’re all happy to spend hours figuring out exactly how we’ll set up our TypeScript config. Oh yes what a joy! > our data access layer (“ORM”) is ubiquitous, and most files use it in some way. Use SQL instead, it's better. > We al…

Hey, the reason I downvoted you here was that you is that you basically just quoted parts from the article and simply added dismissals or small jabs, but little truly constructive, and were kinda rude in the last paragraph. Judging by your other posts you can do better than the easy way out. Do you have something constructively critical instead?

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

#38

Post by morelisp »

desert_boi wrote: post #36
throwaway_bad wrote: post #31

Earlier quoted context omitted.

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

There's some Typescript type stuff that can probably get close. https://stackoverflow.com/a/47914631/1924257 https://stackoverflow.com/a/53229857/1924257

I don't agree - the TypeScript code you link is "complicated" because it's modeling complicated types, or implementing higher-order types which need to handle complicated types. And honestly it's not that complicated - an explanation of what RecursivePartial must do maps closely to the type expression ("each key of the partial type is optional, and each value's keys are also recursively so").

This isn't at all close to CRTP or SFINAE, not just because TS/JS lacks the dispatch features necessary, but because in both cases you link it's still just about type declaration. CRTP and SFINAE are both ways to hack the type system to _run_ differently.

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

#39

Post by phamilton »

RangerScience wrote: post #22

AFAIK, Ruby is the only language that people make other languages look like (CoffeeScript) and JS is the only language that people make look like other languages (CS, TS). Are there others? Edit: Well, I guess the JVM would be considered another?

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

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

#40

Post by Waterluvian »

AriaMinaei wrote: post #2

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…

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.

Post reply on HN