DEV Community

Discussion on: Is TypeScript the future of web development?

Collapse
 
somedood profile image
Basti Ortiz

I'd probably go as far as to say that TypeScript may not necessarily be the ultimate "future" for JavaScript and web development, but it sure is the "present".

Collapse
 
stereoplegic profile image
Mike Bybee

So hot right now

Collapse
 
stereoplegic profile image
Mike Bybee • Edited

It shouldn't be. It's a crutch for devs coming from class-based, statically typed languages to JavaScript, lulls devs into a false sense of security in thinking they can hack JavaScript to behave like those other languages and not bother learning prototypes and dynamic types, adds tons of learning curve to and distracts newer devs from learning JavaScript proper, and those classes don't transpile nearly as cleanly (the same is true of ES6 classes, which were largely a concession to class-based OOP devs who couldn't fathom that JS has always been OOP, just not their flavor of it).

Collapse
 
sqlrob profile image
Robert Myers

You know this reads as "old man yells at cloud"

Thread Thread
 
stereoplegic profile image
Mike Bybee • Edited

Meh. I'll still know the only actual typing that matters after TypeScript's disappears in the transpiler, and my production code will be smaller because it's not the mangled garbage that "classes" turn into.

And given the likes that comment is getting, it seems I'm not the only old man yelling at it.

Thread Thread
 
sqlrob profile image
Robert Myers

Unless it's performance sensitive code, what's the difference? If the developer time saved and bugs prevented is more than the bandwidth costs and time difference, it's worth it.

Anything that helps prevents bugs is not a "crutch", it's a developer productivity tool. Or correcting the analogy, it is a crutch, so that you don't trip and fall. It's not a bad thing. People make mistakes. Period. Admitting that and trying to prevent those mistakes is not a bad thing. Do you have all the unit tests for bugs that would be caught by the compiler? No? Then I don't trust your code. I don't care if you're Brendan Eich or someone junior.

Thread Thread
 
stereoplegic profile image
Mike Bybee • Edited

Except that, in practice, this leads to convoluted codebases which are more difficult to organize, read, and maintain, much like the "object oriented JavaScript" (🙃) craze of the early-mid last decade and the silly MVC-for-the-sake-of-MVC projects it led to (which often, somehow, managed to be less readable than the spaghetti codebases they were refactored from).

This isn't jQuery or Underscore/Lodash which, as completely unnecessary as they are now, were handy convenience wrappers that ended up informing the development of JavaScript's own methods because of their utility.

This is "Can't handle JavaScript qua JavaScript? We got you fam. Feel free to hack at JS to make it behave like the language you wish it were." It's basically everything Kyle Simpson warned about in YDKJS.

Thread Thread
 
stereoplegic profile image
Mike Bybee • Edited

Oh... And it's also (being generous, if you believe the survey results that half of all JS devs are using TypeScript) a way to immediately slash your available talent pool in half by requiring it.

Thread Thread
 
sqlrob profile image
Robert Myers

Depends all on how you use it. Functions with typed parameters and indicating something as nullable or not is going to get you a good chunk of the benefit without straying too far from javascript. If you're doing objects for the sake of objects? Yeah, that can get convoluted if you're not disciplined. Stick with POJO and functional programming if you don't like classes.

Are you saying you never typoed a field? Or do you use jsdoc to make sure you get field names right? If not, what is your testing strategy to make sure you didn't get things wrong. How do you deal with maintenance?

Thread Thread
 
sqlrob profile image
Robert Myers

If someone can't handle simple type definitions on function parameters and return types, they're not a dev I want to consider anyway. They don't have the required discipline or flexibility. If you've jsdoc'ed your code, you can understand enough of the syntax in like 5 minutes.

Thread Thread
 
stereoplegic profile image
Mike Bybee • Edited

If someone can't handle simple type definitions on function parameters and return types

These should be documented anyway. I'd rather enforce the (much simpler, and more necessary) standard comment syntax of JSDOC than that plus a bunch of extra crap which isn't actually part of the language.

Stick with POJO and functional programming if you don't like classes.

Pssst... They're still functions.

They don't have the required discipline or flexibility.

Sounds a lot like someone who not only expects, but insists on one language behaving like another, rather than using the language as designed (if it makes you feel any better, I've long said the same about Python devs and CoffeeScript - just, fortunately, it didn't take off nearly as much... Now, YirgaCheffeScript or SidamoScript? Count me in).

If you've jsdoc'ed your code, you can understand enough of the syntax in like 5 minutes.

2.5 if it's JS. You should be using JSDoc (and linting) anyway.

Thread Thread
 
stereoplegic profile image
Mike Bybee • Edited

But again, to give TS (utilities) some credit: ts-check (which recognizes JSDoc, and can be set for JavaScript) is a fantastic tool while coding in VS Code. I mean that sincerely.

And tsc is great for turning TS codebases into (at least semi-)usable(/fixable) JS/ES.

Collapse
 
samwightt profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Sam Wight • Edited

It's a crutch for devs coming from class-based, statically typed languages to JavaScript

This is true, a lot of Typescript devs come from statically-typed languages and know how useful static types are for preventing a whole host of bugs.

lulls devs into a false sense of security in thinking they can hack JavaScript to behave like those other languages and not bother learning prototypes and dynamic types

This, however, is completely false. There's nothing in Typescript that forces people to skip learning the basics of Javascript. Typescript is a typed superset of Javascript. All valid Javascript is valid Typescript. Typescript is just a way of eliminating certain types of errors in Javascript. There's nothing that says that developers have to work one way or another using it.

adds tons of learning curve to and distracts newer devs from learning JavaScript proper

Typescript has very good type inference and doesn't require actually writing it. You can work in a Typescript project and never write a single type definition. Implying that Typescript in any way affects newer devs' ability to learn Javascript is objectively false.

and those classes don't transpile nearly as cleanly (the same is true of ES6 classes which were largely a concession to class-based OOP devs who couldn't fathom that JS has always been OOP, just not their flavor of it).

Nothing in Typescript requires that you use classes. ES6 classes were the result of a standards committee improving Javascript, not doing anything to cater to one specific audience. It's an optional extension of the language that you can use or ignore. Typescript neither encourages nor inhibits you from using it, but I think you'll find that the majority of Typescript developers don't use classes.

In conclusion, please educate yourself before you rant on something you have no clue on what you're talking about.

Thread Thread
 
stereoplegic profile image
Mike Bybee • Edited

As usual, this comes off as someone who assumes I haven't worked on numerous projects written in TypeScript throughout the years, and haven't attempted to give it (and, as I mentioned in a previous comment, CoffeeScript) a fair shake. I have, repeatedly, and the benefits have never outweighed the drawbacks. Your beloved superset ends up not only being superfluous, but detrimental.

Time and time again, I've heard the same refrains:

  • "Type safety" (there's not, any more than you already have in JavaScript with proper function/"class" commenting/documentation you should use anyway - the same is true of any other language). And none of the static typing in any of those languages is going to save you from runtime. You're correct that that's not inherently the fault of TypeScript for the most part, but billing it as "your types are safe now" results IRL in a lack of attention paid to, and effort bothering to learn, dynamic types already in JS and runtime type checking.
  • "Type inference." Yeah, that's cool I guess, but it doesn't replace the need to properly document correct type usage.
  • "Better organization of complex codebases" (when, in fact, complexity usually grows exponentially).

Nothing in TypeScript requires you to use classes (in fact, it's often harder to use ES6 classes with TypeScript). ES6 classes were the result of the standards committee improving JavaScript

Wait... I'm confused. I thought in TypeScript everything JavaScript was valid and good and... How is it something you believe improves JavaScript, that is now actually in the spec, is harder to use with this blessed superset thereof? While I don't share your opinion of ES6 classes, do you not see the contradiction here?

And nobody on the TS side seems willing to address the effect it has on both junior devs and talent pool.

I usually hear, as I did earlier in this thread, "not the type of dev I'd want to hire." That doesn't answer the question. So how do you create experienced JS devs? Is your answer to take experienced C# devs and plop them into JS via TypeScript?

And what about that other 50% (again, likely WAY higher) of JS devs? Do you just tell them their however many years of experience with JS are invalid if they don't write TypeScript?

And for the small startup and the dev(s) they're fortunate enough to find who they can afford with enough competence to build their product, do you impose TypeScript on them?

Thread Thread
 
samwightt profile image
Sam Wight

As usual, this comes off as someone who assumes I haven't worked on numerous projects written in TypeScript throughout the years, and haven't attempted to give it (and, as I mentioned in a previous comment, CoffeeScript) a fair shake.

Because you write like someone that hasn't taken the time to actually give Typescript a shot and make very, very basic mistakes about how it works and what its purpose is.

Your beloved superset ends up not only being superfluous, but detrimental.

You haven't given any reasons for it being detrimental.

(there's not, any more than you already have in JavaScript with proper function/"class" commenting/documentation you should use anyway - the same is true of any other language).

Typescript is more capable of representing complex types and doing so with dependencies. That's not something you get with JSDoc; more npm modules have correct Typescript typings than JSDoc documentation. Typescript is also much more elegant, saving probably multiple kilobytes of space on a large project compared to JSDoc comments. Last, Typescript types everything by default, while JSDoc does the exact opposite. If you forget a JSDoc comment on a variable or a module doesn't have JSDoc types, then you're screwed. Typescript covers much more, is much safer, and is much more elegant.

but billing it as "your types are safe now"

I never said this, I said it gives you more type safety than whatever tool you're using currently. It's not 100% type safe (I doubt this is not possible), but it does prevent a large margin of errors from even happening, much moreso than JSDoc.

results IRL in a lack of attention paid to, and effort bothering to learn, dynamic types already in JS and runtime type checking.

If you'd really used Typescript before you'd know that Typescript requires you to use runtime type-checking in order to limit down union types. It's encouraging better practices, not replacing them.

How is it something you believe improves JavaScript, that is now actually in the spec, is harder to use with this blessed superset thereof? While I don't share your opinion of ES6 classes, do you not see the contradiction here?

I again didn't say this, please avoid putting words in my mouth. I said the majority of Typescript developers I've encountered prefer to not use ES6 classes simply because there are other alternatives (e.g. a more functional flavor of Javascript) that work better for them with the same effects.

And nobody on the TS side seems willing to address the effect it has on both junior devs and talent pool.

It... doesn't have any effect? It's just a tool. That's like saying ESLint or JSDoc has a significant effect on junior devs and the talent pool.

Do you just tell them their however many years of experience with JS are invalid if they don't write TypeScript?

I didn't say this. You're sounding fanatical.

And for the small startup and the dev(s) they're fortunate enough to find who they can afford with enough competence to build their product, do you impose TypeScript on them?

I didn't say I'd impose Typescript on anyone, but it wouldn't necessarily be a bad thing. Typescript isn't that hard to learn and doesn't take near as long to get started with as you're implying. It's just Javascript.

Thread Thread
 
stereoplegic profile image
Mike Bybee • Edited

Are we really worrying about kilobytes? That's like arguing for SQL over NoSQL (not at all implying there aren't legitimate use cases) in 2020 because "storage is expensive."

You do know comments get stripped out of transpiled and/or minified JavaScript, right? And why aren't you worried about kilobytes of type definitions in not only your code, but every DefinitelyTyped definition dependency you're pulling down?

I again didn't say this, please avoid putting words in my mouth.

I literally quoted you saying ES6 classes are harder in TypeScript. NBD, and I'd say encouraging devs not to use them is a plus, but I'm not the one who called them an improvement to JavaScript, and making something harder (which is still commonly used in TS, seen it plenty of times) isn't the way to discourage it.

It's just JavaScript

No, it's not.

I've said what I needed to say, based on years of experience in both JS and TS, and I know I'm not going to change the minds of people dead set on treating JS like another language built on completely different paradigms. So I'll leave by recommending they check out Ryan Dahl's (Node.js and Deno creator's) recent experiences and motivation for moving away from TS for Deno's internals, and especially Kyle Simpson's (YDKKS author's) comments (some of which are the same beefs I have) as to why that's a bad idea.

Thread Thread
 
samwightt profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Sam Wight

Are we really worrying about kilobytes? That's like arguing for SQL over NoSQL (not at all implying there aren't legitimate use cases) in 2020 because "storage is expensive."

You do know comments get stripped out of transpiled and/or minified JavaScript, right? And why aren't you worried about kilobytes of type definitions in not only your code, but every DefinitelyTyped definition dependency you're pulling down?

I'm not worried about it, I'm saying it saves space, both in the amount of code you have to read but also in the final sizes of the files you're working with. JSDoc comments are ugly, illegible, and not usable if you use them everywhere to get the same type safety you get from Typescript. JSDoc is a great way to document Javascript, but it is not in any way a replacement for Typescript if you care about type safety.

I literally quoted you saying ES6 classes are harder in TypeScript.

No, you didn't. I said this:

Typescript neither encourages nor inhibits you from using it, but I think you'll find that the majority of Typescript developers don't use classes.

Not that Typescript classes are harder to use, but that most Typescript, and Javascript, users don't feel the need to use them.

but I'm not the one who called them an improvement to JavaScript

Because it was better than the previous implementation of classes (having to use objects)? I mean... it's objectively an improvement to Javascript. If you can't acknowledge that, then you really don't need to be making any sort of comments on anythingJavascript-related.

which is still commonly used in TS, seen it plenty of times

Seeing something several times and it being 'common' in TS code are not the same thing. Please provide numbers that the majority of Typescript code uses ES6 classes solely (not just for working with a single library or for a single component, but as the base building block of an application) and then we can talk.

Here's the link to Ryan Dahl's experiences with Typescript. I'd recommend you actually read what you're sending me before commenting because he says this:

Update June 10 2020: I saw that this design doc was being discussed more widely. Most people don't have the context to understand this narrow technical document - it is only applicable to a very particular, very technical situation in the internals of Deno. This is not at all a reflection on the usefulness of TypeScript in general.

Kyle Simpson said this about Typescript:

TS is a linted set of JS that accommodates some opinions on good code. That's great.

Don't see any negative opinions here. Link to the tweet.

Please stop commenting. You're showing how uneducated you are on the topic and how little you really know. It's exhausting.

Thread Thread
 
stereoplegic profile image
Mike Bybee • Edited

I'm sure it is exhausting having to edit your comments after I've pointed out a contradiction, so it looks like I fabricated your actual words as shared in the blockquote (yeah, you did that, the blockquote is exactly what you said... That's pathetic, dude), and cherry-picking the one lukewarm comment you could find from Simpson (among countless negatives) that you could drop to make it look like he supports TS.

But yeah, it is a complete waste of time to debate someone who has to stoop to such lows.

Thread Thread
 
samwightt profile image
Sam Wight • Edited

I'm not cherry-picking any comments from Simpson, I found a comment that said he is indifferent to Typescript.

As for the Deno post, I read the comment at the top of the document you sent me that says that the findings in the document shouldn't be used as a way to talk about the usefulness of Typescript. Again, here's the part quoted from the document:

This is not at all a reflection on the usefulness of TypeScript in general.

Typescript was not the right choice for Deno's internals. Only for the internals, not for anything else, because the Typescript compiler resulted in some runtime inefficiencies for them. Almost nobody will hit that issue in production, and it's slowly being solved by rewriting TSC in Rust, like the swc project is doing. It is not cherry-picking for me to listen to the author's intent. I did not intend to make it look like he supports TS (that was implied nowhere in my comment). Please read my comments more carefully before assuming ill-intent.

Maybe you should read the resources you link (or quote, for that matter as well) before commenting on them. Similarly, maybe you should actually use a piece of software extensively, observing the community and projects surrounding it much more carefully, before making false, unsupported claims about the project's usefulness or capabilities. In the future, I'd highly recommend against doubling down on your claims when someone points out that they're wrong, using that as a sign that you need to educate yourself further on what you're talking about, instead of continuing to spout false assertions and FUD that might deter new users away from using a beneficial piece of technology. It's toxic, immature, and makes no one want to believe or take seriously any of your points.

Thread Thread
 
stereoplegic profile image
Mike Bybee • Edited

Must be even more exhausting, putting forth that much effort to FUD my "FUD" (which couldn't possibly be based on numerous real life experiences over several years, because you disagree with me).

And Dahl's experience isn't nearly as uncommon as you would have people believe. That's why I referred to it. In this case, it's a matter of direct impact on a tool that more and more people are migrating to, away from Node. It's a BFD.

As for Simpson, he has expressed plenty of opinions unapologetically against TypeScript. As I said, it must have been exhausting to hunt down one snippet that was mere indifference.

And there's still the (pathetic) matter of editing a comment to make it appear that I made up a direct quote from you. It's OK. We all contradict ourselves at times, especially in the heat of an argument (and frankly, it wasn't that big of a deal until you resorted to the narcissistic, abusive boyfriend tactic of "I never said that!!!"). It's not ok to resort to virtual gaslighting when called on a contradiction (and again, a minor one until you went this route).

Thread Thread
 
stereoplegic profile image
Mike Bybee

There's obviously nothing to be gained from continuing this "debate." You like TypeScript. I like actual JavaScript.

Let's not get any deeper in the weeds, so you don't have to resort to any more toxic behavior. On the whole, DEV's comments are extremely productive even when there is disagreement. This, on the other hand, is more akin to Reddit.

Thread Thread
 
samwightt profile image
Sam Wight

Must be even more exhausting, putting forth that much effort to FUD my "FUD" (which couldn't possibly be based on numerous real life experiences over several years, because you disagree with me).

You provided no evidence to support your claims and severely misunderstood basic parts of Typescript. I doubt your life experiences were extensive enough for you to be able to make an informed decision on whether Typescript is useful for a project or not if you were unable to get basic things right.

And Dahl's experience isn't nearly as uncommon as you would have people believe.

Please provide evidence that this is the case. Are there any other experiences with Typescript that I should be reading about? Are tons of people using Typescript as a runtime instead of using as a compile-time tool, as it's usually intended to do?

As for Simpson, he has expressed plenty of opinions unapologetically against TypeScript.

Please provide links, I could not find any evidence of this.

As I said, it must have been exhausting to hunt down one snippet that was mere indifference.

This was taken from the first page of google:

(and frankly, it wasn't that big of a deal until you resorted to the narcissistic, abusive boyfriend tactic of "I never said that!!!")

There is literally no need to behave like this. It's toxic and I suggest you stop.

There's obviously nothing to be gained from continuing this "debate." You like TypeScript. I like actual JavaScript.

I like both. This is not an either/or situation, it's possible to like multiple languages at the same time.

so you don't have to resort to any more toxic behavior

I was not the one that compared the person I'm talking with to an 'abusive boyfriend'. And you're right, this conversation is done. Dev.to admins have been notified accordingly. Please stop with this behavior. It creates a toxic and unwelcoming atmosphere for those that are new to Dev.

Thread Thread
 
stereoplegic profile image
Mike Bybee • Edited

Is it done or am I supposed to provide examples?

And tattling to the admins after you edited your comment and called me a liar for quoting it in its original form? The same admins who would be most likely to have a record of your edit?

Yeah. I'm done. Let them sort it out, but let the record show that I never attacked anyone personally (as you did many times, provable at least until you make more edits) unless calling out a quoted contradiction (which you then deleted) counts, until you continued that attack by calling me a liar with nothing but an edited comment to back up the claim (the aforementioned "virtual gaslighting," which apparently continues with you suddenly "taking the high road" immediately after yet another personal attack).

Feel free to get the last word in, as I'm sure you will.