Babel has always caused me headaches. Setting up Babel-based build systems is troubling—the same setup will work sometimes and not others even on the same machine. TypeScript vastly simplified working with modern JS for me. It’s consistent, requires far fewer dependencies, and is much more succinct.
I don't know if what you've described is an _opposite_ experience. I think TypeScript would work fine for me too if I never needed anything compilation-wise outside of what tsc is already capable of. But as soon as you do, the lack of extensibility of tsc compared to babel becomes painfully obvious.
I think it is the opposite. Even without TypeScript Babel has grown to be overly complex.
If you’re talking about front end libraries like React you’re better off ditching Babel altogether and going with something like Parcel. It just works.
The TS developer experience ya sim proved working with JS enormously for me when I have to do it, and nudged me toward simpler, smarter development environment setups.
I can’t speak for you or anyone else. Just adding my two cents.
Babel's designed first and foremost with extensibility in mind. Of course an opinionated build tool with no extensibility to speak of (tsc), is going to be easier to set up and get started with than one that designed with extensibility as a core principle.
That doesn't mean one's necessarily fundamentally better or worse than the other, but the great thing about extensible tools is that they can often be used as building blocks for other more opinionated tools that abstracts away configuration details from the user by providing an opinionated set of defaults, and still offer the ability to customize when users' needs are not adequately met by the defaults.
Case in point - Parcel actually uses babel under the hood:
All it does is configures a default set of plugins & presets for you. You can override any and all compilation behavior Parcel provides by default simply by adding the appropriate babel config files.
TypeScript could have done the same with their build tooling, by extending babel with plugins/presets and providing the exact same set of functionality to users as what tsc's is capable of currently in terms of compilation features (which is currently afaik a strict subset of what babel + its plugin ecosystem is able to provide).
That would give users the exact same out-of-the-box experience as tsc does currently, and offer them the opportunity to extend compilation behavior with additional plugins and presets when the need arises.
That extending the compilation behavior of tsc, after so many years of development and wide adoption, is still not even on the roadmap right now is the core of my disappointment with them choosing to develop their own _non-extensible_ compilation tooling vs just extending babel, where they would have been able to offer extensibility for free from day 1.
It's the Maven (dumb) vs. SBT (very clever) build tool argument. Wherever I've been, there are people in the first camp and people in the second camp. I personally don't like highly extensible build tools because I can't manage them and end up with lots of complexity on it's own, taking time from me building features.
Babel has always caused me headaches. Setting up Babel-based build systems is troubling—the same setup will work sometimes and not others even on the same machine. TypeScript vastly simplified working with modern JS for me. It’s consistent, requires far fewer dependencies, and is much more succinct.
YMMV, of course...