Did you check the article? The latter part is mostly about ways of getting the benefits of a type system without needing typescript or a build step.

The whole point of static types (well one big reason at least) is to improve the actual code quality.

I don't understand how you think it obfuscates what is actually running in the browser.

Nearly all non-trivial web projects have a build step even if they aren't "web apps". But I agree it would be nice to at least have the option to avoid it. There is a JavaScript proposal going through that should fix that.

> The whole point of static types (well one big reason at least) is to improve the actual code quality.

I have worked on multiple typescript projects that had terrible code quality. Types do not make you write SOLID code.

I find functional programming and well-used functional patterns do result in higher quality code. Typescript’s type system makes writing functional code more difficult. The documentation even recommends against it[1].

IMO typescript is easy to prescribe as a panacea, “just use typescript”, whereas understanding how to write SOLID code takes time.

[1] https://www.typescriptlang.org/docs/handbook/typescript-in-5...

> Types do not make you write SOLID code.

Of course. They are not sufficient but they are necessary.

I wouldn't see point free programming is the same as functional programming. Rust has many functional programming features and no currying.

In fact my experience of OCaml is that point free programming makes the code much harder to read.

My world changed when I started thinking in a strongly typed way (not just using string and number) and representing state changes as different types rather than interpreting than through property values. Once you do that then your code becomes mapping from one type to the next.

For example, if `type ShoppingCart = EmptyCart | LoadedCart` then `addToCart` is just a map from `ShoppingCart` to `LoadedCart`. It makes invalid states impossible to represent and flows become clearer. Add in good FP and composition becomes easier.

I am not against types but I do find typescript’s type system to be deficient. Additionally, functional programming is not incompatible with type systems but typescript’s type system in particular makes it more difficult.

Several of the terrible typescript projects I referred to still used property values to represent state (like your example). Just because every definition has a type doesn’t make it good code. Shitty typed code is still shitty code. My concern is that many in our industry conflate typescript with quality and stop there.

> Shitty typed code is still shitty code

Yes, but it's at least code you can understand, navigate and refactor.

I'm curious which part you find deficient? It's biggest downside is probably being Turing complete but that doesn't make it deficient, rather it's too easy for devs to code incomprehensible types with it.

> Instead of worrying about types, why not worry about the actual code quality?

I'd argue that a sign of good code quality is using types even in languages and contexts where you don't have to.

PHP is technically still a duck-typed language, but the community has embraced its relatively new strict typing features with open arms and the PHP ecosystem is all the much better for it.

Well MS does own Github now, so I'd expect Github to say this.

We can expect no less than for MS to use GitHub for self serving purposes.

Because it gets exponentially harder to reason about untyped codebases the larger they get. "Code quality" is not good enough, there's no way to enforce that. You can statically enforce types, and use linting rules to discourage usage of constructs like "any".

I wrote my first typescript this morning. I was trying to do something weird in React Native, which I've also never used before. I was getting red lines all over my editor. Saved. It hot reloaded anyway and ran the code and such. The errors I was getting were pretty inscrutable. I think that's the nature of untagged unions maybe? Anyways, it didn't actually put up the hard wall I'd expect a type system to do, and with that I wasn't in a dialogue with the compiler to get the types working and thus the program.

I'm half with you. I think TS is only worthwhile in strict mode, as soon as an "any" creeps in all bets regarding safety are off. Same story with trusting values returned from 3rd-party libs - everything needs validation.

But you talk about code quality... Honestly if I've got a tricky task the first thing I'll do now is write the types for it, they'll keep me on the right path.

Example: Next week's job is to add analytics to a codebase (I get all the glamorous tasks - well, actually just all the tasks), and the geniuses with the spreadsheets have come up with like 100 different events to track, each with a selection of sometimes-overlapping properties.

I've done this before in plain JS and it was unpleasant. In TS once I have the types nailed down the rest is easy - and when they inevitably change their minds about something the week after next I just alter the types to match and then follow the errors until it works again.

> Half of all typescript I've seen uses "any"

You're saying that half of the projects you've seen successfully adopted strict typing? And others use an occasional escape hatch, but still try to introduce reasonable typing? That sounds like a success story to me.

“Any” is a switch to disable typescript.

So if you’re using it, you aren’t really using typescript, you’re disabling typescript and saying “I want to write this part in plain JavaScript.”

I agree, I’ll take JavaScript over TypeScript any day. I work on massive codebases and have never had bug related to type safety, or any issues scaling.