While TypeScript fans are blasting him for it, it says something that Ryan Dahl (creator of Node.js and Deno) went from TS to JS for Deno's internals.
I have warned about every reason he gave for the switch for years, and then some.
*Edited out "fanboys," because there are plenty of valid reasons to consider TS and there were some well-reasoned arguments against his complaints; however, those were few compared to "Jeez, this guy" (again, creator of Node and Deno) "is an idiot! How doesn't he see that treating JS like C# is so much better!"
You're welcome. It was quite vindicating to learn that someone who has made my career so much better with his creations has some of the same concerns about TS that I do.
Most of my other beefs with TS stem from what it's doing to JS devs:
stunting their growth in learning JS proper, whilst simultaneously
adding a great deal to their learning curve which is NOT actual JS,
and giving a false sense of security in:
static types that are transpiled away, when JavaScript has its own dynamic typing system you'd do well to learn, and documenting them can be as simple as JSDoc @params (you can even exploit tscheck in VS Code to check them as you write)
hacking around JS to treat it like some other class-based language e.g. C# (if you remember the "object oriented JavaScript" craze that came along before the first edition of YDKJS - which Simpson covers therein to some extent - you know why such a pattern of hacking around JS, rather than understanding what it does and why, is a road to sadness).
Finally, on the hiring end, because:
requiring it automatically cuts the available talent pool in half (and that's being generous, if you believe the oft-referenced Stack Overflow developer survey claiming that 50% of JS devs use TS).
Oh, and a comment about most annoying language replying to a post asking about hardest language - the commenter chose Java as most annoying for the same main reason I dislike Java, and yet another beef I have with TS:
tl;dr:Context is everything and know your use case. I'm still a TS newb, but I've already run into instances where TS removed burden by increasing transparency and simplifying apparent complexity in a manner similar to Artur's(@dotintegral) comment.
FWIW the complexity issue is something many experienced JS devs likely complained about back in the early-mid part of the last decade when so many got caught up in the "object oriented JavaScript" craze (because it wasn't already? 🙃) that Kyle Simpson touched on in the first edition of You Don't Know JS, and the related "MVC EVERY CODEBASE PURELY FOR THE SAKE OF MVC 🙃" craze.
What a lot of us witnessed back then was a bunch of resulting code that was, somehow, even less readable and maintainable than it was in its previous spaghetti form (which we had probably already warned was spaghetti, but new hotness won out over common sense as the solution).
Right. Other than a clear model for componentization, it's hard to think of anything libraries offered that I wasn't already doing in one form or another. JSX/Hyper-HTML has also been quite revolutionary in it's own right, but on the other hand, that does come at a cost. I do like that the React community brought an awareness of classic CS concepts like immutability, side-effects, memoization, etc.
I could be very wrong here, but... I think the industry will dramatically shift back away from mega-frameworks and build-systems this decade, mostly due to new browser capabilities like Web Components and Modular JavaScript. I can't wait, it's going to be clean again for a while.
I actually don't have a problem with React - now Redux's obsession with pure functions to the point that you need either band-aidy (Thunk) or even more super-duper-boilerplatey (Saga) middleware just for async is a different story - in fact, it's my favorite library (actually React Native on mobile web and desktop, it's amazing what you can do with a single codebase without relying on a WebView these days).
I actually dug pretty deeply into HyperHTML (and other smaller libraries like Riot, and strictly relying on modern vanilla JS) before giving React a serious, unbiased chance, but I kept running into wheels that needed to be reinvented.
I haven't experienced many tradeoffs with JSX, especially now that there's hardly any reason for me to worry about repeating class/lifecycle methods (or using classes at all) ever again.
The thing that keeps me from web components is the same thing I ask any time I hear about use of just about any web framework/library: What's your mobile strategy? I don't like fragmenting teams to build what is often the same exact app in multiple codebases, if it's not absolutely necessary.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
While TypeScript fans are blasting him for it, it says something that Ryan Dahl (creator of Node.js and Deno) went from TS to JS for Deno's internals.
I have warned about every reason he gave for the switch for years, and then some.
*Edited out "fanboys," because there are plenty of valid reasons to consider TS and there were some well-reasoned arguments against his complaints; however, those were few compared to "Jeez, this guy" (again, creator of Node and Deno) "is an idiot! How doesn't he see that treating JS like C# is so much better!"
That's really interesting. Do you have links to any of that information? I would love to read what his reasons were.
startfunction.com/deno-will-stop-u...
Wow, thanks.
You're welcome. It was quite vindicating to learn that someone who has made my career so much better with his creations has some of the same concerns about TS that I do.
Most of my other beefs with TS stem from what it's doing to JS devs:
and giving a false sense of security in:
@params (you can even exploit tscheck in VS Code to check them as you write)Finally, on the hiring end, because:
Oh, and a comment about most annoying language replying to a post asking about hardest language - the commenter chose Java as most annoying for the same main reason I dislike Java, and yet another beef I have with TS:
Verbosity is really key.
Of course, if you follow the rainbow to the end, you'll notice the disclaimer at the top of the Design Doc that the Deno decision was discussed around.
Design Doc: Use JavaScript instead of TypeScript for internal Deno Code
tl;dr: Context is everything and know your use case. I'm still a TS newb, but I've already run into instances where TS removed burden by increasing transparency and simplifying apparent complexity in a manner similar to Artur's(@dotintegral) comment.
Yes, and still, not being a TS noob, I've run into the same issues for years.
FWIW the complexity issue is something many experienced JS devs likely complained about back in the early-mid part of the last decade when so many got caught up in the "object oriented JavaScript" craze (because it wasn't already? 🙃) that Kyle Simpson touched on in the first edition of You Don't Know JS, and the related "MVC EVERY CODEBASE PURELY FOR THE SAKE OF MVC 🙃" craze.
What a lot of us witnessed back then was a bunch of resulting code that was, somehow, even less readable and maintainable than it was in its previous spaghetti form (which we had probably already warned was spaghetti, but new hotness won out over common sense as the solution).
Right. Other than a clear model for componentization, it's hard to think of anything libraries offered that I wasn't already doing in one form or another. JSX/Hyper-HTML has also been quite revolutionary in it's own right, but on the other hand, that does come at a cost. I do like that the React community brought an awareness of classic CS concepts like immutability, side-effects, memoization, etc.
I could be very wrong here, but... I think the industry will dramatically shift back away from mega-frameworks and build-systems this decade, mostly due to new browser capabilities like Web Components and Modular JavaScript. I can't wait, it's going to be clean again for a while.
I actually don't have a problem with React - now Redux's obsession with pure functions to the point that you need either band-aidy (Thunk) or even more super-duper-boilerplatey (Saga) middleware just for async is a different story - in fact, it's my favorite library (actually React Native on mobile web and desktop, it's amazing what you can do with a single codebase without relying on a WebView these days).
I actually dug pretty deeply into HyperHTML (and other smaller libraries like Riot, and strictly relying on modern vanilla JS) before giving React a serious, unbiased chance, but I kept running into wheels that needed to be reinvented.
I haven't experienced many tradeoffs with JSX, especially now that there's hardly any reason for me to worry about repeating class/lifecycle methods (or using classes at all) ever again.
The thing that keeps me from web components is the same thing I ask any time I hear about use of just about any web framework/library: What's your mobile strategy? I don't like fragmenting teams to build what is often the same exact app in multiple codebases, if it's not absolutely necessary.