A big benefit with static typing is the ability to refactor easily. It takes time to get design and code right, in a way that captures the requirements well as well as code quality. With static typing, you get immediate feedback while you tune your code.

Most of the popular large JS projects have switched (or are switching) to TypeScript (or Flow for React, though they'd have used TypeScript today). So that supports the argument in favor of TypeScript.

I don't know the js world that well, can you provide links that show most js developers use typescript? There are arguments for both. There are still millions of python/php/js/ruby devs and codebases that use dynamic code. It could be that in javascript the gains of types are more felt than in Ruby/Python. '' + [] will raise an error in Ruby and probably python too.

> can you provide links that show most js developers use typescript?

They didn't say most developers had switched, they said most large projects have switched

Tests are a very poor and verbose duct-tapey replacement for succinct and powerful static type information.

Static types massively make it easier to understand new code. I can actually see the structure of the data that's getting passed around, with types.

Huh? tests are there to make sure your code behaves correctly, e.g it works. Don't you do that in static land?

You write tests for things that actually matter ... like you know, testing functionality.

You don't waste time writing tests that simply check if all the arguments received the right type. This is taken care of by the type checker.

Besides, the biggest benefit of types is readability.

I don't see tests as you describe in dynamic languages much. E.G this is how you would test Rails controllers https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/cont... . I don't think its that different than java world.

About 1/3 of the bugs on my current project would have been prevented just by strict null checking alone. I've seen bugs on projects with 100% test coverage that would have been caught by types. Dynamic typing was a mistake.

Are you talking about using Optional or things like that in java? That's pretty recent so you can't say that's a property of a static language. And it brings its own problems with it.

What problems does it bring with it? It's just a tool that automatically tells you where you need to deal with possible null values. It's far easier than trying to catch every possible place this can happen with loads and loads of manually written tests.

Not all static languages give you this but the trend is pretty clear with Typescript, Swift, Kotlin etc.

I can't say the use case for Optional is even well defined https://stackoverflow.com/questions/26327957/should-java-8-g... . I'm no good in java, this is just what I find on the web.

Have you actually worked in a language with good, first-class null handling? I'm not surprised that something tacked onto java very recently is awkward to use but in Swift or Typescript it's much easier than wrapping if foo.nil? calls everywhere and much more effective.

What? The use case for an optional type has been been documented for decades and iirc is sourced from type theory. See it’s usage in Haskell (Maybe type) as one aged example. Also, that stack over flow is pretty well clear on what it should be used for imo.

Not having to go to the code and investigate what the types of am object's fields are. That alone can make TS worth it.

Heck just getting auto-complete on an object's members.

Also any sort of combinator usage or functional programming reminds me of why static typing is so useful.

A few layers of higher order functions / combinators and I don't remember if I have `value` or a `{ value: value }` container (like map vs flatMap). Or which stage of the curry I'm at. Oh right, I'm at foo(a, _, c) but thought I was at foo(a, b, _).

If you can't even remember the last time you've encountered a runtime error, you are by my definition writing trivial code or not writing much code at all.

Yes. I'm part of a long term support team - teams do their work and transition it to me. I support a lot of solutions at once, none of which I've built or been able to spend a significant time getting into the guts of. Having the code do a lot of the investigation for me is incredibly valuable. It helps me quickly build a mental model of the small slice of the code I'm dealing with.

If you need autocomplete for your object, that's a sign your objects are probably a bit too big.

Tests are only as good as the person who writes them. Typescript is just another way to build confidence in your codebase. I have found it to be an invaluable tool in large projects especially on teams with various levels of experience.

Well code in general is only as good as the person who writes it. You can write static code that compiles and doesn't work at all, you still need to test it. Only in static languages testing it become way more complicated.

What are the types of tests you’d need to write in a statically-typed language that are more complicated than their dynamically-typed counterparts?

I don't write much JS/TS anymore but I had a weird relationship with Typescript. I work daily with Swift and sometimes Kotlin and found myself slightly disappointed about the kinds of things that Typescript would let me do, I'm not sure if this is up to the underlying limitations of compiling to JS or that the settings of the project I was on wasn't configured properly. It adds quite a bit of overhead as a dependency when you have to bring in typings and keep these updated then make everything work with tests and storybook etc. It's a huge improvement over Javascript though and it's likely unfair to compare it to those other languages.

I think the future is a strongly typed language like Kotlin/Swift to webassembly on front end, and compiled to Bytecode on back end.

But how often do you forget what properties are required for the config object that is the third argument to your function?

I'm not saying it never happens, I just really need to think hard on when it last happened. You're talking about a method that requires a certain param but doesn't raise an exception if you leave it out and then behaves in a buggy way. Again, not something happening a lot.

Everytime I construct that object I'd have to look up what the fields are, either docs (lol yeah right) or by looking at previous calls.

Bonus if my previous usage was incorrect and I didn't notice and I end up copying that same mistake again and again!

TypeScript saves me probably 15+ minutes a day of just switching back and forth looking up what parameters are needed.

It is a one time tax to make everything I do more pleasant.

btw can't you potentially write methods that receive arbitrary number of arguments in java as well? https://docs.oracle.com/javase/1.5.0/docs/guide/language/var...

You’re referring to a variadic function, which can be written in most modern languages.

The commenter you are replying to is talking about a function of fixed-arity, with a config object with required props. Which props are required? A Typed language will tell you immediately “for free”.