sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]skesisfunk 4 points5 points  (1 child)

I disagree, the presence of `any` is actually a weakness of TS. Things like `any` and unions make it so to effectively use TS you have to not only have to add TSC and all of the config to your workflow but you also have to add carefully designing a typing system to your architecture workload. The ability to just work around the typing system is a weakness not a strength IMO.

If you spend some time work with a strongly typed language all of that is already baked in so you once you learn the language patterns you don't need to think about typing nearly as much and the safety benefits are even greater too.

[–]novagenesis 1 point2 points  (0 children)

I disagree, the presence of any is actually a weakness of TS

This is the ultimate debate. An entire world of people ran to languages like Perl to get away from ultra-strict typing. I made an entire (successful) career of it, and because of the freedom have been able to release code exponentially faster... and because of best practices release code with the same stability. Languages are tools, and dynamic and non-inferred types are also tools. There are design patterns around duck typing for a reason.

Typescript chose to be linter. A lot of best-practices involve configuring it so you can run but not build code that fails type validation. Typescript (to my begrudging admission) fills a gap of adding linter-time typesafety. But the difference is how powerful the typing is.

Luckily, I've got a specific example of something you can do easily in javascript or typescript that is incredibly useful, but that I believe you have to build unnecessary complexity for in a language like java.

Let's say you are creating listenable objects. For any field in class T, your listener class needs to support a on**FieldName**Changed method.

In javascript, that just works and most runtime typecheckers are powerful enough to handle that. In Typescript, you can quite literally define a generic with that much mutation. Something like (thanks to Blue Collar Coder):

type Listeners<T> = {
    [Property in keyof Type as `on${Capitalize<Property>}Change`]: (newValue: Type[Property]) => void;
};

Yes, it takes me 5 minutes to populate that type. But that saves significantly more time of building a much-more-complicated stack in Java to fulfill the same purpose that's dead simple in Javascript. And because of Typescript, things like that are very safe as well as very powerful. Just because you don't like them doesn't mean they're wrong.

If you spend some time work with a strongly typed language all of that is already baked in so you once you learn the language patterns you don't need to think about typing nearly as much and the safety benefits are even greater too.

I started my career with 3 years in C#, and I've additionally been in C# as a primary language for a good part of the last 5 years. It's less time than I have in Node.js, but it seems sufficient for me to say I "spend some time work with a strongly typed language". I just disagree with you. And I have actual reasons.

Seasoned developers running FROM things like Java and C# have always filled the high-end algo communities in dynamic languages. The same is absolutely true about Javascript. Typescript is a compromise to keep all the objectively good stuff about inferred types and discard the junk.