As a PM on the team, I actually _share_ your concern! ;)

In fact, we're very mindful about the cognitive overhead of new features, but we're also motivated by pragmatism. These features have been highly demanded to help them write real-world code. My coworker Ryan has written up a pretty good explanation of why we tackled the feature set that we did: https://news.ycombinator.com/item?id=16277367

Keep in mind that TypeScript strives to model JavaScript as it's written broadly. While we could always take the stance that you have to rethink the way you write JavaScript, that would be unnecessarily stubborn. Hope that gives some insight!

It is a bit dizzying that the type system keeps getting even more expressive (the next release might have type conditionals!) while the core language and its dynamic semantics is necessarily limited to tracking Javascript (so no operating overloading, no pattern matching).

TypeScript itself doesn't really add new language features; it just tracks the ECMAScript spec and considers proposed features for implementation after they hit stage 3.

The enhancements coming out in new TypeScript releases are largely related to typing expressiveness / type inference precision (covering more edge cases where one might have previously resorted to `any`) and strictness (catching more errors at compile time).

Indeed, the only Typescript feature I can think of that isn't purely for type checking or lifted from ECMAScript is Enums, and Enums have been around forever.

Well it has supports for JSX and decorators which AFAIK aren't in the spec yet. It also has a syntax for class mixins without actually doing any desugaring when the code is transpiled. So it's not quite just JS + types.

Ah, I forgot about those. Nonetheless JSX and Decorators were added to the language back in 2015, so they've been sticking strictly to ECMA features for nearly 3 years now.

It has public, private and protected members (checked at compile-time), which is a bit of a mess because ES is gaining an independent notion of private fields (checked at runtime).

The strongest point for TypeScript is its tooling and editor support that made it so easy use to use it in development. Even anyone writing JS in VSCode gets to use some checking from TS. But that bloat in the language and the amount of features added with every release is making me a lot worried.

ReasonML is great but it still so immature with little issues here and there that might be annoying to some people. I expect it to be a great alternative in the future but not now.

That's for example what makes something like Elm much better. How Elm dealt with the whole echosystem to make it use separate packaging system, not bad editors support (needs a lot of improvement for VSCode IMO) and the simplicity of the language made it a really powerful alternative that I'd use instead whenever possible.

Looking at the 2.7 updates, they don't really seem to be adding more features that result in bloat - instead there is a lot of work to make existing features more predictable and catch potential mistakes. Sounds good to me.

If they add features the same way they do with C# I don't see a problem. C# has been extended a lot from V1 but it doesn't feel bloated at all. I think C++ started from a much less solid foundation and is still suffering from that.

> On the other hand I am concerned that TypeScript is becoming a very bloated language

I came to say exactly this. Are there actually people out there asking for all of these nuanced features?

I've been excited about TS for a while and used it for several side projects with great success...but with each new release and new set of "features" my excitement wanes a bit.

I do some of the feature planning / prioritization for TypeScript.

The strict class property initialization check was the one of the highest-voted, most-commented, and most-duped "unfixed" issues on the issue tracker.

Definite assignment assertions are a necessary co-feature for class property initialization checks to work ergonomically.

ES module interop is just TS keeping up with the evolving ES6 / CJS interop story. TS has to support ES modules.

"unique symbol" is type system support for the long-present ES6 symbol concept.

Cleaner/prettier console output should be uncontroversial as an incremental improvement.

Numeric separators are an ECMAScript feature that need to be supported. TS has to support ES syntax.

Fixed length tuples were a long-standing proposal (nearly 2 years old) that had a lot of positive feedback from the community. Among people who were using tuples, the prior behavior was seen as very much wrong and we were convinced by the use cases. People not using tuples are unaffected, naturally. It's more of a bugfix than a feature.

Better narrowing under "in" and "instanceof" were also long-standing issues. The "instanceof" behavior in particular just looks like a bug; only from a spec-lawyer perspective is it really a feature per se. It's more of a bugfix than a feature.

Smarter object literal inference again basically amounts to a bugfix; TS was allowing extremely broken code, essentially due to some implementation details of how types' representations are optimized. It's more of a bugfix than a feature.

It's definitely understandable that the most exciting features are already in the language, but I don't see anything in this list and see "bloat".

Thanks so much for taking the time to respond in such a thorough manner :)

I really appreciate the work that the TS team is doing, and understand that they are up to a very difficult task in trying to keep up with JS while also augmenting the type system capabilities to cover more cases.

With regards to making the language more complex, yes, i agree that it's not something pretty, but at the same time i find these kind of additions similar to the recent JS additions: you can still ignore them if you don't need them. E.g., you can still code perfectly fine without using classes, or symbols, or whatnot. There is the issue of having to deal with different "dialects" of JS/TS when reading others' code, but that still happens in pretty much every mainstream language i know of :/

Features != bloated. JS has many, many, many shortcomings. I don't have 100+ libraries to do basic stuff that should be baked in.

JS is a big language. It continues to grow without removing features. One codebase can be very functional, another dynamically typed C++ from 2004, another pythonic. As long as they support the entire language while adding static typing (not an easy feat), it's going to grow. In that sense it is very much like C++, though it's still not in the same league of complexity of C++.

If you want a small language, look elsewhere. I had fun with Bucklescript over the weekend, and it is amazing how expressive it is. The syntax sucks in places [| Reason is a small upgrade |], but that's probably where you want to look. Maybe Elm if you are fanatic about it.

> JS is a big language.

Kind of(maybe). But that's beside the point. Typescript is a separate language that happens to compile to Javascript. The TS team is in no way bound to support every style of programming that Javascript supports (and they don't, just by virtue of having strict typing).

They don't have to, but as long as they want to market themselves as a "typed superset of Javascript" (see homepage), they do. For many people, that is the point.

Yep. And this is important, it allows people to move most JS projects incrementally to TS projects. If they fall far behind the features that many JS projects are using, that won't be true anymore, and those people will start using Flow instead (flow.org)

Similarly it is useful for TS to track the Stage 3 proposals of future features and offer them early, as JS users may pick those up with Babel or other polyfills. Typescript's own transpilation behavior of Stage 3 proposal can sometimes be a useful test for the feature while browsers work on their own implementations.

> Programming languages are not like your Word or Excel where more features is better.

I‘d contest that even for those categories adding more features is necessarily better. In fact, Word in particular is an excellent example of how adding features can result in a worse product.

On the other hand, I like programming languages with either a “batteries included” philosophy or a large ecosystem of easily usable libraries that allow you to solve common real-world problems quickly.

In that regard C11 is also much more than K&R C, and C20 is on the horizon.