DEV Community

Discussion on: TypeScript?.. or JavaScript?

f1lt3r profile image
Alistair MacDonald Author

Wow, thanks.

Thread Thread
stereoplegic profile image
Mike Bybee • Edited

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).
Thread Thread
stereoplegic profile image
Mike Bybee

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.
Thread Thread
f1lt3r profile image
Alistair MacDonald Author

Verbosity is really key.

Thread Thread
bearcanrun profile image
Barry Low

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.

Thread Thread
stereoplegic profile image
Mike Bybee

Yes, and still, not being a TS noob, I've run into the same issues for years.

Thread Thread
stereoplegic profile image
Mike Bybee • Edited

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).

Thread Thread
f1lt3r profile image
Alistair MacDonald Author

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.

Thread Thread
stereoplegic profile image
Mike Bybee • Edited

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.