I've already talked about how much I love TypeScript in some of my previous posts. It allows me to be more productive, but most importantly - it...
For further actions, you may consider blocking this person and/or reporting abuse
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".
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).
You know this reads as "old man yells at cloud"
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.
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.
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.
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.
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?
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.
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.
Pssst... They're still functions.
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).
2.5 if it's JS. You should be using JSDoc (and linting) anyway.
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.
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.
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.
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.
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.
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:
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?
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.
You haven't given any reasons for it being detrimental.
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.
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.
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.
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.
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.
I didn't say this. You're sounding fanatical.
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.
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 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.
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.
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.
No, you didn't. I said this:
Not that Typescript classes are harder to use, but that most Typescript, and Javascript, users don't feel the need to use them.
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.
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:
Kyle Simpson said this about Typescript:
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.
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.
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:
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.
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).
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.
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.
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?
Please provide links, I could not find any evidence of this.
This was taken from the first page of google:
There is literally no need to behave like this. It's toxic and I suggest you stop.
I like both. This is not an either/or situation, it's possible to like multiple languages at the same time.
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.
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.
Actually, that's not the only source of
any. Some other sources areObject.entries,Array.prototype.includesIMO, always have to keep in mind, that TypeScript's typing is not perfect, and may lead to false sense of security and reliance on TypeScript's suggestion. Best way is to do testings as if it is JavaScript, and defensive programming / validators, when required (e.g. accepting user's input will always need validation).
No where as strongly typed as a true static typing language, e.g. Kotlin/JS.
You have to enable either
// @ts-checkor somejsconfig.json/tsconfig.jsonsettings, as well.No where as convenient as TypeScript's interface IMO. However, a competitor is indeed Flow.
No.
There is no the future of web development.
There are many competing and co-existing futures, some of which may be more or less popular.
And even if it does become overwhelmingly popular for a time, that's only going to be for a time. :)
True
Many approaches to web development would exist as we progress
Companies would just have to use the ones that seem reasonable to them
I wonder what the tc39 folks think about typescript.
They already caved to classes, unfortunately.
When you got Jsdoc and serious naming strategy, types are a waste of time !
Just invest in code quality and forget typescript.
If I want crosscompile I have haxe/c#/rust/c++ that are more powerful than typescript.
Typescript are made for dev that does not know to write code without compilation...
Not really I would still stick to ES6 convention or future versions due to it being independent and affect a general amount of people who uses it.
I think Typescript have very successfully positioned itself as javascript that corporations and like minded companies prefer as they already like strongly typed C# and Java. Typescript allows JS to compete in similar space.
Have you worked in those messes of corporate C# and Java codebases? Three words: Resume driven development. There's a reason we still have O&G companies in Houston who are using ancient versions of both, often with AngularJS frontends they still haven't been able to migrate away from.
While I'm not going to debate the main question of this article, I will go on and describe my experience with TS.
I didn't plan to learn JS or TS. I just "had to", at some point, as my company made some sudden changes.
2 years later, I'm able to write pretty decent TS code, regardless of the frameworks used. However, I can't stand JS. It's a PITA for me to read / write plain JS.
But that's just my subjective experience. Maybe the fact that for many years I wrote Java and PHP code had something to do with how I perceive native JS.
God, I hope not
I certainly hope not, for all of the reasons I gave in my reply to @somedood and more.
"Is TypeScript the future of web development?" - no, I sure hope not. If we keep abusing the web for stuff it was never made for, I hope the future will at least be WebAssembly.
Web Assembly doesn't really dictate a language though. That's probably the future of browsers, but not of the development experience, short of adding a compilation step.
I will hand it to tsc for being able to quickly turn a TypeScript mess into JS/ES you can quickly fix.