Returning to JavaScript After 5 Years | Hacker News Reader

Returning to JavaScript After 5 Years

hackernoon.com

14 pointsdictum13 comments

With just a few lines of JavaScript, engineers can move markets, change lives, and build the future.

Either this is exaggerated, or people write incomprehensibly dense JavaScript code.

I feel like if I hadn't written JS in 3 years and was dropped into some JS code today I wouldn't even be able to read it much less code review it adequately. There were a series of months relatively recently where every week I would look at a code review, and be like this is a thing? When did this happen? That said the changes were not exhausting at all. It was like being gifted a new tool, and you were just trying to find a new project to use it on. Now I find myself looking through the TC39 proposals window shopping.

TypeScript is the modern way to 'do' JavaScript. It solves every problem that JavaScript ever had.

It does not solve every problem JavaScript ever had. By definition of being a superset, it's still JavaScript. It just induces a prescription to mitigate symptoms of type unsafeness.

Null AND Undefined still coexist, though type safety helps. There's an idiomatic way to specify classes, as opposed to using a pattern of object returning closure function for instance. There's still both the == and === operators.

A problem beyond type-safety is the confusing semantics of 'this': https://github.com/Microsoft/TypeScript/wiki/'this'-in-TypeS...

The semantics of 'this' in TS are the same as in JS and they're only a problem if you expect TS to be Java rather than JS.

I use the '=>' operator to get a 'this' reference that does what you'd expect (like in Java) by getting whatever object is running rather than the typical JS 'this' of the function. Trivial example is here:

https://github.com/Clay-Ferguson/meta64/blob/master/src/main...

If you want to trade contrarian jabs, I can play that game: TypeScript does far more than 'mitigate symptoms of type unsafeness' it is a fully type-safe language that will get proper compile-time errors if you use the wrong type. It doesn't "mitigate" unsafeness. It ELIMINATES unsafeness.

When comparing the types of function parameters, assignment succeeds if either the source parameter is assignable to the target parameter, or vice versa. This is UNSOUND because a caller might end up being given a function that takes a more specialized type, but invokes the function with a less specialized type.

A Google query for the definition of unsound: "not safe or robust"

https://www.typescriptlang.org/docs/handbook/type-compatibil...

You're portraying TypeScript as if it's perfect. Typescript is is permissive and structurally, rather than nominally typed. This is not TypeScript's fault. There will always be tradeoffs. Among other things in the FAQ, there is a section on how to prevent two types from being structurally incompatible. "A possible FIX if you really want two types to be incompatible is to add a 'brand' member"...

https://github.com/Microsoft/TypeScript/wiki/FAQ#type-system...

The 'assignability rules' of TS catches type-errors in a way that 'solves' all the problems JS ever had. You can critique the nature of that solution if you want (after all, there are an infinite number of solutions in the solution-set), but I think it's a perfect solution.

Give any good developer TS to code in, and he'll know how to use it to check every type in every variable, class, or method parameter, and the checking will be 100% perfectly reliable. That's what I mean by "problem solved".

Google's closure compiler already addressed that

Yeah, that's what I just said.

I like TypeScript but it doesn't come close to solving every problem. You still have floating-point only numerics, bizarre array semantics, crappy Unicode support, nigh-unusable threading, perf optimization is hard, lots more.

If you took a poll of developers about what the problems with JavaScript really are, the things you mentioned wouldn't even make it onto the list.

Imagine how much of a disaster the web would be today if JavaScript allowed threading all these years. All the script-kiddies who have never written one line of back-end code in their lives suddenly having to grapple with concurrency? Oh my god what a disaster.

Reply on news.ycombinator.com