Top JavaScript Frameworks and Topics to Learn in 2020 and the New Decade | Hacker News Reader

Top JavaScript Frameworks and Topics to Learn in 2020 and the New Decade

medium.com

19 pointsericelliott10 comments

> I stand by my assessment that the TypeScript language may have a low or even negative return on investment. It could hurt rather than improve your productivity, and if you’re already using great bug prevention measures such as TDD, code review, and design review, coding in TypeScript is unlikely to provide a significant bug reduction benefit.

Totally lost me at this line. Yes TDD and code/design review are important but a strong type system absolutely reduces an entire category of stupid bugs. It also makes sure those bugs stay fixed later on when you change a method signature and get immediate feedback on what broke. Recommending to the contrary strikes me as irresponsible and naive.

+1. Another use of type systems that often falls under the radar is as documentation. Coming back or ramping up in a project that's typed is much more straightforward than one that isn't, for a few reasons:

- Types are documentation most editors will allow you to click through, which makes finding definitions much easier, as opposed to just comments.

- Types are documentation that's enforced by the type checker, meaning it's always there. Either the type checker can infer it, so the editor can display it even if the developer didn't write it, or it can't, so it asks the developer to write it.

- Due to the same enforcement as above, types are documentation that never grows stale.

Add to all this the fact good editors can parse and understand this documentation, and use this and provide code suggestions, etc. and it's IMO most often a very worth investment.

This is all true. It's also true of JSDoc (using the TypeScript engine or TernJS with standard JS) - but JSDoc also includes space for human readable descriptions which can be used to auto-generate thorough API documentation. And JSDoc has the advantage of working inline with standard JS.

It has the disadvantage of being annoyingly verbose compared to TypeScript though, so I guess the score here is:

JSDoc: Documentation that stays in sync, powers editor tooling: 1 Works with standard JS: 1 Generates better API docs: 1

TS: Documentation that stays in sync, powers editor tooling: 1 Requires compile-to-JS: 0 Less verbose than JSDoc: 1 WAY more fun to write: 1 Lacks prose descriptions for documentation: 0

JSDoc: 3 TypeScript: 3

I love JSDoc but it has the fatal flaw of being optional. It requires human discipline which, when your boss is breathing down your neck to get that feature out, you aren't gonna do. Same goes for robust tests etc. TS is self documenting even if it's less verbose you'll get more coverage overall in your system and maybe have some hope of being able to to back and write those JSDoc comments later. You also don't have to write as many tests as you can be somewhat assured of data integrity since you've defined a robust contract.

TypeScript annotations are also optional.

In my experience, TypeScript does not reduce the number of tests you need to write.

Well yes and no. Even if you don't add any type annotations you still get some implicit type safety. You have to opt out with an Any type of something to totally turn that off.

Our experience is different with tests.

The TypeScript engine in VS Code does the same type inference for standard JS, and automatically downloads d.ts typings for libraries you use to enhance it.

If you follow the link in that reference, you'll see that the claim that TypeScript does not reduce bugs much is backed up by 4 independent sources.

My claim comes from having built large scale systems with and without TS. I have the scars from working without it and I'll never do it again if I can help it. I'll also say that it's possible to write bad buggy code no matter what tooling you use. It's a "pit of success" thing for me. I want to at least make sure the super dumb stuff doesn't make it through.

IMO you should use all the TDD, documentation, and code/design review in ADDITION to a type system.

Yeah. I've done that, too, and TypeScript certainly can catch up to 20% of the public bugs on GitHub. But I find that after all the other measures I use (particularly TDD and code review), there just aren't many type-related bugs left to catch (very near zero).

Mileage can and does vary. Airbnb noted a significant benefit from TypeScript. I suspect you could reproduce Airbnb's results if you had a good design review process and poor test coverage.

Lots of people share your views. A lot of people love using TypeScript because it feels satisfying and the intellisense you get with it is really nice. I'm not saying anybody is wrong for feeling that way -- only that on the projects we used it for, ROI was not good.

Reply on news.ycombinator.com