Live data from Hacker News

The TypeScript Tax

medium.com

41–50 of 120 posts

Re: The TypeScript Tax

#42
post #13

Before I tried Typescript I thought it was just another JS-precompiler... been there done that. I tried Coffeescript, the Closure Compiler, even LispyScript. In the end it wasn't really that much different to plain old JS, just with some syntactic sugar. But when I actually had to use it in a project, I instantly fell in love with it. Not only does it force me to think about the proper scope and type of a function or…

What about Typescript clicked for you that didn't click with the Closure Compiler?

Re: The TypeScript Tax

#43
post #37
post #12

Earlier quoted context omitted.

I don't know where this misconception started, but you can't just run javascript through a typescript compiler. There is a huge amount of valid javascript that is not valid typescript. Try something like `const testVar = {}; testVar.asdf = "asdf";`. Node web frameworks, for example, are based entirely off this ability to monkey-patch the request object.

`const testVar = {}` doesn't mean that the object is immutable, it means that testVar will never point to something else.

He's not saying that TypeScript complains because he thinks TypeScript considers testVar immutable here. TypeScript will complain because it will infer the type of testVar is an object with no properties, and `testVar.asdf = "asdf";` is an attempt to write to a nonexistent property.

Re: The TypeScript Tax

#44
post #16

Articles like this will certainly bring out the pro-Typescript people, so this got me thinking. I'd like to hear from people who tried Typescript and found they didn't like it for any number of reasons. Note I'm not pro or anti myself, I've only just begun playing with it, but would like to hear from all kinds of people.

The article is correct in that it's important to understand that typing your code has a cost - it's not just all magical benefits. Personally (personally - not for everybody) the cost is that it inhibits my initial experimentation. I don't KNOW what types things should be while I'm faffing around researching and experimenting in a new domain.

I'm a huge fan of strongly-typed code, but I like to add the types much later, once all of the pieces are in place and are not in constant change, and mostly as a way to not have to write unit tests. If I type from the start I find I lock in to sub-optimal data structures and get "attached" to them. I already typed them, I don't want to break things!

Also, I live by the "What Would Rich Hickey Do?" school of thought... so when he mandates types in Clojure, I'll switch to TypeScript by default ;)

Re: The TypeScript Tax

#45
post #12

Earlier quoted context omitted.

I don't know where this misconception started, but you can't just run javascript through a typescript compiler. There is a huge amount of valid javascript that is not valid typescript. Try something like `const testVar = {}; testVar.asdf = "asdf";`. Node web frameworks, for example, are based entirely off this ability to monkey-patch the request object.

I'm not sure exactly what you mean by "not valid" but that example is absolutely valid typescript, and will compile perfectly fine.

By default, you'll get "error TS2339: Property 'asdf' does not exist on type '{}'.". Yes, the error can be disabled.

Re: The TypeScript Tax

#46
post #41

I generally wasn't impressed by his work, but learning that Eric Elliot changed his citations to suit his false claims for his article on TDD [1] has made me lose any form of respect for him [1] https://twitter.com/Hillelogram/status/1084991487702691840

I like this guy. It's like he's trying out for HBO's Silicon Valley.

Re: The TypeScript Tax

#47
Yesterday, there was news that Facebook was porting Yarn from Flow to TypeScript for ease of new contributors. That ease is a shared goal of one of my projects, and yesterday I tried porting it as well.

I discovered that in contrast to Flow, TypeScript has horrible errors. Often I ran into errors that would not give much more information than "error" -- no line information, no file information, nothing. One of the causes of such opaque errors was empty Flow-style typecasts, so they were pervasive throughout a large project.

In contrast, Flow has beautiful error messages.

Re: The TypeScript Tax

#48
post #41

I generally wasn't impressed by his work, but learning that Eric Elliot changed his citations to suit his false claims for his article on TDD [1] has made me lose any form of respect for him [1] https://twitter.com/Hillelogram/status/1084991487702691840

[deleted]

Re: The TypeScript Tax

#49
post #47

Yesterday, there was news that Facebook was porting Yarn from Flow to TypeScript for ease of new contributors. That ease is a shared goal of one of my projects, and yesterday I tried porting it as well. I discovered that in contrast to Flow, TypeScript has horrible errors. Often I ran into errors that would not give much more information than "error" -- no line information, no file information, nothing. One of the ca…

Huh? It sounds like a problem with your toolchain, not TypeScript. You should get all of that whenever there's a type error.

Re: The TypeScript Tax

#50
post #41

I generally wasn't impressed by his work, but learning that Eric Elliot changed his citations to suit his false claims for his article on TDD [1] has made me lose any form of respect for him [1] https://twitter.com/Hillelogram/status/1084991487702691840

I cannot describe how infuriating it is to see hacks like this get publicity. Thank you for sharing that link.
Post reply on HN