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

101–110 of 120 posts

Re: The TypeScript Tax

#101

Post by z3t4 »

ng12 wrote: post #10

> Type correctness does not guarantee program correctness. Yeah, obviously. Think about it -- when you write the code you still think about the "types", you're just not writing them down. Typescript's virtues are completely related to developer productivity. Documenting your code with types, better autocompletion, catching silly mistakes before needing to run it in a browser, getting new people up to speed, etc.

One thing I like about JS is that you dont have to think about types. It's an old convention in JS that you should be able to pass anything in and it will figure out what to do - instead of complain. JS has always had a test driven approach - test-code-test-code so you would detect if something is off. But the strictness do of course have trade-offs, for example being fast, easy and forgiving, vs forcing the developer to think hard and give errors if it's not exactly right. For example writing flight control software where an error can mean life or death. Or writing a web game that can be patched in less then five minutes. Maintainability and refactor-ability is all about developer process, it's possible to build a buggy unmanageable mess in a strong/ strictly statistically typed language, just like it's possible to write a fail proof distributed system in plain JavaScript (it's possible but hard in any language and JS might not be the best option).

Re: The TypeScript Tax

#102

Post by z3t4 »

ng12 wrote: post #79
ericelliott wrote: post #76

Earlier quoted context omitted.

I have all those benefits already. The zero point includes inference, lint, design review, spec review, code review, and TDD -- and you can't leave those out safely because 80% of bugs are not type errors.

With TypeScript I can make a change and immediately get a list of every single line I need to update. None of those replace that very key functionality. > and you can't leave those out safely Who's advocating for the replacement of code review, specs, and tests with TypeScript? TypeScript makes these things better, it doesn't replace them.

You can make the life of others more easy by always naming the same thing the same, eg always naming foo.bar foo.bar and you wouldn't need to annotate them, and everyone will know what it is. But if changing something means you also need to modify code at a lot of other places you have a architecture/pattern issue. Such a change should always be a semver major.

Re: The TypeScript Tax

#103

Post by z3t4 »

ericelliott wrote: post #75
cloverich wrote: post #11

I don't think the author adequately addresses the positives of development velocity with Typescript. I find I'm able to read and write code much more quickly with Typescript than without, especially once I am beyond 50-100 loc. I doubt I _ship_ fewer bugs to production, but I certainly catch and fix my own mistakes much more quickly _as I go_, and am able to make more ambitious changes much faster when I have types o…

I get the same benefits from my other tooling. Lint and type inference provide real-time feedback similar to TypeScript, and TDD gives me continuous test feedback every time I hit save. That's the zero point on the ROI scale, and while I admit that well annotated TypeScript code does it a little better, it's not better enough to justify the cost.

If you haven't already written an article about your tooling, I think a practical guide would be well received. Not many users are aware of thees tools, which is why TypeScript is so amazing. I don't think most TS users use it because they like to annotate things, they use it because the autocomplete and editor integrations.

Re: The TypeScript Tax

#104

Post by z3t4 »

wanted2 wrote: post #62
geist wrote: 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.

Typescript projects definitely give me the most pain. You regularly end up to the point you have to resort to 'any' after hours of looking for a stupid type definition. IMAO it's just one big waste of time, just landed a job with a good old JS codebase, what a relief. TS might help for junior and medior developers so they make less mistakes. But I'm pretty sure if you can code Javascript well Typescript only stands i…

Most developers coming new to JS are Java and C# developers. They want to keep their old tools, and methods. And Microsoft want to keep selling it to them. Which is my main concern, once you're in you are locked in.

Re: The TypeScript Tax

#105

Post by z3t4 »

ng12 wrote: post #97
wanted2 wrote: post #62

Earlier quoted context omitted.

Typescript projects definitely give me the most pain. You regularly end up to the point you have to resort to 'any' after hours of looking for a stupid type definition. IMAO it's just one big waste of time, just landed a job with a good old JS codebase, what a relief. TS might help for junior and medior developers so they make less mistakes. But I'm pretty sure if you can code Javascript well Typescript only stands i…

> But I'm pretty sure if you can code Javascript well Typescript only stands in your way when you want to create something. You and the author are both overly concerned about writing code and completely ignoring maintainability. If you write your code once and never touch it again, sure, use plain JS. If you're going to come back in six months month and refactor it or hand it off to a co-worker and expect him to writ…

There's more to maintainability then just adding types. Maintainability is a process not a language.

Re: The TypeScript Tax

#106

Post by z3t4 »

asark wrote: post #63
wanted2 wrote: post #62

Earlier quoted context omitted.

Typescript projects definitely give me the most pain. You regularly end up to the point you have to resort to 'any' after hours of looking for a stupid type definition. IMAO it's just one big waste of time, just landed a job with a good old JS codebase, what a relief. TS might help for junior and medior developers so they make less mistakes. But I'm pretty sure if you can code Javascript well Typescript only stands i…

I just don't like having to look things up, or remember them, or tell someone else about them, or make sure the things I told them or that they told me are still true six months later, or check manually that I haven't typo'd a variable name, and so on and so on, when a machine can do those things for me. The absolute worst case with TS is that I'm as bad off as I would be in JS (use "any", or "as", or provide a dummy…

When dealing with binary packages I have to do stuff like iterating over an object to see what it exposes. I guess typings (if one exist) help a lot there. But for open source code you can just look in the source. Looking at other peoples source code is the best way to learn, so don't let TypeScript take that away for you. The projects with non-existing documentation is often the ones most easy to use. Maybe because the source code is so easy to understand that no documentation is needed :P

Re: The TypeScript Tax

#107

Post by z3t4 »

013a wrote: post #58

My experience with TS is totally on the backend. The biggest issue with typescript, and the reason I'll probably never reach for it for another large project despite having used it for a 50k line+ project, is that it's still, at its core, javascript. We've experienced a tremendous amount of pain because of this. - We've needed libraries which don't provide typescript typings. Like a good little typescript user, we ha…

Defensive programming is very effective in JavaScript. If the state is wrong, log, (core-dump) and restart. Trying to prove correctness statically is not a battle you can win in JavaScript. Instead enjoy getting things done. And let the bugs find themselves, using Murphy's law. For example:

    if(x
If it can happen it will happen. So instead of support getting a call that some customers balance is negative, with defensive programming you not only prevented the bad state from spreading, you can also see why it happened. And fix it asap. Meanwhile if you trusted the static analysis good luck and have fun debugging something after-the-fact that "couldn't" happen.

Re: The TypeScript Tax

#108

Post by seanwilson »

ericelliott wrote: post #99
seanwilson wrote: post #92

Earlier quoted context omitted.

> The study made no effort to determine the quality of the test and review process Assuming you wrote the article, why did you cite that study then? > That means the maximum effect must be less than 20% But what effect are you trying to argue? Maximum of what? I feel this is so vague it's not useful. In my opinion (I'm not going to try to back this up with a study that doesn't measure exactly this), types make an eno…

I get the same real-time error detection and refactoring help from type inference, lint, and TDD. Lint and inference gives me real-time editor feedback, TDD runs automatically on file save. I do consider TDD and code reviews are costly but you can't skip them with TypeScript because at least 80% of bugs are not detectable with TypeScript.

> because at least 80% of bugs are not detectable with TypeScript.

I give up. You're repeatedly using this figure in this thread in a misleading way to make it sound like what you're saying is more legitimate that just an opinion.

The abstract of the study you cite explicitly mentions this is a conservative estimate of effectiveness and ignores bugs detected in private:

> Evaluating static type systems against public bugs, which have survived testing and review, is conservative: it understates their effectiveness at detecting bugs during private development, not to mention their other benefits such as facilitating code search/completion and serving as documentation. Despite this uneven playing field, our central finding is that both static type systems find an important percentage of public bugs: both Flow 0.30 and TypeScript 2.0 successfully detect 15%!

Re: The TypeScript Tax

#109

Post by ng12 »

z3t4 wrote: post #105
ng12 wrote: post #97

Earlier quoted context omitted.

> But I'm pretty sure if you can code Javascript well Typescript only stands in your way when you want to create something. You and the author are both overly concerned about writing code and completely ignoring maintainability. If you write your code once and never touch it again, sure, use plain JS. If you're going to come back in six months month and refactor it or hand it off to a co-worker and expect him to writ…

There's more to maintainability then just adding types. Maintainability is a process not a language.

Yes, and TypeScript is an incredibly powerful tool to make that process easier.

Re: The TypeScript Tax

#110

Post by ng12 »

z3t4 wrote: post #101
ng12 wrote: post #10

> Type correctness does not guarantee program correctness. Yeah, obviously. Think about it -- when you write the code you still think about the "types", you're just not writing them down. Typescript's virtues are completely related to developer productivity. Documenting your code with types, better autocompletion, catching silly mistakes before needing to run it in a browser, getting new people up to speed, etc.

One thing I like about JS is that you dont have to think about types. It's an old convention in JS that you should be able to pass anything in and it will figure out what to do - instead of complain. JS has always had a test driven approach - test-code-test-code so you would detect if something is off. But the strictness do of course have trade-offs, for example being fast, easy and forgiving, vs forcing the develope…

> One thing I like about JS is that you dont have to think about types

This is patently wrong. You _are_ thinking about types. Every object, function, variable you write has a type you store in your head. The question is about how easy it is to remember those types in 6 months, or how hard it would be for a new developer to figure them out.

> JS has always had a test driven approach

Yes, and you should keep that test-driven approach with TypeScript. I'm not sure why anyone would assert otherwise.

Post reply on HN