Hacker News new | ask | show | jobs
by hipsterrific 3746 days ago
JavaScript, IMO, forces the developer to do a lot more defensive coding. All API's have contracts. An add() method that computers two numbers shouldn't expect a JSON object. For that matter, your method's contract shouldn't return an "any" for the same reason that you shouldn't expect "any" as its input.

What TypeScript does is remove the ambiguity of API development for front-end work. Considering I've worked in some big enterprise wide JS projects, TypeScript answers the question "Wtf is this returning?" which lessens my debugging time because I know exactly the type of the object being returned.

Your arguments are actually kind of moot. When you write in Java, you're really just boiling it down to an intermediary language. Should you write it in IL? Why not C/C++? Why not assembly? Shoot, just handout punch cards again and let's get to working. Abstraction isn't the enemy here, it's the value of the abstraction that gives value to it. TypeScript isn't so much an abstraction as a superset but it's static typing alone is worth 1000x over.
1 comments
badminton1 3746 days ago
Defensive coding in JavaScript? That's absolutely not how most libraries are implemented.
link
hipsterrific 3746 days ago
If you're expecting one type and get another, you have to handle it, right? Documentation is important in JavaScript by virtue that code contracts are never enforced due to implicit typing.
link
badminton1 3746 days ago
JavaScript makes this process optional, and it only needs to go wrong once to become a problem.

Personally I saw over a million dollars lost and an entire team laid off after a piece of code started working with a value that was expected to be a number but wasn't.

link
nly 3746 days ago
> If you're expecting one type and get another, you have to handle it, right?

Depends. You could debate the same philosophy wrt C and null pointers. Should you check all your arguments to see if they're null, if the documentation/specification says they should never be null, or accept undefined behaviour and segfault?

In practice, most code assumes everything is checked, sanitized and used correctly at the outer most API boundary.

link