TypeScript offers a compelling case, however. It often can provide the refactoring superpowers of strong statically typed languages on top of JS, and its brand of structural typing allows for quite expressive, but type safe, programs.

That being said, TypeScript is not sound and obviously in a real TypeScript program you'll eventually touch things that are untyped. But still, getting a different set of trade-offs than "statically typed" and "dynamically typed" is useful. It makes me wish there was something like this for Python (no, MyPy and Pyre are not this. They only provide nominal typing, which is definitely not good enough for everyday Python like Django.)

It's useful having a spectrum types. I personally prefer noImplicitAny in Typescript as that lets me choose which battles to pick and while I often leave more `any` typed things than I would like, I have the `any` keyword as an explicit TODO marker of those places where I gave up, so I can go back and fix them as needed/time permits/tech debt requires.

This is a giant overgeneralization. If you are using Redux, for example, you _can_ easily tell most of the time what functions get called and in what context, because data flow is unidirectional and easy to reason about. If you're using an old massive tangle of spaghetti code, it is much more difficult, yes.

You can have very messy code with an excellent language. You can also have beautiful code with a poorly designed language. Let's do a thought experiments. Have a pool of SWEs fresh out of school. Divide them into groups. Each group is given a language they are not familiar with. The pool of languages will include both commonly regarded good ones, OK ones, and bad ones. Ask the groups to do a middle-sized project for 3~6 months independently. Then we compile the projects, analyze their code quality. If the pool of SWEs are big enough, it will give us some insights.

Forget code complexity. Have each team develop the exact same product in their assigned language, measure how long that takes.

Then play musical chairs and have each team develop a new feature in one of the other teams' project/language. Measure how long that takes.

You can always cherrypick advantages and disadvantages to make a language look "bad", or make another language look "better".

This is true. However, it is more important to evaluate both the quantity and the "quality" of advantages and disadvantages.

For disadvantages, how serious are they, how easy are they to be abused, to creep into the codebase, to be prevented from happening again, etc.

It also depends on the team. If it is a small team of 5 people and they are all excellent engineers, I think whatever languages are fine. The 5 engineers will discuss and decide what features to NOT use, etc. and abide to them. If it is a team of 500 engineers, it will take much more efforts and eductions and much longer to achieve that.

what can you cherry pick from javascript to make it look good?

Comparing with Java or popular languages like those at the top of tiobe?

Lambdas, First class functions, and closures are a great feature missing in basically every other popular language (things like Javas lambdas or function pointers aren't even close in real world use).

Proper tail calls is another feature missing from that list and despite some browsers refusing to honor the spec they ratified, it's still implemented in Safari/javascriptCore, XS6, duktape, node 6-7, etc.

The interplay between js dynamic objects and closures is difficult to describe, but a thing of beauty when fully understood. Object literals are also basically unique to js on that list as well.

There's a lot to love about most languages and JS is no exception.

Data from Stack Overflow Trends says that javascript, python are becoming more popular than Java, C# https://insights.stackoverflow.com/trends?tags=javascript%2C...

None of the languages are new.

Nope. I’ve worked in Java codebases which are much worse than your average js codebases. You could never tell what part of the java code calls which genericized listener. Especially with all the floating xmls and linked annotations. Its not the language, its the design that matters.

The tooling makes up for it -- VSCode, for example. Click to definition, right out of the box. The number of options is too numerous to be listed here. Modern Javascript is as much about the tools as it is about the language, as the writer points out.

If the issue is IDEs you can do all that with WebStorm.

As a matter of fact, you can even use IntelliJ for checking function usages and refactoring in JavaScript.

Even the best IDE cannot do anything about the fact that JS is dynamically typed.

Yes, modern IDE do wonderful thing to help you with JS but they will never be able to match the help they can give with a language that is statically typed.