I am in the same boat as the poster. The main reasons I use typescript instead of scala.js are the vast amount of definition files already made (the scala.js translator of these leaves a lot to be desired), and the fact that it's closer to the es6 community which makes maintenance, contributions, and adoption much more likely. So basically because you stay closer to the JS world.

The only downside is lack of "isomorphic" code reuse which I gladly accept anyways because I rarely see server and client side code reuse as beneficial beyond simple models and validation.

I think the biggest advantage is that typescript emits code that is good JavaScript. This means if I decide to stop using typescript, I can just use the generated JavaScript. It also means that there transpiled file is smaller. Using scala.js for a small project wouldn't make sense if you cared about file size at all. It could be worth it more as your project grows, but your then you are that much more commited. There's no exit strategy like with typescript.

I'm always curious where that came from. TypeScript does not emit good JS. It's pretty garbage and not reasonably usable by humans. TS supports ES6 target, where it more or less just strips TS-specific features, but that's only useful if you target a very small subset of browsers and limit what you use.

Even "6to5" (previous name for Babel), which originally had as a design goal that it would emit good JS (and back then, it did!) quickly lost that when they tried to aim for spec correctness.

TypeScript actually punts on the standard in some cases (eg: TypeScript classes are not ES6 compliant) to generate more readable code, but it's still not "good" code and I certainly would never consider working with that.

I remember hearing the same argument in the early 80s for the benefit of C vs Assembly. And it actually was a good argument. A lot of people, myself included, learned "real programming" (ie assembly) by using C as training wheels. But a funny thing happened on the way to the forum - C became real programming and nobody remembered or learned assembly - myself included. Then the same thing happened ten years later with the transition from C to C++.

So it sounds like everything worked out.

It did, and it will. My point is that just like with these "legacy" languages, the next generation of TypeScript developers are no more likely to "drop down into JavaScript" as a C developer is to "drop down into assembly". So our development tools and debuggers must be really solid at the language level that we code in. And just like I skipped the "transpiling" phase of C++, I'll probably skip the transpiling phase of TypeScript, and wait for the tooling and runtime to be more mature.

The advantage is it gives you an escape route if Typescript ends up dying. I worked on a project that had to do a giant dead language -> Java conversion, and it was extremely painful.

As codablah said: the availability of type definitions is a major difference in ease of use. The other reason is that I can add a specialised frontend dev to the team and reasonably expect them to be able to work in Typescript.

Also, TypeScript uses a structural type system, which feels very dynamic most of the time.

I could imagine, that most JavaScript developers prefer this over nominative systems.