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

The TypeScript Tax

medium.com

Post reply on HN
Print view View original

21–30 of 120 posts

Re: The TypeScript Tax

#21

Post by steadicat »

qwer wrote: post #12
brlewis wrote: post #2

But if you’re in the position of deciding whether or not to use it, you should have a realistic understanding of both the benefits and the costs. Will it have a positive or negative impact? I strongly disagree. You can start using typescript without thinking for a second about what parts of it will be beneficial. Initially you can just run javascript through the typescript compiler and let type inference find some bu…

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 think grandparent was referring to the fact that you can tell the compiler to ignore type errors if you so choose. The TypeScript compiler is perfectly happy to compile the code in your example, if you disable strict type checking and treat type errors as warnings. On top of that, there are simple annotations you can add that let you silence warnings as they come up, e.g. `const testVar: any = {}; testVar.asdf = "asdf";`. This is not too far off from a linter with comments to disable linting when you don't want it. So yes, technically, you can just run JavaScript through a TypeScript compiler.

Re: The TypeScript Tax

#22

Post by DrJokepu »

qwer wrote: post #12
brlewis wrote: post #2

But if you’re in the position of deciding whether or not to use it, you should have a realistic understanding of both the benefits and the costs. Will it have a positive or negative impact? I strongly disagree. You can start using typescript without thinking for a second about what parts of it will be beneficial. Initially you can just run javascript through the typescript compiler and let type inference find some bu…

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.

That's what the --allowJs flag is for.

Re: The TypeScript Tax

#23

Post by seattle_spring »

aphextron wrote: post #15

Here's Eric Elliot, doing his Eric Elliot thing. Pages and pages of beautifully worded, perfectly structured arguments about absolutely nothing. And this month he's a Distributed Systems Expert. More power to this guy for building a brand for himself, but what a load of nonsense.

> Pages and pages of beautifully worded, perfectly structured arguments about absolutely nothing.

I don't know Eric Elliot, but this sentence captures my perception of most "influencers" perfectly.

Re: The TypeScript Tax

#24

Post by thegeekpirate »

qwer wrote: post #12
brlewis wrote: post #2

But if you’re in the position of deciding whether or not to use it, you should have a realistic understanding of both the benefits and the costs. Will it have a positive or negative impact? I strongly disagree. You can start using typescript without thinking for a second about what parts of it will be beneficial. Initially you can just run javascript through the typescript compiler and let type inference find some bu…

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.

Front page of the TypeScript website:

"TypeScript is a typed superset of JavaScript..."

"Use existing JavaScript code, incorporate popular JavaScript libraries..."

You should be able to use --allowJs and have everything compile just fine, otherwise log a bug.

Re: The TypeScript Tax

#25

Post by JohnDotAwesome »

qwer wrote: post #12
brlewis wrote: post #2

But if you’re in the position of deciding whether or not to use it, you should have a realistic understanding of both the benefits and the costs. Will it have a positive or negative impact? I strongly disagree. You can start using typescript without thinking for a second about what parts of it will be beneficial. Initially you can just run javascript through the typescript compiler and let type inference find some bu…

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.

The compiler can most definitely type-check that code. It's up to you whether or not you want to ignore certain types errors. Want to ignore monkey-patching related errors? Filter out all lines from tsc that include TS2339.

Re: The TypeScript Tax

#26

Post by migstopheles »

qwer wrote: post #12
brlewis wrote: post #2

But if you’re in the position of deciding whether or not to use it, you should have a realistic understanding of both the benefits and the costs. Will it have a positive or negative impact? I strongly disagree. You can start using typescript without thinking for a second about what parts of it will be beneficial. Initially you can just run javascript through the typescript compiler and let type inference find some bu…

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.

Re: The TypeScript Tax

#27

Post by int_19h »

Let me save a few minutes of your time. The author of the article believes that static typing is mostly a waste of time. Consequently, in his point-based model, he assigned that particular feature of the language +0.1 points. "Typing overhead", on the other hand, got -3 points. And then, after adding all the points, he unsurprisingly concluded that the overall score is negative.

If you agree with the premise that static typing is a waste of time, you'll probably agree with the rest, but then you're likely not using TS in the first place. If you don't agree, the article is just wrong.

Re: The TypeScript Tax

#28

Post by qwer »

steadicat wrote: post #21
qwer wrote: 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 think grandparent was referring to the fact that you can tell the compiler to ignore type errors if you so choose. The TypeScript compiler is perfectly happy to compile the code in your example, if you disable strict type checking and treat type errors as warnings. On top of that, there are simple annotations you can add that let you silence warnings as they come up, e.g. `const testVar: any = {}; testVar.asdf = "a…

Sure... I guess you're saying that you can use the typescript compiler just fine as long as you turn off literally the only reason for it?

Have you been on a team that adequately managed a list of thousands of warnings, always finding and fixing just the ones that are "important"?

Re: The TypeScript Tax

#29

Post by kiliancs »

For those worried about compile time for large projects, tools like https://github.com/alangpierce/sucrase can go a long way for the transpilation (remove types), while you can use the TypeScript compiler in parallel only for the type analysis.

That said, Sucrase has a number of issues still. Nothing that can't be resolved, but enough to prevent me from using it in a few projects.

Re: The TypeScript Tax

#30

Post by dvlsg »

Findeton wrote: post #19
maze-le wrote: 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…

I would say that there's no Typescript tax. Rather, there's a Javascript tax for Typescript. As in, the shortcomings of Typescript only come from Javascript. Typescript is transpiled to Javascript, so types are not enforced on execution, and that's the only real limitation of Typescript.

Usage of the word "tax" is interesting, too. I'm happy to pay tax if I reap tangible benefits from it / if the "money" is put to good use. I'd say that's the case with typescript.
Post reply on HN