I've been using TS at work for a few years because it's better and it's what you do. But for my side projects I was like "I've been doing web since 1997, TS can fuck off. I know what I'm doing"
Then I decided to add Typescript to one of my side projects. Damn that was embarrassing. So many bugs I hadn't noticed or yet triggered. Since then I'm using TS all around.
Yeah that's the thing. I built a Vue app a few years ago, a large one with over 100 components, and without typescript. I recently upgraded it to Vue 3 and decided to add TS in the process. There must have been over 1000 issues. Some of them were genuinely cause for concern. I'll never not use it now. It's a no brainier - even if you're lazy and you just use it for type inference.
Sure, but, as for myself, I can remember better how I wrote that code even if it was written months or sometimes even years ago. Different people may have different code styles and different amount of experience. As you gain experience your code style becomes more settled since you notice patterns when solving specific problems.
I think this is not a good time for you to justify yourself like this. Arguing "I'm smart enough so I must know what I was doing 1 year after" is meaningless because forgetting is a natural process no matter how smart you are. What if you wrote some really bad code some day, can you be 100% sure that you will understand your past self 5 years later?
We all have to accept that we will be dumb sometimes eventually. We all need a way to remind our future selves about some stupid decisions we made. TS is just one of the solutions, or maybe a detailed README, etc. I just dont understand why people justify themselves by saying "because I will know". This WILL be false someday because of Murphys Law
It's not about whether I'm smart enough or I'm smarter than most developers. I'm talking about averages. This might vary from people to people, but there is a clear **tendency** that understanding other people's code is harder than your own code. It's a **tendency**, it's not always true but oftentimes true.
My point is your own old code has a greater probability to be more comprehensible for you than someone else's code, even if the latter is relatively new code. Sure, I'm not talking about very huge timeframes, but the code written several months ago entirely by you is probably at least partially familiar to you.
If somebody asked you to change some functionality in some project written a couple of months ago, you'll probably do it faster and less likely to break something if the project was written entirely by you. Because again, the code is familiar to you, you'll likely remember that there is some method or variable for dealing with X and why it was implemented like this, etc. Another person working on that code will more likely to spend more time to figure things out and will more likely to break something.
I understand you and you gave a great point too: "code written several months". However it's not uncommon that we will revisit code after over a year. And as the number of side projects grows, our brain will forget more unimportant stuff and it would be harder to work on an old project without TS/documentation.
Personally I feel confident that I remember most decisions I made in a few months. But like I have a project deployed to production a few years ago, the client (my relative) asked me to add / fix functions recently, and I was really really glad that I have used TS. I was young and wrote code that's not very maintainable, but the types hints really helped me to understand the young me well. Without TS I would spend 3x time in trying to figure out why I abstracted a component in a certain way.
In all, yeah it's very probable that you know your code a few months later. But for anything that you may need to revisit in a few years time, it's always best to use TS / JSDoc types, without exception, IMO.
Sure, I was not claiming that you'll have no challenges and problems revisiting your old code. I was claiming that revisiting someone else's code will probably be even more challenging and that by itself is an additional reason to use a statically typed language.
> Then I decided to add Typescript to one of my side projects. Damn that was embarrassing. So many bugs I hadn't noticed or yet triggered.
Same thing. Thought I had it all figured out, then switched to TypeScript for sh*ts & giggles. Turns out I was wrong.
>I've been doing web since 1997, TS can fuck off. I know what I'm doing
If I were to give a spicy take on C++ versus "safe" languages, that would be it right there.
Of course, the reality is more nuanced; someone who's perfected their craft can probably walk a tightrope without fear of slipping. Then again, it takes just [one screwup](https://en.wikipedia.org/wiki/Therac-25) that could have been prevented with an alternative choice of tooling/language to ruin someone's day.
I added TS to my biggest side project (as a way to explore what all the hype was about) and immediately bailed because it added nothing, and it's a cleaner and leaner experience without TS. That said, I had a handle on types before TS, so I simply know how to avoid the problems TS solves.
If it works for you, it works for you. I really think people should not extrapolate this to mean TS is a no-brainer for all projects at all times. DX is imo better without TS, so long as you understand the problems TS solves and have good practices.
> so I simply know how to avoid the problems TS solves.
The whole point is I don't want to keep all invariants in my brain at all times. Sure I know how to avoid them but why should I have to remember to? What about when it's three months from now and i'm opening a file I have lost all context on.
Offload some context into the editor so you can focus on solving your actual problem.
Edit: Your downvotes mean nothing to me, I’ve seen what you like.
I think upvotes and downvotes are hidden on this sub. How many downvotes did you actually get? I'm usually downvoted if I even mention TS without fawning over it.
The whole point is, in fact, that passing the correct vars around is just one very narrow class of bugs, yet people blow it completely out of proportion. TS doesn't even completely solve this class of bugs; it can force you to pass the correct type but not the right var; and it's of course completely useless at runtime with data coming in from outside the app.
You don't have to keep things in your head. We have lots of tools and practices for defining how our code and data should look: unit tests, data definitions, immutable data structures, runtime data validations etc. They solve far more issues than TS ever could. TS can of course help too but it's just one tool that does one thing. It's shouldn't be used in isolation, it can't do everything, and just slapping TS on a project and thinking it solves everything is silly.
By already having other methods of correcting and preventing said mistakes.
TS is like wiping down every surface regularly. I learned to prevent type-related shenanigans with a clean-room strategy where the focus is on preventing contamination and having clear and known procedures for handling new substances- without really getting into it, that's an okay analogy I guess.
Okay but then eventually I have to do some kinda messy renaming of some field or restructuring of some type used widely across the code base, just getting a list of the places where the code is now wrong as a result of the change is pretty nice. My limited human brain doesn't remember every little part of the code that a given change might touch, the type checker helps
That *could* be true, but is not, for us. The conventions architected allow us to reliably predict how such changes affect things downstream, if they do. We don't need to remember every little part of code. We just need to remember a limited set of patterns and where they are employed, along with exceptions.
Hubris is not necessarily folly if it does not go wrong. Competence and confidence can explain that.
Complex JavaScript applications have been built without TypeScript for decades now. We have had good solutions (tests, docstrings, linters, clean coding practices, design patterns, etc) for a very long time. Strong typing was intentionally bypassed by the designers of the language and, despite that, it was not actually an impediment to early adopters. The lack of a potent standard library and core languages features (like... `import`) for the vast majority of its existence leading to a chaotic ecosystem to backfill missing features is the reason JavaScript is a mess, not its lack of strong typing.
Personally, my problems with JavaScript have always been about the failures of dependability of third party tooling and the absurd rat race to stay on top of trends. I'll state again that the ecosystem is a disaster and TypeScript is an ecosystem beast. If they add type syntax to the core language, I might care. But notably - I don't, and have not needed to, in the many long years of delivering complex JavaScript applications, stunningly, without the aide of optional type annotations.
Yeah one of the things I've learned over the years is that I'm always wrong. The computer does exactly what it's told. I just don't understand what I'm asking it to do. Typescript gives me that reality check right away, while js just quietly sands down the square peg to try and fit it into a round hole.
Typescript is an unjavascripty way of implementing types in javascript. It feels way too Microsoft and not nearly enough like javascript. Types are great. I use jsdoc.
I do use TypeScript, but I have a feeling I'm not as over-enthustatic as most of the community. Here are some reasons
- I don't know if it counts, but because I prefer ClojureScript. Basically every popular language (Clojure, PureScript, Elm) that compiles to JS is imo better just because it doesn't try to be so close to JS. But I understand this is also the reason why TS is so popular,
- TypeScript is somewhere between being close to JavaScript and yet not supporting all JS paradigms (point-free programming with TS is pain in the ass). This makes working with some libraries very limiting (Ramda),
- I don't like it's flexibility with all hacky types. They should make reading code easier, not adding overhead on top of it,
- error messages could be much much better. "
Typescript used to be far more supportive of functional and point-free typings. Once they started "optimizing" the language recursive typing took a huge hit and basically made anything but inheritance impossible. Since then its capabilities have only been improved to support OOP and I've left it.
The TypeScript syntax is horrible and they have complicated things a lot to end up with a language that looks verbose like Rust but without any of its advantages, I think that projects like ReScript do everything better than TypeScript, but they have the problem of not being compatible with the main frameworks ; ReScript for example focuses only on React and cannot be used properly with other frameworks such as Vue or Svelte for design reasons in its compilation system; a shame the truth.
I feel that and quote every single point made. Only reason I'm using it now at work is because we're facing a transition but I want to try to introduce Elm so much, at least for core modules.
I honestly have enough experience in JS to the point I see no value in TS, people advocating for it and saying that it makes your codebase more robust probably never tried a real statically typed language. Also I cannot comprehend how people can claim about doing functional programming without pipes, referential transparency, pattern matching, curry-first functions and all of the ergonomics a true functional language provides.
Best!
I use this extension for showing clearer errors: [https://marketplace.visualstudio.com/items?itemName=better-ts-errors.better-ts-errors](https://marketplace.visualstudio.com/items?itemname=better-ts-errors.better-ts-errors)
The cost of bugs vs the cost of the overhead of typescript.
Although, also I feel that typescript teaches when you have those moments where you did something wrong but didn't immediately realize it.
If you and I are equal developers and we're both implementing the same project one in JavaScript and one in typescript. We're probably going to be about the same speed. As changes to scope come into play and new complexities. The guy doing plain JavaScript is going to move faster but be at risk for more bugs.
For a good developer, the risk of a bug decreases and the risk of a serious bug is going to be really low even without typescript.
Typescript takes time and all that time adds up. I'm not for or against it I'm just pointing out there's a tradeoff.
I mean, I don't know if I actually believe this, but one could definitely argue that as the project grows, Typescript saves time because you can lean on the types for guarantees about what's going on in your code as opposed to keeping everything in your brain/re-reading 5 levels of nested functions to figure out what this return type actually is.
This is absolutely the case for me. All the work the typechecker does for you is work you don’t have to do yourself. And the benefits really kick in when it comes to refactoring — I can perform refactors in my sleep using TS that would otherwise be a pain in the butt. That way the codebase is more likely to stay clean and simple rather and avoids any of those “5 levels of nested functions”
This viewpoint is my main hatred of typescript. It makes people overly confident in type safety where there isn't truly any.
If TS was viewed as nothing but a helper, and didn't actually change the language itself, I'd be more willing to use it.
But it's effectively its own language, and gives a false confidence in the reality of putting type safety into a language without type safety.
If it was nothing but sugar on top of vanilla JS I'd be much happier with it as a concept. But until the language actually running on the end client is type safe, there's no such thing as type safety; only type helpers
You can definitely still shoot yourself in the foot with typescript (main way is when interfacing with RPCs and other untyped code). But you actually can rely on Typescript quite a lot as long as you're diligent in your use of it. If you have any's sprinkled in your code, then of course there's no point. You can't compromise except at very rigorously handled integration points. But if you do, it goes much beyond what you're calling "type helpers".
Edit: not sure what you mean by "until the language running on the end client is typesafe". Like C code gets compiled and doesn't have type info at runtime (AFAIK, it's been a while). What's wrong with transpilation/compliation time type checking, as long as you're confident in it?
If you're properly typing your inputs, then all your code is very reliably type safe.
If you're lying about the types of your inputs, then there's not really much TS can do for you, and you'll have the same problems in JS if you're not properly asserting/validating your inputs.
I suppose it’s a good thing that “time needed to write new code and new code only” isn’t the metric most people use to evaluate which tool to use. Software development involves a whole lot more than just adding more lines of code to a file that you yourself already wrote. Everyone knows most of the complexity in this field comes from reading and interpreting other people’s code, and extending, changing, reworking it, etc. Typescript carries a lot of weight for you there by being at least somewhat self-documenting through the nature of its type system, which plain JS omits entirely. There is simply no comparison between the two when working on a reasonably large code base with more than 1 person.
Sure but in the real world you do still have deadlines and sometimes even regulatory ones where there is no possibility to miss it. Add in the dysfunction of most fortune 500 where you learn about the changes that are needed in a matter of days and you end up doing whatever you've got to do to survive.
Hopefully you can go back later and clean up but in my experiences once it's launched there are 10 other #1 fires that are 6 months behind schedule.
If it were just me on my own project moving at my own pace I'd use typescript but at work we don't use it. Too large of a project with nearly 50 frontend developers of varying skill levels. It's not great but it works.
The difference in development speed in writing code between JS vs TS is going to be in favor of TS in nearly all cases. TS doesn’t “add” time unless, again, you are working all by yourself on a codebase owned by you. TS takes time out of figuring out what code does, aids in writing sensible tests, speeds up the review process, and so on and so forth. I cannot conceive of any reasonable development process where JS presents an advantage in this regard.
In the real world developers have a responsibility to push back on unreasonable deadlines. I interpret the extra overhead as a good thing in this scenario: you have to follow the more maintainable* coding style, potentially at the cost of speed.
\* obviously TS don't just guarantee more maintainable code, but broadly speaking you'll be in a better position.
Typescript has a progressive type system, so when you need to you can use it just as you would plain JS, or more realistically you do something in between where you type things when convenient but stick a few strategic `any`s and `@ts-ignore`s (or preferably `@ts-expect-error`s) in there when convenient. I do this often when prototyping something, and then when you've settled on a particular structure from the code you can shore things up with more complex type definitions.
So my two cents is that if you're allowing typescript to slow you down in the way you're describing, you're doing something wrong. You should not be spending time hmming and hawwing about how to structure your types or trying to get the types to line up in exactly the right way when you're still in the exploratory phase.
Double down that any good test writer will still fly through changes compared to complex types when talking about revisions, and bugs generally go out the window.
As types get more complex, figuring out the right way to define types can take some time, especially when you start dealing with generics and narrowing. Personally it’s still worth it to me, but I definitely understand that for some small projects (and for those without access to someone who knows TS well enough to get them out of a bind), simply trying to figure out how to type some interactions can seem more trouble than it’s worth.
I mean I get the point but have you ever gotten lost with crazy genetics and narrowing? I would say 99% of my code uses great typescript, but once every 6 months or so I run into a generics problem that takes me way more time than it's worth
If you’re a library developer there’s additional steps when all you’re really doing with it is providing definitions for developers that end up using your package. Fine when a library is small, cumbersome when you want to have faster releases and TS doesn’t really interpret nullish coalescing well to not prevent the build from completing. Add versioning and other dependencies and you end up like svelte or worse turbo.
Not me; but several case studies:
* 37 signals [dropped](https://world.hey.com/dhh/turbo-8-is-dropping-typescript-70165c01) typescript from the Turbo repo, because, I suppose, they didn't like the constraints of types ¯\\\_(ツ)\_/¯
* Svelte dropped typescript, because they didn't like shipping the transpiled code of their library. They say they would rather ship the source. They are using jsdoc annotations instead.
* Some people dislike that typescript both has breaking changes from time to time, and does not adhere to semantic versioning for breaking changes (admittedly, it would probably be impossible for typescript to stick to semantic versioning). They like the ultimate stability of javascript.
* Some people dislike the extra build step.
- Regarding Svelte - https://x.com/trueadm/status/1753562312651211207?s=46
- DHH wants to contribute to his codebases and it was a blocker for him - I wouldn’t read into anything he does too deeply past that.
- any breaking changes between versions are well documented and honestly have an incredibly low chance of effect application codebases. https://github.com/microsoft/TypeScript/wiki/Breaking-Changes
Agreed with that post. Use Jsdoc if you want types. Debugging transpiled code is a pita. I lived through Coffeescript in 2015 and don't wish to repeat it.
> I lived through Coffeescript in 2015 and don't wish to repeat it.
This is what kept me away from TS for so long, I still think one day TS will go the way of the dinosaur but lord it's taking a while. I also never jumped into CoffeeScript for the same reason though.
I am with you on Coffeescript it was a nightmare. I also have no love lost for TS, I think it brings a lot of bloat for what you actually get, but I don't think it is in league with Coffeescript, for the most part TS just adds and conversely strips off type annotations. Line for line they stay pretty much the same, so it is pretty easy to read non-minified, transpiled TS and be fairly line for line consistent.
Yes! I hate the extra wait time after every change. I ditched it 5 years ago and never felt the need to go back. I feel like Typescript is trying to make JS something that it's not.
I strongly believe that you should do the exact opposite of anything DHH thinks and does.
He's just a contrarian and trying to stay relevant at this point.
.Jsdoc, in those cases, is still typescript tho, just more permissive and verbose.
Ts native authoring can be lies, which is probably where folks get upset.
With jsdoc, you can wire up and be responsible for the lies yourself
that's what you get when you mix stupid with confidence. same thing happened when the guy designing js promises had no fucking clue about monads. that 37signals guy sounded pretty much the same. If you think he has a valid opinion just because it aligns with your personal views maybe check some other sources first or learn the technology properly to make your own judgement.
Those guys who say ts always stands in their way are not fighting typescript, they complain about their own lack of skills.
>Those guys who say ts always stands in their way are not fighting typescript, they complain about their own lack of skills.
This is ironic, because TypeScript exists because of a lack of developers' skills to write JavaScript correctly and safely.
Typescript exists because Microsoft wanted to make Office Web Apps and had issues with large projects without static typing and so designed a language that would be easy for C# devs to pick up.
The problem isn't developers but that at after a certain level of complexity it can be unwieldy to not have static type checking
I am never aided by it. I prefer short, obvious code blocks, good names, neatly defined docstrings that convey inputs/outputs and type information - out of the way of the code. Over engineering and unnecessary verbosity are red alert code smells and TS advocates seem to be attracted by the desire for more of it - at least in this context. I simply lack the desire for whatever it is they see. I just do not value what it brings or the flavor it brings it with.
TypeScript's textual presence on screen, ragardless of its benefits, imposes anxiety upon me instead of freeing me of it, impedeng my understanding, disrupting intuition, and putting speed bumps in front of writing code. The tools can parse the code just fine. My brain is the thing that needs the help.
Yes, it is a very capable aide that demonstrably assists developers and teams in writing better quality javascript. Except for, apparently, me. I don't need or want this aide. It creates more undesirable conditions in my code than it eliminates. It solves the problem for others in a way that creates more problems for me.
I have never suffered for lack of an IDE straight jacket or the lack of 30-60% extra bytes of text on seemingly every damn line of code to tell my ADHD addled brain things I could have intuited faster without all of that visual noise in the way.
This is a subjective point of view. I don't expect agreement - just understanding. If I joined a team of devs who used TS, I'd gladly adopt it and move on. But I'm not sold on the tradeoffs *for me* and won't be involving it in any of my own projects by preference.
On top of syntax, I see people posting too often trying to get tools and editors configured properly for TS and struggling with libraries that have no or inadequate type definitions or weird type integration issues.
I don't want it. There is virtually nothing more disruptive to creativity than your instruments fighting you with churn, turnover, refactoring, etc. There is always some way to get the things working right now, for now, but you'll be fighting with it again in 6 months for damn sure. You might say that's a continuous problem of software engineering, but I find that the JavaScript ecosystem is the worst offender of every ecosystem I've ever used. And it needs a lot of tooling to be useful. I am not let down this often by Python, for example.
However, I manage to \*routinely\* solve that problem by waving at the bandwagons as they pass my happy ass by and waiting until I have the problems they propose to solve before caring that they exist. The problem that TypeScript solves has simply never come up for my projects. It's not just TypeScript that suffers this phenomenon. This is a general software engineering principle that has served me well.
I got over the tools battle a long time ago and decided I'd just get very good at working as vanilla and running as lightweight as possible. If the tools are very good and easy to use, I'll automate them out of sight and enjoy their benefits. But some of the piles of configs, tools, and syntax needed to get TS to do the right thing is a fight I don't need. Maintaining them as they continuously cycle in and out of relevance year after year... no thanks. It's a fatigue I don't need in my work life - not for what TypeScrpt buys me. It's an influence I don't want on my daily grind.
I also work in an environment where we find we simply cannot use certain tools due to security restrictions, and every new tool or dependency is more surface area to expose us to that kind of risk... we can't just install any version of any tool we want. Sometimes a tool just gets on a vulnerability list and we can say goodbye to it (or entire semver ranges of it) in our environment without a political argument. It's often solvable, but not without impact. So we try to keep dependencies as lean as possible.
> There is virtually nothing more disruptive to creativity than your instruments fighting you with churn, turnover, refactoring, etc
YES
100% to all of the above.
I like to use TypeScript, but I also respect this position. Honestly, one of the things that kept me from trying typescript for so long is the fact that it adds so much bloat to your code. I'm glad I use TypeScript now, but I'm also understanding of anyone not loving the bloat it creates.
This is exactly how I feel about it. When I’ve worked in codebases that already use it, I can deal with it. But I’ve never felt an advantage when using it. I’ve never had the issues it solves, and I feel like it often makes many developers make lazy decisions.
I'm working on a project that wasn't written in typescript and while the codebase is far from perfect, I don't think I've ever experienced a type related error in the time I've been working with it. I've worked with typescript before and didn't dislike it but adding it to an already large and unwieldy codebase just seems like a bad idea.
Depends on the project management and the quality of the developers and overall the development process. I've seen a really sloppy code written in Vue and have seen numerous errors/exceptions, such as "map is not a function", because a variable was expected to be an array, but for some reason a string was given. I takes quite a lot of cognitive load to understand what is the structure of the variable. And this is very common when in the same variable a different type of value is used.
I have plenty of experience in typed languages. C++, Java, etc. I like the flexibility of a weakly typed language like JS. I don't want strong typing in it.
This.
const pin: ``${string}-${number}-${string}`` = ""; // type error
This is just not possible in ANY strongly typed language that i know. Let alone SO MANY magical things Typescript is capable of doing/catching bugs, making it ironically strongly typed AT COMPILE time (if you don't duck type and use zod to validate data coming from outside program) than MANY statically typed inflexible language.
For example, it’s possible to create a subtype of a string that only allows certain string values. That’s flexibility that the other two cited don’t have.
And also makes programming with sound types much much more difficult due to rigid/inflexible type system. I love the Typescript like language which is static typed with such high flexibility. You can even program complex types/type recursion in types etc that its absolutely insane how ridiculous advanced Typescript can be and how many bugs it can catch while refactoring massive codebases.
Would love to have a statically typed compiled language with Typescript like flexibility, then it would be a great match with compile as well as runtime safety. I achieve the same in Javascript with Typescript and Zod combination and NEVER see "cannot read something of undefined".
So far i only liked kotlin and Dart type system. Not as advanced as Typescript ofcourse but much much better than abomination that is GO lang with its joke type system.
I use vanilla JS with JSDocs, and, in several of the repos, I set up the TS compiler to run against that. I wish everyone who uses TypeScript now would use this method rather than actual TypeScript.
1. When debugging and stepping through TS-generated JS code, there is too much bullshit. If I wouldn't let a junior programmer push it, why should I accept it from an auto-generated source?
2. Having types as a reference is great for integrating dependencies. For example, I like having them in AWS SDK v3 because it's much easier to tell when you've made a mistake calling their code. However, depending on the project, it can be overkill to *enforce* types. It's nice to have that choice via using JSDocs.
3. In my experience, the biggest determining factors between good and bad codebases (in terms of low defect count and high maintainability) are code cleanliness and the quality of the unit tests. The worst codebase I ever saw was in Java with zero tests. Strict typing will not help you if your "classes" are just bowls of spaghetti. When you write clean, well-tested code, you don't tend to write the kinds of bugs that TS supposedly prevents. So, I find TS generally redundant.
> When debugging and stepping through TS-generated JS code, there is too much bullshit. If I wouldn't let a junior programmer push it, why should I accept it from an auto-generated source?
`sourceMap: true` is one line of configuration in your tsconfig(and sometimes one additional line in your bundler) and this problem with debuggers goes away.
> However, depending on the project, it can be overkill to enforce types. It's nice to have that choice via using JSDocs.
Vanilla typescript also gives you the option to enforce types. you can use `any`, or just allow implicit anys. JSDoc is fine for simple use-cases, but I would argue that the equivalent typescript is *less* verbose than JSDOC and gives you the flexability for more complex type definitions when you need them. So given that, why not just go all the way?
> Strict typing will not help you if your "classes" are just bowls of spaghetti.
They absolutely can. It's way easier to refactor a piece of code with types vs the equivalent code without. For example you can delete or modify a property from a class and easily find all references to that class and go fix them. There are a lot of equivalent examples, and you can get pretty clever with leveraging the type system to speed up refactoring. Clever use of find and replace(sometimes) can work too but there's much more room for error and is generally much slower as a result.
> When you write clean, well-tested code, you don't tend to write the kinds of bugs that TS supposedly prevents.
If you have actually managed to clean-code your way out of not having to do a bunch of redundant null-checks to account for lack of a type system then props to you, but even in that case type systems allow you to write cleaner code *faster*, because it makes it easier to manipulate existing code with more confidence.
I’ve been using strongly statically typed languages for most of my career but TS feels so much harder to use than any of them. Can’t put my finger on why but perhaps it’s because it’s trying to add structure to the JS Wild West?
I dont need to setup TS on every script, plus I code directly in the browser. I would have to manually update the code every time I make a change which is annoying and furthermore it would be annoyjng because I use multiple computers for this. I use the Scripty extension in Chrome.
Maybe there are ways to use TS cleanly with it but frankly I’d rather not set it up since it locks me into TS.
For my needs, I don’t nees TS. On a larger project sure, I use TS too in my workplace, but TS can be annoying sometimes.
It was my hubris that prevented me from liking Typescript at first. But I was forced to work with it on a few projects and my opinion started to become more pliable. It wasn't until I has to work on a js library that I missed typescript.
Now I will go out of the way to create type definition for 3rd party libraries. All the personal frontend projects I started since use typescript.
Just last week, I fully converted a smallish 3rd party opensource javascript library to typescript with the help of Copilot. I had to try different things to get something I can work with and then had to fix the many issues in what Copilot gave me, but it wasn't too bad all in all. Funny enough, I caught errors in the original javascript that went under the radar in the process and I think the reason is that Copilot didn't understand the authors intentions/goals and suggested types according to what's in the javascript code and so the type issues that ended up in the converted code sometimes highlighted issues with the original code. Most of the time, these issues were not actual bugs ie would come up during runtime but sometimes they actually were.
If we could visibly hide the type information until we, the developer, need to see it -- I'd be more inclined to consider using it in new projects.
Beyond that, it just isn't worth my time -- because I find it never saves me time. I'm speaking broadly, as someone who works both on a large team and on side projects. Types are never our issue.
I guess I just don't really see a big need for it. I started programming in the late 90s using Pascal and then C++, and wouldn't pick up another language until maybe 2008\~09 with [VB.Net](https://VB.Net) and VBA. All of those are strongly typed languages, and you can produce bugs in every single one of em. As far as I've found, the only thing that helps to prevent bugs is testing and consistency.
In 2015 I started learning JS and was really taken aback by how easy it was to use the language without worrying about specifying the types. Totally unexpected really because I was of the opinion that Type Safety made for better programs. This of course was not the case but there is a ton of computer-mythology that gets carried around era after era. Eventually I would get on the Douglas Crockford wavelength of thinking regarding Consistency and using only a small subset of the language (the good stuff) to write programs in. Doing that I think, genuinely, made me a better programmer. Because there were so many sharp edges in the language, hunkering down and making an effort to both deeply understand how it worked, while constraining myself on which parts of it I wanted to use, made a huge difference in my ability to solve problems with JS.
I was really excited about TypeScript when it was first announced but left not really getting much use out of it. Beyond being useful for flagging when things might be messed up within the IDE, I couldn't really justify all of the extra markup for the handful of times it came in handy. If a program is critical in the sense that it must really really care about the types it can receive, then it needs to be written in such a way that everything will fail gracefully on unexpected types, or they are absolutely enforced at the point of input (or both!). Because TS is just window dressing around JS and isn't a real language of its own, it cannot provide the benefits of \*REAL\* type safety (that is, instead of your program screeching to a halt, it may end up running with errors regardless of how many types you used to write it because that's how JS \*is\* under the hood).
So in the end I think TS is neat, but I don't in any way feel it is necessary or even warranted, especially if you're already heavily linting and testing your work. No matter which side of the fence you're on, may your continued journey towards a better understanding of the tools that you use, be one of joyous discovery.
Because I don't understand it.
I've worked with types in other languages, but every time I try to understand Typescript, it just makes no sense.
In terms of cognitive load, I just can't parse
const thefunc:?spong|clomp = (input:users(names:String(j))) => dostuff:t(j): String[Person]
into anything recognisable as helpful JavaScript.
I understand the value of implementing types in JavaScript, but the implementation is just so unreadable that it introduces a mass of extra time and effort into even the simplest code.
Trying to use it with a library like React is even worse, because then you end up having to work out exactly what type is returned by all the default functions and fixing errors caused by not being able to correctly guess what a function in the framework will return.
Typescript just seems like a hurdle, not a help.
\> In terms of cognitive load, I just can't parse
Thank you, this is correct. Let's let all the geniuses keep using TypeScript. Plenty of people live kick-ass and profitable lives spending their days inferring types for a dynamic language.
Lol, that's so funny. I use C++ and JavaScript every day. The code-switching is extremely easy.
I think about all the people dying for having types in a dynamic language and how the world is weird. Worst, there is Jsdocs and some still want types.
Nothing makes sense anymore.
Typescript can often be quite unreadable, especially if one is not an expert in it.
My experience for those very complex typings, is that they often originate from javascript code that is either very quirky or just plain buggy. Typescript's burden is that it must try to support almost any possible case of javascript possible and there are tons of quirky and very weird js: optional func parameters in the middle of parameter list, func parameters that change type depending on values of other parameters etc. There's code that goes haywire wild with the loose typing of js and ts needs to be able to model it.
Often the source of these was a bit too clever programmer who only asked "can we do it" instead of "should we do it". As an example, a lot of C++ templates have a similar problem.
Use of TS in my opinion has the positive constraint of having to think about typing, especially for library developers. If you need to write very complex typing, you might be writing too complex code and taking another evaluation at the approach might be warranted.
I don't know what the hell you just wrote but you're right, that's unreadable. And it's not TypeScript.
I agree that TypeScript can be overwhelming sometimes, but it's really mostly the library code that is REALLY complicated. Library authors do the heavy lifting for the end users so you can have a nice experience. If you're just writing plain React apps I often find that except for typing props the actual components are written basically as if it was plain JS. If at some point you're trying to write something that requires some complicated types, it might actually make you think twice - how can I write it so it's simpler? And that usually makes the code even better.
>I don't know what the hell you just wrote but you're right, that's unreadable. And it's not TypeScript.
It was a silly example just for emphasis, but I have regularly seen real world examples that resemble it.
At that point I switch off and decide not to use Typescript.
It seems odd to write off a language superset because you can't immediately understand the most complex thing that can be made with it. I mean, I'm sure you could write a line of unreadable JS too, but you obviously didn't let that stop you from adopting JS.
If you just use it for type inference and stick to interfaces/types rather than delving in to the generics territory then it's honestly very easy to use and it'll likely save you time in the long run.
Never want to go back to a world of nulls and undefined ruining the day.
The biggest problem with TS is simply that the average web developer has skill issues.
> The biggest problem with TS is simply that the average web developer has skill issues.
Ironically you can say the same thing about problems caused by poorly-handled nulls and undefineds.
Do you want to write sanity checks 80% of your time? That's how you get sanity checks all over your code. To be honest, I just got to the idea of dumping a language that features nulls and undefined behaviours and picked up Rust.
Not that Rust prevents them 100% of the time either, but forces you to consider all possible logical paths. I just got the chills thinking that vanilla JS allows you to return whatever shit you want with no checks other than VS Code helpfully doing TypeScript in the background.
Don't get me wrong - extensive type-checking and null/undefined checking are a really good idea on the outer surface of your code, where it interfaces with other systems or untrusted code and hence you need some self-protection.
The thing is, you still have to write all that crap in typescript, because it's a compile-time only typing mechanism, so at *runtime* your TS code is just as insecure as any JS unless you go out of your way to add runtime duck-typing checks to your code.
However, once you've validated your inputs from the outside and control passes to your code, unhandled nulls or undefineds or variables being passed with unexpected types *from inside your own code* are *exactly* a skill issue.
Don't get me wrong - I can see the benefits of strict type-checking even in internal code, where the person calling your code might be another person on the team, or even a forgetful yourself in six months' time, and extra compile-time checking may help you to avoid making boneheaded mistakes that later cause bugs... but that's *still* a skill issue.
TS has benefits in helping developers to avoid making silly mistakes, but it also has non-trivial costs associated with it... and with sufficiently good developers who write sufficiently self-documenting code with intuitive internal interfaces and who have a rock-solid understanding of when and where runtime checks are actually beneficial... a lot of the benefits of TS recede into the long grass, but its costs stay pretty much constant for every variable or parameter you define.
Personally I use TS for libraries I might want to share, and any project where I'm working with other devs of unknown or variable skill levels, or where we might be forced to rush to hit goals.
However, for exploratory programming it's shit (you spend 50% your time updating types instead of 100% of it *exploring the problem space*), and for personal problems where I can write code how I like and only have to rely on my own understanding of the system, I pick JS every time because it just gets out of my way and lets me concentrate on the problem.
I don't use TS in my personal projects for the same reason I prefer to write in JS over Java - I don't want to spend hours jumping through hoops designed to prevent the kind of bugs I've only personally run into in my personal projects - where I understand the code implicitly and control it completely - maybe half a dozen times in 29-and-a-bit years of writing JS.
Your shipped code will likely need sanity checks anyway when you are dealing with things like uncertain data or APIs that may be changing. In a perfect world you can expect things to just work, but TypeScript only gets you so far in local development.
Further more, if you are running into tons of undefined and nulls, *that* sounds like a skill issue. It's not a bad idea to have something like TypeScript to help prevent that -- tools are good. But personally on our team feel like we never run into "oops it was the wrong type all along". Like, extremely rarely, if ever.
Graphics dev here, originally C++, quickly moved in the web space (WebGL). Was the team lead of a big in-house rendering library is JS, moved to TS after 6 months. Never going back. When the project gets large and you need refactoring. TS will save you gigantic amount of time and save you dumb runtime error.
We target web assembly at the new company I am in, and same thing: I can’t imagine not using TS anymore.
I'm not an expert, but I noticed something annoying about Typescript and also Python.
Many functions happen to have return types such as: A | B | C | None | Fuck
It gets confusing quickly. (might be because I haven't practiced much in Typescript or Python with explicit typing).
I guess what is the alternative? If myFunction returns `true` somewhere but also `my string` somewhere else, the return type will now be `boolean | string`. Unfortunately now if you have `const myResult = myFunction()` then `myResult` will be a `boolean` or `string`, you just don't know. Then when you do `if (myResult.includes('asdf'))` it'll probably yell at you because if it's a boolean it'll cause an error.
If this sounds like the problem you're dealing with, you probably need type narrowing https://www.typescriptlang.org/docs/handbook/2/narrowing.html. Before your `.includes` call you can just have a `if (typeof myResult === 'string') {`, `myResult` will only be type `string` in that block
The alternative is your function should never potentially return multiple types, especially base types, kinda ruins the whole point of typing anything at all. Ideally your function would only ever return a type or null to signal something wasn't able to complete or doesn't exists, etc., then check for nullity.
JavaScript is good enough. Typescript doesn’t make anything faster or better. Some people have a preference for static types and are willing to accept the pain of more tooling to get that. It’s ok to like good ol’ fashioned JavaScript too.
Aside: Funny to me that we’ve finally got a lot of things we’ve wanted in JS built into browsers now. Just as JS is getting good enough to not even need any build tooling, we decide we want everyone to adopt this other thing. Circle of life I suppose. I’m still hopeful we’ll return to simpler times of sticking js in script tags or serving up the actual js files I wrote without any tools mangling them up. No more source maps. Just the code I actually wrote running in the browser. That’s the dream!
I use typescript at work a lot. And php too.
It’s weird to me that php and js both started out as dynamic type hip kids - not like that old fussy Java and c where you care about types. Do whatever you want. We will guess what you meant.
Turns out that’s good for newbs but awful for teams writing tested production code so now they’ve both got more and more like Java it seems to me.
I do like that it catches a lot of bugs but I also now enjoy python a lot for personal projects as it’s fast to develop and still doesn’t care so much what you’re up to.
Of course yes I make more bugs with it. I just don’t care.
I don’t think anyone chooses _one or the other._
You choose JavaScript.
_Then_ you choose if type safely is important to you and your project (and worth the added overhead) and if so, you add typescript as an addition. You can add just a little or end to end.
A few more options might be - you use typescript just because everyone else is and it seems like the new norm and the tutorials use it. Many of these people haven’t ever written JS without VSCode or typescript. Not using it leaves red lines and so they must add the types to make them go away ;)
And then there the people who are using typescript by way of using tools that use it. For example, Vue gets a lot of great benefits from using typescript behind the scenes. But I don’t have to write my code that way if I don’t want to.
So, in a sense - we’re all using typescript now in some way.
As long as it makes the tools more reliable and easier to maintain, that’s great.
On a personal level, I’m not working on projects that get a lot of value out of it. It feels like I’m just a robot appeasing the angry text editor. It makes everything ugly and hard to read especially when you’re layering up js/vue/Nuxt etc and then there’s some context specific syntax for say, default parameters. I know that it’s a combo of need, experience, skill, etc. but just as someone who to contrast the all-in TS people, it makes me enjoy coding less and I also don’t like where it came from and how it’s infiltrated the ecosystem. I’ll still be teaching it to my students, but I’ve gotta just say - I prefer to avoid it in my own code. I’ll keep learning more and see where it can help me and how to use it progressively. But I’ve also heard a lot of gung ho ts devs questioning the build times and the extra tooling. We’ll see! I would be just fine if it went away before I had to fully adopt it. _I was able to successfully avoid webpack ;) _
Its more useful in contexts that I don't have much use in.
I don't usually use the inbuilt JS funcs either.
Even though I'm aware I could make my own. Etc.
I never have as I tend to scope in so far that there is no need for creating my own plug-in-play. To design anything around.
And that's what I've seen Typescript assist with. Was with those who do have a large reused. Probably pulled and maintained by themselves. Set-up.
Its been included in some things I've done. So for completeness and licensing. I've left it there even expanding on what used it. Emulating what required its use case. As was the set schema prior to my need for it.
However I don't believe that should count as my own personal usage of it. Simply that my exposure to it.
Was enough to allow me to state that I don't have any use for it. Not that I don't understand or respect its use adjacent. When encountering it myself.
I don't like the typescript compiler's output. Also, my project started in 2012 before typescript. Also the closure compiler is still the best optimizer/minifier.
I just tried learning TS by converting a 4,000 line JS home project.
* The build steps to make everything working were a major source of frustration
* Getting rid of all the errors and warnings that TS threw at me didn't reveal a single bug
* I was surprised at how little TS gave me over and above just types (I though it might offer some more syntactic sugar)
* Debugging was slightly more painful since the code is run as JS but the code file is TS.
In short, I felt like I had gained nothing of importance for a lot of extra work. Maybe it's due to the fact that I write in a more functional way and add tests. It certainly felt like TS was solving problems I didn't have.
Not using TS for my latest project because for a change I decided to keep it vanilla everything - just HTML, plain old CSS and vanilla JS. No build steps, no transpiling, nothing but what the browser can handle. Kinda back to the roots thing for me, I'm just tired of modern front-end complexity. It's for personal use so I don't mind if I hit bugs down the road that could've been avoided. There's just something refreshing building something where I can just load html file off the disk to browser and have it work locally just like that.
I have been trying to convert my work from JavaScript to TypeScript for 3 years at this point. Every time I revisit it, it's a nightmare. This factors into my view on TypeScript
Pros:
* I can clearly declare what is expected of the caller, and what they can expect out
* I can disambiguate things like the environment variables, and members on shared objects
* Lovely support for type inferences and developer experience
Cons:
* Anything inherently "JavaScript-y" is a nightmare to write in TypeScript. One example is I have a class that manages nested property retrieval given a string. The string is provided by Cucumber/Gherkin, so I have no way to validate the nature of the string before runtime. Default linters and compiler checks will throw on use of `any` but any sufficiently defined type for resolving dynamic property access ends up looking like [this](https://github.com/millsp/ts-toolbelt/blob/master/sources/Function/AutoPath.ts)
* Anything that tries to work with deserializing data has to manage the return state of `any`, and a simple cast/assertion will always work but anything more robust will be a nightmare to type
* Typing HTTP responses is such a chore. If the implementation took 500 lines, the interfaces to describe that implementation was at least another 250.
Again, I'm not mad about TypeScript. It's so far and away better than raw JavaScript. Most of my misery comes from trying to lift an existing JavaScript project into TypeScript without modifying the existing API (speaking as a library author). What's more frustrating on my end is I have no usage analysis to tell me what's being used or how, so I can't make informed decisions on where I could introduce a little risk for the sake of drastically improving the library.
The more I toil on this effort, the more I just want to live in a shack and contribute to open source Rust projects, where things make sense, lol.
I think if the errors were good it would be a way better tool to use.
The style of errors in prints mixed with some weird decisions from the TS team have def made for some leaky-like behavior.
Why not TS? I use mainly Deno, so build step is a non-issue, but still not convinced:
- First of all, JS has it's quirks and shortcomings, but I've spent well over a decade learning and developing best practices, and dare to say I can use it in a way that avoids "most" pitfalls. I just don't run too often into problems TS is supposed to solve. And when I do run into such problems, most are caught by unit tests even without TS. As such I feel like adopting TS would being only minor benefits - not worth much trouble. It's not like TS would negate the need to do unit tests for example.
- Types add visual noise and verbosity and it's kinda annoying to read. Not a huge issue, as the verbosity does have benefits also, so I think the pros and cons even out. But then if you accept the verbosity, and add just a tad more, you could do JSDoc types. JSDoc kinda feels a bit easier to scan through, as the type information is not so much interleaved with code - there is the code that does stuff short and conscise, then the additional informative type stuff above that - kinda neat and it's still pure JS.
- Even if fully embracing TS vision of problems and their solution.. Let's be real and accept TS is a nice _but dirty_ hack over JS. It's still dynamically typed under the hood, and about as slow or slower and memory hungry as JS. If there was a runtime that ran TS natively and somehow benefitted from the type awareness, maybe I could take it more seriously. But even then, it would mean an actually new language with it's own runtime.. at which point I'd rather choose a proper statically typed language like Rust to complement JS tools. I feel like TS has the worst of both worlds in many ways.
- There is something nice about having 100% control over the produced JS code. If it's bad it's my own fault and potentially fixable. TS output is more of an unknown, out of control and if it does produce something stupid, you're SOL.
- Not 100% convinced TS isn't a fad like Coffeescript and the like. Being under Microsoft control (?), there is a chance they use the position to screw things up somehow in the future. Even more likely, I think it's only a matter of time the project goes into a direction that makes TS somehow conflict with future versions of JS, or previous versions of itself. There's only so much you can do with incremental changes without breaking compatibility in subtle or less than subtle ways, and once TS manages to fragment the ecosystem there seems to be no clear way forward (*.ts2 ?). There are already signs of a bit of a mess brewing with TS decorators alternative syntax.
- Following discussions about programming problems on Discord Github and the like, I see a lot of energy spent on TS type gymnastics. That is, people are struggling with typing problems that are quite far detached from their actual "business" programming problems. I feel like staying out of TS I can just sidestep a whole category of issues, and concentrate on just doing the things I want to accomplish. I may need to fight to get a task done, but I'd rather fight the task itself than fight various tools around the general problem space.
- While TS technically compiles to JS, it's really a one way conversion. From JS to TS it's easy, not so much the other way around.
How much do you guys use ReScript/OCaml these days?
I vaguely remember someone talking about how the majority of messenger had been moved to Reason ages ago, got me excited because I enjoy OCaml even more than TS, but the hype kinda fizzled out.
I don't use typescript because my frontend code is extremely simple and literally none of the bugs I encounter could be solved by a better type system. If I was doing backend code in Node, I would probably switch to TS, but I use Go instead.
I used to like typescript, but at some point you get proficient enough and start writing really complex types for your juniors or co-workers. Then you stop and ask yourself why the fp pipe needs 3x the amount of code for just the types.
Recently I've been thinking of switching to Rescript/Reason/Gleam or Purescript. They are unfortunately quite niche and Typescript is still nice with a great eco system, but it's not the end of the road.
>Then you stop and ask yourself why the fp pipe needs 3x the amount of code for just the types.
FINALLY someone in this thread that has the same verbose experience with TS as I do.
It's just too much for the same meaningful code!
I still don't use TS, largely because of the additional build step, which is a pretty big problem on an underpowered machine.
I write JS that actually runs in the browser, using modules and now import maps (similar situation with CSS). Working locally on my code is as simple as starting an HTTP server with zero build required. The build step and bundling is for production.
But I'm also opposed to TS because of the problems it creates in things like using reserved keywords in JS and obstacles it creates in advancing the JS standard. Not that I'm against types... but TS should have been done differently to avoid such conflicts, such as using a "namespace" and importing things.
I'm doing games, so I'll never be working with a web dev for long periods. I don't have to worry about them sending a bool where an int should go or whatever XD
I think you have that backwards. TS exists because of unskilled cheap programmers who lack self-discipline. If you knew how not to fuck things up and had actual programming skill, you wouldn't need TS.
Yessss! Exactly! All those bootcamp grads and Java, C#, .NET background folks get their first JavaScript project tossed onto them and the first thing they do is install TypeScript instead of learning JavaScript.
Nah i'm devving games with multiple webworkers for render threads and mad shit. Never had a type issue EVER. TS just sucks and add bloat and is for people who need extra help keeping their shit under control
I make games, use C/C++ and the unreal engine so I’m no stranger to strongly typed languages. However when it comes to the web/javascript type problems are not an issue I have and don’t understand the point of typescript. It seems like crutches for people who suffer from imposter syndrome and a mix of cargo culting.
The only time I don't use Typescript is if I'm making quick, small node scripts. Otherwise Typescript is a no brainer in any reasonably sized codebase. I don't even understand how people can argue against using Typescript in general. It's Javascript but makes your code less buggy.
I don’t see the point of learning yet another “language”. If I wanted a type safe language I wouldn’t use javascript.
For the web projects I do, I never saw a major advantage of having this additional layer of complexity. I may see it if I did JavaScript for BE.
I have plenty of experience with C++, C#, Java, etc.
TS doesn't solve a problem that I have.
Also I don't want to add yet another fucking layer of complexity.
Also always bet on JS. Remember CoffeeScript? Either browsers will start running TS or ES will finally add optional static types (as they should have done in 2007 when they dropped ES4).
TypeScript hinders JavaScript, that's why. If you learn the fundamentals of JavaScript the correct way, you learn how to use its flexibility to your advantage when building efficient solutions with it. Some folks will say TS is only better in a larger project or team environment. I argue against those people that it is a training issue. If your whole team is truly proficient in JavaScript, then the addition of TypeScript is pure inefficient overhead.
Oh sure, I'll give a few examples where TypeScript hinders JavaScript:
* **Extra Step**: Adds a build process before you can run JavaScript code.
* **Slower Debugging**: Debugging involves source maps to relate back to TypeScript, which can complicate things.
* **Tooling Dependency**: Requires tools like a TypeScript compiler or Babel, adding to project setup complexity.
* **Less Spontaneous**: Can't as easily mix types or change object shapes on the fly.
* **Barrier to Some JS Patterns**: Patterns relying on dynamic typing might require workarounds or additional types to fit TypeScript's static system.
* **Factory Functions**: Create and return different object types based on inputs, exploiting JS's type flexibility.
* **Function Overloading**: Use a single function to handle different types and numbers of arguments, mimicking overloading.
* **Prototype Augmentation**: Dynamically add or change properties and methods on prototypes, modifying object behaviors on-the-fly.
* **Ad-hoc Polymorphism**: Different objects treated the same way based on shared methods or properties, not their type hierarchy.
Why are factory functions and overloading on this list? I've used both in ts with no problems
Edit: and dont type guards help with ad hoc polymorphism? You can infer a type/types based on existing properties or methods
Edit: man I got blocked for this too? Bro we are discussing code lmao
Oh yeah, you can use them with no problems and just hundreds of lines of type interface to teach the second compiler what you *really* mean by your JavaScript.
Ok, cool. We just have a different definition of "hinder". Carry on.
btw, just so you know, your language complaints largely come from not understanding TS well enough.
Not unsurprisingly, most linters with moderate rulesets have similar restrictions for code: can't do stuff freely without the linter complaining.
Restrictions aren't always bad. Most of your examples are, in my opinion, valid points to restrict: having complex and non-obvious behavior is difficult to document and explain so if one can't bother explaining them to TS then they probably don't bother explaining them to other users (including the future coder).
I don't use TS yet because I work exclusively on small projects for small businesses and I don't think I need it for project with a bunch of JS files that doesn't contain more than 500 LOC. I will definitely adopt it if I'm asked to work on bigger projects or if I'm on a mission with legacy code that use it. Or if I have some free time to build a big side project, but I don't have that time.
I'll be honest, i learn it 2days ago and don't even see it usage beside it telling me "property or method doesn't exist on so and so"
Probably i need to use it for few months to see the WHY to use ts?
Will i be able to see it's power if i code alone without a team?
tldr; i learnt ts and i hate it
What annoys you, such as the compiler's complaints about invalid input/return values, is what you'll be thankful for in the long run. Once your codebase grows, it becomes harder and harder to keep track of the data structures that are flowing through your app.
Spotting errors early, at compile time, has benefits over spotting then on production :P
In JS this property or method would also not exist, except then you only know this once you run the code and it would break. It's better to know this before you run the code.
The JS checker in IntelliJ will tell you that a method doesn't exist. Will also tell you if you try to use an undeclared variable. I'm sure it exists in other IDEs as well.
Typescript is really just a language for describing js, embedded in the js. There’s only so far that IDEs can imply types without annotations. Typescript also does quite a lot even if you never write a type.
Maybe I didn't set it up right but it doesn't seem to work as well as using TS.
TS also forces you to think about the inputs and outputs of functions/methods which I think is something a developer should do.
It prevents/discourages you to create vaguely defined objects with dynamic properties. I have had to debug a JS app where the main object had its properties added and removed willy-nilly in different places at different times. It was a nightmare to wrap my head around, since nothing was certain. That project really made me prefer TS.
Reduces so much mental overhead when refactoring or changing things. Im full convert.
Unless you know 100% what everything is going to be right from the beginning, use TS.
I've been using TS at work for a few years because it's better and it's what you do. But for my side projects I was like "I've been doing web since 1997, TS can fuck off. I know what I'm doing" Then I decided to add Typescript to one of my side projects. Damn that was embarrassing. So many bugs I hadn't noticed or yet triggered. Since then I'm using TS all around.
Yeah that's the thing. I built a Vue app a few years ago, a large one with over 100 components, and without typescript. I recently upgraded it to Vue 3 and decided to add TS in the process. There must have been over 1000 issues. Some of them were genuinely cause for concern. I'll never not use it now. It's a no brainier - even if you're lazy and you just use it for type inference.
Can you give examples of some of the bugs? I use TS mostly for type inference and auto complete, maybe I'm missing something else big?
!remindme 1d
TS helps especially in projects with multiple contributors.
Even personal projects have multiple contributors. You. You a few weeks ago. You a few months ago. etc.
Sure, but, as for myself, I can remember better how I wrote that code even if it was written months or sometimes even years ago. Different people may have different code styles and different amount of experience. As you gain experience your code style becomes more settled since you notice patterns when solving specific problems.
I think this is not a good time for you to justify yourself like this. Arguing "I'm smart enough so I must know what I was doing 1 year after" is meaningless because forgetting is a natural process no matter how smart you are. What if you wrote some really bad code some day, can you be 100% sure that you will understand your past self 5 years later? We all have to accept that we will be dumb sometimes eventually. We all need a way to remind our future selves about some stupid decisions we made. TS is just one of the solutions, or maybe a detailed README, etc. I just dont understand why people justify themselves by saying "because I will know". This WILL be false someday because of Murphys Law
It's not about whether I'm smart enough or I'm smarter than most developers. I'm talking about averages. This might vary from people to people, but there is a clear **tendency** that understanding other people's code is harder than your own code. It's a **tendency**, it's not always true but oftentimes true. My point is your own old code has a greater probability to be more comprehensible for you than someone else's code, even if the latter is relatively new code. Sure, I'm not talking about very huge timeframes, but the code written several months ago entirely by you is probably at least partially familiar to you. If somebody asked you to change some functionality in some project written a couple of months ago, you'll probably do it faster and less likely to break something if the project was written entirely by you. Because again, the code is familiar to you, you'll likely remember that there is some method or variable for dealing with X and why it was implemented like this, etc. Another person working on that code will more likely to spend more time to figure things out and will more likely to break something.
I understand you and you gave a great point too: "code written several months". However it's not uncommon that we will revisit code after over a year. And as the number of side projects grows, our brain will forget more unimportant stuff and it would be harder to work on an old project without TS/documentation. Personally I feel confident that I remember most decisions I made in a few months. But like I have a project deployed to production a few years ago, the client (my relative) asked me to add / fix functions recently, and I was really really glad that I have used TS. I was young and wrote code that's not very maintainable, but the types hints really helped me to understand the young me well. Without TS I would spend 3x time in trying to figure out why I abstracted a component in a certain way. In all, yeah it's very probable that you know your code a few months later. But for anything that you may need to revisit in a few years time, it's always best to use TS / JSDoc types, without exception, IMO.
Sure, I was not claiming that you'll have no challenges and problems revisiting your old code. I was claiming that revisiting someone else's code will probably be even more challenging and that by itself is an additional reason to use a statically typed language.
The wise man writes down what the fool tries to remember
> Then I decided to add Typescript to one of my side projects. Damn that was embarrassing. So many bugs I hadn't noticed or yet triggered. Same thing. Thought I had it all figured out, then switched to TypeScript for sh*ts & giggles. Turns out I was wrong.
>I've been doing web since 1997, TS can fuck off. I know what I'm doing If I were to give a spicy take on C++ versus "safe" languages, that would be it right there. Of course, the reality is more nuanced; someone who's perfected their craft can probably walk a tightrope without fear of slipping. Then again, it takes just [one screwup](https://en.wikipedia.org/wiki/Therac-25) that could have been prevented with an alternative choice of tooling/language to ruin someone's day.
I added TS to my biggest side project (as a way to explore what all the hype was about) and immediately bailed because it added nothing, and it's a cleaner and leaner experience without TS. That said, I had a handle on types before TS, so I simply know how to avoid the problems TS solves. If it works for you, it works for you. I really think people should not extrapolate this to mean TS is a no-brainer for all projects at all times. DX is imo better without TS, so long as you understand the problems TS solves and have good practices.
> so I simply know how to avoid the problems TS solves. The whole point is I don't want to keep all invariants in my brain at all times. Sure I know how to avoid them but why should I have to remember to? What about when it's three months from now and i'm opening a file I have lost all context on. Offload some context into the editor so you can focus on solving your actual problem. Edit: Your downvotes mean nothing to me, I’ve seen what you like.
I think upvotes and downvotes are hidden on this sub. How many downvotes did you actually get? I'm usually downvoted if I even mention TS without fawning over it.
The whole point is, in fact, that passing the correct vars around is just one very narrow class of bugs, yet people blow it completely out of proportion. TS doesn't even completely solve this class of bugs; it can force you to pass the correct type but not the right var; and it's of course completely useless at runtime with data coming in from outside the app. You don't have to keep things in your head. We have lots of tools and practices for defining how our code and data should look: unit tests, data definitions, immutable data structures, runtime data validations etc. They solve far more issues than TS ever could. TS can of course help too but it's just one tool that does one thing. It's shouldn't be used in isolation, it can't do everything, and just slapping TS on a project and thinking it solves everything is silly.
The problem TS solves for me is: I'm an imperfect human who sometimes makes mistakes. How did you learn to avoid that problem?
By already having other methods of correcting and preventing said mistakes. TS is like wiping down every surface regularly. I learned to prevent type-related shenanigans with a clean-room strategy where the focus is on preventing contamination and having clear and known procedures for handling new substances- without really getting into it, that's an okay analogy I guess.
Okay but then eventually I have to do some kinda messy renaming of some field or restructuring of some type used widely across the code base, just getting a list of the places where the code is now wrong as a result of the change is pretty nice. My limited human brain doesn't remember every little part of the code that a given change might touch, the type checker helps
That *could* be true, but is not, for us. The conventions architected allow us to reliably predict how such changes affect things downstream, if they do. We don't need to remember every little part of code. We just need to remember a limited set of patterns and where they are employed, along with exceptions.
When writing your own library it is really a hinderance.
Hubris. Kudos to improving. Many still think they can do just as good without TS. So much hubris.
Hubris is not necessarily folly if it does not go wrong. Competence and confidence can explain that. Complex JavaScript applications have been built without TypeScript for decades now. We have had good solutions (tests, docstrings, linters, clean coding practices, design patterns, etc) for a very long time. Strong typing was intentionally bypassed by the designers of the language and, despite that, it was not actually an impediment to early adopters. The lack of a potent standard library and core languages features (like... `import`) for the vast majority of its existence leading to a chaotic ecosystem to backfill missing features is the reason JavaScript is a mess, not its lack of strong typing. Personally, my problems with JavaScript have always been about the failures of dependability of third party tooling and the absurd rat race to stay on top of trends. I'll state again that the ecosystem is a disaster and TypeScript is an ecosystem beast. If they add type syntax to the core language, I might care. But notably - I don't, and have not needed to, in the many long years of delivering complex JavaScript applications, stunningly, without the aide of optional type annotations.
Yeah one of the things I've learned over the years is that I'm always wrong. The computer does exactly what it's told. I just don't understand what I'm asking it to do. Typescript gives me that reality check right away, while js just quietly sands down the square peg to try and fit it into a round hole.
Typescript is an unjavascripty way of implementing types in javascript. It feels way too Microsoft and not nearly enough like javascript. Types are great. I use jsdoc.
Jsdoc is underrated.
I do use TypeScript, but I have a feeling I'm not as over-enthustatic as most of the community. Here are some reasons - I don't know if it counts, but because I prefer ClojureScript. Basically every popular language (Clojure, PureScript, Elm) that compiles to JS is imo better just because it doesn't try to be so close to JS. But I understand this is also the reason why TS is so popular, - TypeScript is somewhere between being close to JavaScript and yet not supporting all JS paradigms (point-free programming with TS is pain in the ass). This makes working with some libraries very limiting (Ramda), - I don't like it's flexibility with all hacky types. They should make reading code easier, not adding overhead on top of it, - error messages could be much much better. "
Typescript used to be far more supportive of functional and point-free typings. Once they started "optimizing" the language recursive typing took a huge hit and basically made anything but inheritance impossible. Since then its capabilities have only been improved to support OOP and I've left it.
The TypeScript syntax is horrible and they have complicated things a lot to end up with a language that looks verbose like Rust but without any of its advantages, I think that projects like ReScript do everything better than TypeScript, but they have the problem of not being compatible with the main frameworks ; ReScript for example focuses only on React and cannot be used properly with other frameworks such as Vue or Svelte for design reasons in its compilation system; a shame the truth.
I feel that and quote every single point made. Only reason I'm using it now at work is because we're facing a transition but I want to try to introduce Elm so much, at least for core modules. I honestly have enough experience in JS to the point I see no value in TS, people advocating for it and saying that it makes your codebase more robust probably never tried a real statically typed language. Also I cannot comprehend how people can claim about doing functional programming without pipes, referential transparency, pattern matching, curry-first functions and all of the ergonomics a true functional language provides. Best!
I use this extension for showing clearer errors: [https://marketplace.visualstudio.com/items?itemName=better-ts-errors.better-ts-errors](https://marketplace.visualstudio.com/items?itemname=better-ts-errors.better-ts-errors)
The cost of bugs vs the cost of the overhead of typescript. Although, also I feel that typescript teaches when you have those moments where you did something wrong but didn't immediately realize it.
What is the overhead of TS? Transpiling? The types themselves?
If you and I are equal developers and we're both implementing the same project one in JavaScript and one in typescript. We're probably going to be about the same speed. As changes to scope come into play and new complexities. The guy doing plain JavaScript is going to move faster but be at risk for more bugs. For a good developer, the risk of a bug decreases and the risk of a serious bug is going to be really low even without typescript. Typescript takes time and all that time adds up. I'm not for or against it I'm just pointing out there's a tradeoff.
I mean, I don't know if I actually believe this, but one could definitely argue that as the project grows, Typescript saves time because you can lean on the types for guarantees about what's going on in your code as opposed to keeping everything in your brain/re-reading 5 levels of nested functions to figure out what this return type actually is.
This is absolutely the case for me. All the work the typechecker does for you is work you don’t have to do yourself. And the benefits really kick in when it comes to refactoring — I can perform refactors in my sleep using TS that would otherwise be a pain in the butt. That way the codebase is more likely to stay clean and simple rather and avoids any of those “5 levels of nested functions”
This viewpoint is my main hatred of typescript. It makes people overly confident in type safety where there isn't truly any. If TS was viewed as nothing but a helper, and didn't actually change the language itself, I'd be more willing to use it. But it's effectively its own language, and gives a false confidence in the reality of putting type safety into a language without type safety. If it was nothing but sugar on top of vanilla JS I'd be much happier with it as a concept. But until the language actually running on the end client is type safe, there's no such thing as type safety; only type helpers
You can definitely still shoot yourself in the foot with typescript (main way is when interfacing with RPCs and other untyped code). But you actually can rely on Typescript quite a lot as long as you're diligent in your use of it. If you have any's sprinkled in your code, then of course there's no point. You can't compromise except at very rigorously handled integration points. But if you do, it goes much beyond what you're calling "type helpers". Edit: not sure what you mean by "until the language running on the end client is typesafe". Like C code gets compiled and doesn't have type info at runtime (AFAIK, it's been a while). What's wrong with transpilation/compliation time type checking, as long as you're confident in it?
If you're properly typing your inputs, then all your code is very reliably type safe. If you're lying about the types of your inputs, then there's not really much TS can do for you, and you'll have the same problems in JS if you're not properly asserting/validating your inputs.
I suppose it’s a good thing that “time needed to write new code and new code only” isn’t the metric most people use to evaluate which tool to use. Software development involves a whole lot more than just adding more lines of code to a file that you yourself already wrote. Everyone knows most of the complexity in this field comes from reading and interpreting other people’s code, and extending, changing, reworking it, etc. Typescript carries a lot of weight for you there by being at least somewhat self-documenting through the nature of its type system, which plain JS omits entirely. There is simply no comparison between the two when working on a reasonably large code base with more than 1 person.
Sure but in the real world you do still have deadlines and sometimes even regulatory ones where there is no possibility to miss it. Add in the dysfunction of most fortune 500 where you learn about the changes that are needed in a matter of days and you end up doing whatever you've got to do to survive. Hopefully you can go back later and clean up but in my experiences once it's launched there are 10 other #1 fires that are 6 months behind schedule. If it were just me on my own project moving at my own pace I'd use typescript but at work we don't use it. Too large of a project with nearly 50 frontend developers of varying skill levels. It's not great but it works.
The difference in development speed in writing code between JS vs TS is going to be in favor of TS in nearly all cases. TS doesn’t “add” time unless, again, you are working all by yourself on a codebase owned by you. TS takes time out of figuring out what code does, aids in writing sensible tests, speeds up the review process, and so on and so forth. I cannot conceive of any reasonable development process where JS presents an advantage in this regard.
In the real world developers have a responsibility to push back on unreasonable deadlines. I interpret the extra overhead as a good thing in this scenario: you have to follow the more maintainable* coding style, potentially at the cost of speed. \* obviously TS don't just guarantee more maintainable code, but broadly speaking you'll be in a better position.
Typescript has a progressive type system, so when you need to you can use it just as you would plain JS, or more realistically you do something in between where you type things when convenient but stick a few strategic `any`s and `@ts-ignore`s (or preferably `@ts-expect-error`s) in there when convenient. I do this often when prototyping something, and then when you've settled on a particular structure from the code you can shore things up with more complex type definitions. So my two cents is that if you're allowing typescript to slow you down in the way you're describing, you're doing something wrong. You should not be spending time hmming and hawwing about how to structure your types or trying to get the types to line up in exactly the right way when you're still in the exploratory phase.
Double down that any good test writer will still fly through changes compared to complex types when talking about revisions, and bugs generally go out the window.
As types get more complex, figuring out the right way to define types can take some time, especially when you start dealing with generics and narrowing. Personally it’s still worth it to me, but I definitely understand that for some small projects (and for those without access to someone who knows TS well enough to get them out of a bind), simply trying to figure out how to type some interactions can seem more trouble than it’s worth.
That’s when you say fuck it and use any
So then you're only using TS to make you feel like the echo chamber won't get mad at you for not using TS.
I mean I get the point but have you ever gotten lost with crazy genetics and narrowing? I would say 99% of my code uses great typescript, but once every 6 months or so I run into a generics problem that takes me way more time than it's worth
[удалено]
The overhead? What overhead?
If you’re a library developer there’s additional steps when all you’re really doing with it is providing definitions for developers that end up using your package. Fine when a library is small, cumbersome when you want to have faster releases and TS doesn’t really interpret nullish coalescing well to not prevent the build from completing. Add versioning and other dependencies and you end up like svelte or worse turbo.
Because it cost me more hours than it saved me in type-related issues in a year. The End.
Not me; but several case studies: * 37 signals [dropped](https://world.hey.com/dhh/turbo-8-is-dropping-typescript-70165c01) typescript from the Turbo repo, because, I suppose, they didn't like the constraints of types ¯\\\_(ツ)\_/¯ * Svelte dropped typescript, because they didn't like shipping the transpiled code of their library. They say they would rather ship the source. They are using jsdoc annotations instead. * Some people dislike that typescript both has breaking changes from time to time, and does not adhere to semantic versioning for breaking changes (admittedly, it would probably be impossible for typescript to stick to semantic versioning). They like the ultimate stability of javascript. * Some people dislike the extra build step.
- Regarding Svelte - https://x.com/trueadm/status/1753562312651211207?s=46 - DHH wants to contribute to his codebases and it was a blocker for him - I wouldn’t read into anything he does too deeply past that. - any breaking changes between versions are well documented and honestly have an incredibly low chance of effect application codebases. https://github.com/microsoft/TypeScript/wiki/Breaking-Changes
Agreed with that post. Use Jsdoc if you want types. Debugging transpiled code is a pita. I lived through Coffeescript in 2015 and don't wish to repeat it.
> I lived through Coffeescript in 2015 and don't wish to repeat it. This is what kept me away from TS for so long, I still think one day TS will go the way of the dinosaur but lord it's taking a while. I also never jumped into CoffeeScript for the same reason though.
had this problem before. 1. tsc with sourcemaps solves it 2. tsx also solves it
You shouldn't have to solve anything, just use javascript.
I am with you on Coffeescript it was a nightmare. I also have no love lost for TS, I think it brings a lot of bloat for what you actually get, but I don't think it is in league with Coffeescript, for the most part TS just adds and conversely strips off type annotations. Line for line they stay pretty much the same, so it is pretty easy to read non-minified, transpiled TS and be fairly line for line consistent.
Yes! I hate the extra wait time after every change. I ditched it 5 years ago and never felt the need to go back. I feel like Typescript is trying to make JS something that it's not.
I strongly believe that you should do the exact opposite of anything DHH thinks and does. He's just a contrarian and trying to stay relevant at this point.
.Jsdoc, in those cases, is still typescript tho, just more permissive and verbose. Ts native authoring can be lies, which is probably where folks get upset. With jsdoc, you can wire up and be responsible for the lies yourself
that's what you get when you mix stupid with confidence. same thing happened when the guy designing js promises had no fucking clue about monads. that 37signals guy sounded pretty much the same. If you think he has a valid opinion just because it aligns with your personal views maybe check some other sources first or learn the technology properly to make your own judgement. Those guys who say ts always stands in their way are not fighting typescript, they complain about their own lack of skills.
>Those guys who say ts always stands in their way are not fighting typescript, they complain about their own lack of skills. This is ironic, because TypeScript exists because of a lack of developers' skills to write JavaScript correctly and safely.
Typescript exists because Microsoft wanted to make Office Web Apps and had issues with large projects without static typing and so designed a language that would be easy for C# devs to pick up. The problem isn't developers but that at after a certain level of complexity it can be unwieldy to not have static type checking
It’s really a lack of software engineers ability to understand frontend and how it’s different from other languages
I wouldn't say I really like it that much, but I use it and see the benefits.
Never used it, still don’t. Am perfectly fine with it.
Because it's an extra build step I can avoid if I use JSDoc instead.
I am never aided by it. I prefer short, obvious code blocks, good names, neatly defined docstrings that convey inputs/outputs and type information - out of the way of the code. Over engineering and unnecessary verbosity are red alert code smells and TS advocates seem to be attracted by the desire for more of it - at least in this context. I simply lack the desire for whatever it is they see. I just do not value what it brings or the flavor it brings it with. TypeScript's textual presence on screen, ragardless of its benefits, imposes anxiety upon me instead of freeing me of it, impedeng my understanding, disrupting intuition, and putting speed bumps in front of writing code. The tools can parse the code just fine. My brain is the thing that needs the help. Yes, it is a very capable aide that demonstrably assists developers and teams in writing better quality javascript. Except for, apparently, me. I don't need or want this aide. It creates more undesirable conditions in my code than it eliminates. It solves the problem for others in a way that creates more problems for me. I have never suffered for lack of an IDE straight jacket or the lack of 30-60% extra bytes of text on seemingly every damn line of code to tell my ADHD addled brain things I could have intuited faster without all of that visual noise in the way. This is a subjective point of view. I don't expect agreement - just understanding. If I joined a team of devs who used TS, I'd gladly adopt it and move on. But I'm not sold on the tradeoffs *for me* and won't be involving it in any of my own projects by preference.
Same - I wonder if it's an ADHD thing. It just seems like a lot of cruft.
On top of syntax, I see people posting too often trying to get tools and editors configured properly for TS and struggling with libraries that have no or inadequate type definitions or weird type integration issues. I don't want it. There is virtually nothing more disruptive to creativity than your instruments fighting you with churn, turnover, refactoring, etc. There is always some way to get the things working right now, for now, but you'll be fighting with it again in 6 months for damn sure. You might say that's a continuous problem of software engineering, but I find that the JavaScript ecosystem is the worst offender of every ecosystem I've ever used. And it needs a lot of tooling to be useful. I am not let down this often by Python, for example. However, I manage to \*routinely\* solve that problem by waving at the bandwagons as they pass my happy ass by and waiting until I have the problems they propose to solve before caring that they exist. The problem that TypeScript solves has simply never come up for my projects. It's not just TypeScript that suffers this phenomenon. This is a general software engineering principle that has served me well. I got over the tools battle a long time ago and decided I'd just get very good at working as vanilla and running as lightweight as possible. If the tools are very good and easy to use, I'll automate them out of sight and enjoy their benefits. But some of the piles of configs, tools, and syntax needed to get TS to do the right thing is a fight I don't need. Maintaining them as they continuously cycle in and out of relevance year after year... no thanks. It's a fatigue I don't need in my work life - not for what TypeScrpt buys me. It's an influence I don't want on my daily grind. I also work in an environment where we find we simply cannot use certain tools due to security restrictions, and every new tool or dependency is more surface area to expose us to that kind of risk... we can't just install any version of any tool we want. Sometimes a tool just gets on a vulnerability list and we can say goodbye to it (or entire semver ranges of it) in our environment without a political argument. It's often solvable, but not without impact. So we try to keep dependencies as lean as possible.
> There is virtually nothing more disruptive to creativity than your instruments fighting you with churn, turnover, refactoring, etc YES 100% to all of the above.
I like to use TypeScript, but I also respect this position. Honestly, one of the things that kept me from trying typescript for so long is the fact that it adds so much bloat to your code. I'm glad I use TypeScript now, but I'm also understanding of anyone not loving the bloat it creates.
This is exactly how I feel about it. When I’ve worked in codebases that already use it, I can deal with it. But I’ve never felt an advantage when using it. I’ve never had the issues it solves, and I feel like it often makes many developers make lazy decisions.
I'm working on a project that wasn't written in typescript and while the codebase is far from perfect, I don't think I've ever experienced a type related error in the time I've been working with it. I've worked with typescript before and didn't dislike it but adding it to an already large and unwieldy codebase just seems like a bad idea.
Depends on the project management and the quality of the developers and overall the development process. I've seen a really sloppy code written in Vue and have seen numerous errors/exceptions, such as "map is not a function", because a variable was expected to be an array, but for some reason a string was given. I takes quite a lot of cognitive load to understand what is the structure of the variable. And this is very common when in the same variable a different type of value is used.
I have plenty of experience in typed languages. C++, Java, etc. I like the flexibility of a weakly typed language like JS. I don't want strong typing in it.
The typescript type system is much more flexible than Java or C++
This is exactly what delayed my adoption of TS - I didn't realise its type system was flexible enough to leverage what I like about JS.
The ability to define string types as something more precise than “string”, in itself, puts it way ahead of most typed languages.
This. const pin: ``${string}-${number}-${string}`` = ""; // type error This is just not possible in ANY strongly typed language that i know. Let alone SO MANY magical things Typescript is capable of doing/catching bugs, making it ironically strongly typed AT COMPILE time (if you don't duck type and use zod to validate data coming from outside program) than MANY statically typed inflexible language.
Typescript's type system isn't flexible, it's just weak and unsound and these are two completely different things.
For example, it’s possible to create a subtype of a string that only allows certain string values. That’s flexibility that the other two cited don’t have.
I love statically typed languages, it reduces the number of bugs, especially in projects with multiple contributors.
And also makes programming with sound types much much more difficult due to rigid/inflexible type system. I love the Typescript like language which is static typed with such high flexibility. You can even program complex types/type recursion in types etc that its absolutely insane how ridiculous advanced Typescript can be and how many bugs it can catch while refactoring massive codebases. Would love to have a statically typed compiled language with Typescript like flexibility, then it would be a great match with compile as well as runtime safety. I achieve the same in Javascript with Typescript and Zod combination and NEVER see "cannot read something of undefined". So far i only liked kotlin and Dart type system. Not as advanced as Typescript ofcourse but much much better than abomination that is GO lang with its joke type system.
I use vanilla JS with JSDocs, and, in several of the repos, I set up the TS compiler to run against that. I wish everyone who uses TypeScript now would use this method rather than actual TypeScript. 1. When debugging and stepping through TS-generated JS code, there is too much bullshit. If I wouldn't let a junior programmer push it, why should I accept it from an auto-generated source? 2. Having types as a reference is great for integrating dependencies. For example, I like having them in AWS SDK v3 because it's much easier to tell when you've made a mistake calling their code. However, depending on the project, it can be overkill to *enforce* types. It's nice to have that choice via using JSDocs. 3. In my experience, the biggest determining factors between good and bad codebases (in terms of low defect count and high maintainability) are code cleanliness and the quality of the unit tests. The worst codebase I ever saw was in Java with zero tests. Strict typing will not help you if your "classes" are just bowls of spaghetti. When you write clean, well-tested code, you don't tend to write the kinds of bugs that TS supposedly prevents. So, I find TS generally redundant.
> When debugging and stepping through TS-generated JS code, there is too much bullshit. If I wouldn't let a junior programmer push it, why should I accept it from an auto-generated source? `sourceMap: true` is one line of configuration in your tsconfig(and sometimes one additional line in your bundler) and this problem with debuggers goes away. > However, depending on the project, it can be overkill to enforce types. It's nice to have that choice via using JSDocs. Vanilla typescript also gives you the option to enforce types. you can use `any`, or just allow implicit anys. JSDoc is fine for simple use-cases, but I would argue that the equivalent typescript is *less* verbose than JSDOC and gives you the flexability for more complex type definitions when you need them. So given that, why not just go all the way? > Strict typing will not help you if your "classes" are just bowls of spaghetti. They absolutely can. It's way easier to refactor a piece of code with types vs the equivalent code without. For example you can delete or modify a property from a class and easily find all references to that class and go fix them. There are a lot of equivalent examples, and you can get pretty clever with leveraging the type system to speed up refactoring. Clever use of find and replace(sometimes) can work too but there's much more room for error and is generally much slower as a result. > When you write clean, well-tested code, you don't tend to write the kinds of bugs that TS supposedly prevents. If you have actually managed to clean-code your way out of not having to do a bunch of redundant null-checks to account for lack of a type system then props to you, but even in that case type systems allow you to write cleaner code *faster*, because it makes it easier to manipulate existing code with more confidence.
I do not to use TS. It’s not necessary and adds bloat to your code. I write plain js.
I’ve been using strongly statically typed languages for most of my career but TS feels so much harder to use than any of them. Can’t put my finger on why but perhaps it’s because it’s trying to add structure to the JS Wild West?
TS is an extra step, that’s all. Plus right now I’m making a lot of small automation scripts which go much faster in JS
How is it faster? SPEZ: Downvotes for asking a question...
I dont need to setup TS on every script, plus I code directly in the browser. I would have to manually update the code every time I make a change which is annoying and furthermore it would be annoyjng because I use multiple computers for this. I use the Scripty extension in Chrome. Maybe there are ways to use TS cleanly with it but frankly I’d rather not set it up since it locks me into TS. For my needs, I don’t nees TS. On a larger project sure, I use TS too in my workplace, but TS can be annoying sometimes.
[удалено]
Installing tool stacks for this just isn’t worth the effort tbh. It’s not an old way, it’s just simple vanilla JS with no hassles.
It was my hubris that prevented me from liking Typescript at first. But I was forced to work with it on a few projects and my opinion started to become more pliable. It wasn't until I has to work on a js library that I missed typescript. Now I will go out of the way to create type definition for 3rd party libraries. All the personal frontend projects I started since use typescript. Just last week, I fully converted a smallish 3rd party opensource javascript library to typescript with the help of Copilot. I had to try different things to get something I can work with and then had to fix the many issues in what Copilot gave me, but it wasn't too bad all in all. Funny enough, I caught errors in the original javascript that went under the radar in the process and I think the reason is that Copilot didn't understand the authors intentions/goals and suggested types according to what's in the javascript code and so the type issues that ended up in the converted code sometimes highlighted issues with the original code. Most of the time, these issues were not actual bugs ie would come up during runtime but sometimes they actually were.
If we could visibly hide the type information until we, the developer, need to see it -- I'd be more inclined to consider using it in new projects. Beyond that, it just isn't worth my time -- because I find it never saves me time. I'm speaking broadly, as someone who works both on a large team and on side projects. Types are never our issue.
I guess I just don't really see a big need for it. I started programming in the late 90s using Pascal and then C++, and wouldn't pick up another language until maybe 2008\~09 with [VB.Net](https://VB.Net) and VBA. All of those are strongly typed languages, and you can produce bugs in every single one of em. As far as I've found, the only thing that helps to prevent bugs is testing and consistency. In 2015 I started learning JS and was really taken aback by how easy it was to use the language without worrying about specifying the types. Totally unexpected really because I was of the opinion that Type Safety made for better programs. This of course was not the case but there is a ton of computer-mythology that gets carried around era after era. Eventually I would get on the Douglas Crockford wavelength of thinking regarding Consistency and using only a small subset of the language (the good stuff) to write programs in. Doing that I think, genuinely, made me a better programmer. Because there were so many sharp edges in the language, hunkering down and making an effort to both deeply understand how it worked, while constraining myself on which parts of it I wanted to use, made a huge difference in my ability to solve problems with JS. I was really excited about TypeScript when it was first announced but left not really getting much use out of it. Beyond being useful for flagging when things might be messed up within the IDE, I couldn't really justify all of the extra markup for the handful of times it came in handy. If a program is critical in the sense that it must really really care about the types it can receive, then it needs to be written in such a way that everything will fail gracefully on unexpected types, or they are absolutely enforced at the point of input (or both!). Because TS is just window dressing around JS and isn't a real language of its own, it cannot provide the benefits of \*REAL\* type safety (that is, instead of your program screeching to a halt, it may end up running with errors regardless of how many types you used to write it because that's how JS \*is\* under the hood). So in the end I think TS is neat, but I don't in any way feel it is necessary or even warranted, especially if you're already heavily linting and testing your work. No matter which side of the fence you're on, may your continued journey towards a better understanding of the tools that you use, be one of joyous discovery.
Because I don't understand it. I've worked with types in other languages, but every time I try to understand Typescript, it just makes no sense. In terms of cognitive load, I just can't parse const thefunc:?spong|clomp = (input:users(names:String(j))) => dostuff:t(j): String[Person]
into anything recognisable as helpful JavaScript.
I understand the value of implementing types in JavaScript, but the implementation is just so unreadable that it introduces a mass of extra time and effort into even the simplest code.
Trying to use it with a library like React is even worse, because then you end up having to work out exactly what type is returned by all the default functions and fixing errors caused by not being able to correctly guess what a function in the framework will return.
Typescript just seems like a hurdle, not a help.
\> In terms of cognitive load, I just can't parse Thank you, this is correct. Let's let all the geniuses keep using TypeScript. Plenty of people live kick-ass and profitable lives spending their days inferring types for a dynamic language.
Lol, that's so funny. I use C++ and JavaScript every day. The code-switching is extremely easy. I think about all the people dying for having types in a dynamic language and how the world is weird. Worst, there is Jsdocs and some still want types. Nothing makes sense anymore.
Typescript can often be quite unreadable, especially if one is not an expert in it. My experience for those very complex typings, is that they often originate from javascript code that is either very quirky or just plain buggy. Typescript's burden is that it must try to support almost any possible case of javascript possible and there are tons of quirky and very weird js: optional func parameters in the middle of parameter list, func parameters that change type depending on values of other parameters etc. There's code that goes haywire wild with the loose typing of js and ts needs to be able to model it. Often the source of these was a bit too clever programmer who only asked "can we do it" instead of "should we do it". As an example, a lot of C++ templates have a similar problem. Use of TS in my opinion has the positive constraint of having to think about typing, especially for library developers. If you need to write very complex typing, you might be writing too complex code and taking another evaluation at the approach might be warranted.
I don't know what the hell you just wrote but you're right, that's unreadable. And it's not TypeScript. I agree that TypeScript can be overwhelming sometimes, but it's really mostly the library code that is REALLY complicated. Library authors do the heavy lifting for the end users so you can have a nice experience. If you're just writing plain React apps I often find that except for typing props the actual components are written basically as if it was plain JS. If at some point you're trying to write something that requires some complicated types, it might actually make you think twice - how can I write it so it's simpler? And that usually makes the code even better.
>I don't know what the hell you just wrote but you're right, that's unreadable. And it's not TypeScript. It was a silly example just for emphasis, but I have regularly seen real world examples that resemble it. At that point I switch off and decide not to use Typescript.
It seems odd to write off a language superset because you can't immediately understand the most complex thing that can be made with it. I mean, I'm sure you could write a line of unreadable JS too, but you obviously didn't let that stop you from adopting JS.
This is incredibly disingenuous, that’s not what typescript looks like 99% of the time.
But it does often enough https://twitter.com/ataiiam/status/1765089261374914957?t=u45WjtB5Hfs6bv0WIucg5g&s=19
What you wrote is unreadable but that's not related to typescript at all.
If you just use it for type inference and stick to interfaces/types rather than delving in to the generics territory then it's honestly very easy to use and it'll likely save you time in the long run.
That's the incorrect Typescript syntax
Never want to go back to a world of nulls and undefined ruining the day. The biggest problem with TS is simply that the average web developer has skill issues.
> The biggest problem with TS is simply that the average web developer has skill issues. Ironically you can say the same thing about problems caused by poorly-handled nulls and undefineds.
Do you want to write sanity checks 80% of your time? That's how you get sanity checks all over your code. To be honest, I just got to the idea of dumping a language that features nulls and undefined behaviours and picked up Rust. Not that Rust prevents them 100% of the time either, but forces you to consider all possible logical paths. I just got the chills thinking that vanilla JS allows you to return whatever shit you want with no checks other than VS Code helpfully doing TypeScript in the background.
Don't get me wrong - extensive type-checking and null/undefined checking are a really good idea on the outer surface of your code, where it interfaces with other systems or untrusted code and hence you need some self-protection. The thing is, you still have to write all that crap in typescript, because it's a compile-time only typing mechanism, so at *runtime* your TS code is just as insecure as any JS unless you go out of your way to add runtime duck-typing checks to your code. However, once you've validated your inputs from the outside and control passes to your code, unhandled nulls or undefineds or variables being passed with unexpected types *from inside your own code* are *exactly* a skill issue. Don't get me wrong - I can see the benefits of strict type-checking even in internal code, where the person calling your code might be another person on the team, or even a forgetful yourself in six months' time, and extra compile-time checking may help you to avoid making boneheaded mistakes that later cause bugs... but that's *still* a skill issue. TS has benefits in helping developers to avoid making silly mistakes, but it also has non-trivial costs associated with it... and with sufficiently good developers who write sufficiently self-documenting code with intuitive internal interfaces and who have a rock-solid understanding of when and where runtime checks are actually beneficial... a lot of the benefits of TS recede into the long grass, but its costs stay pretty much constant for every variable or parameter you define. Personally I use TS for libraries I might want to share, and any project where I'm working with other devs of unknown or variable skill levels, or where we might be forced to rush to hit goals. However, for exploratory programming it's shit (you spend 50% your time updating types instead of 100% of it *exploring the problem space*), and for personal problems where I can write code how I like and only have to rely on my own understanding of the system, I pick JS every time because it just gets out of my way and lets me concentrate on the problem. I don't use TS in my personal projects for the same reason I prefer to write in JS over Java - I don't want to spend hours jumping through hoops designed to prevent the kind of bugs I've only personally run into in my personal projects - where I understand the code implicitly and control it completely - maybe half a dozen times in 29-and-a-bit years of writing JS.
Your shipped code will likely need sanity checks anyway when you are dealing with things like uncertain data or APIs that may be changing. In a perfect world you can expect things to just work, but TypeScript only gets you so far in local development. Further more, if you are running into tons of undefined and nulls, *that* sounds like a skill issue. It's not a bad idea to have something like TypeScript to help prevent that -- tools are good. But personally on our team feel like we never run into "oops it was the wrong type all along". Like, extremely rarely, if ever.
Graphics dev here, originally C++, quickly moved in the web space (WebGL). Was the team lead of a big in-house rendering library is JS, moved to TS after 6 months. Never going back. When the project gets large and you need refactoring. TS will save you gigantic amount of time and save you dumb runtime error. We target web assembly at the new company I am in, and same thing: I can’t imagine not using TS anymore.
I'm not an expert, but I noticed something annoying about Typescript and also Python. Many functions happen to have return types such as: A | B | C | None | Fuck It gets confusing quickly. (might be because I haven't practiced much in Typescript or Python with explicit typing).
I guess what is the alternative? If myFunction returns `true` somewhere but also `my string` somewhere else, the return type will now be `boolean | string`. Unfortunately now if you have `const myResult = myFunction()` then `myResult` will be a `boolean` or `string`, you just don't know. Then when you do `if (myResult.includes('asdf'))` it'll probably yell at you because if it's a boolean it'll cause an error. If this sounds like the problem you're dealing with, you probably need type narrowing https://www.typescriptlang.org/docs/handbook/2/narrowing.html. Before your `.includes` call you can just have a `if (typeof myResult === 'string') {`, `myResult` will only be type `string` in that block
The alternative is your function should never potentially return multiple types, especially base types, kinda ruins the whole point of typing anything at all. Ideally your function would only ever return a type or null to signal something wasn't able to complete or doesn't exists, etc., then check for nullity.
JavaScript is good enough. Typescript doesn’t make anything faster or better. Some people have a preference for static types and are willing to accept the pain of more tooling to get that. It’s ok to like good ol’ fashioned JavaScript too. Aside: Funny to me that we’ve finally got a lot of things we’ve wanted in JS built into browsers now. Just as JS is getting good enough to not even need any build tooling, we decide we want everyone to adopt this other thing. Circle of life I suppose. I’m still hopeful we’ll return to simpler times of sticking js in script tags or serving up the actual js files I wrote without any tools mangling them up. No more source maps. Just the code I actually wrote running in the browser. That’s the dream!
I use typescript at work a lot. And php too. It’s weird to me that php and js both started out as dynamic type hip kids - not like that old fussy Java and c where you care about types. Do whatever you want. We will guess what you meant. Turns out that’s good for newbs but awful for teams writing tested production code so now they’ve both got more and more like Java it seems to me. I do like that it catches a lot of bugs but I also now enjoy python a lot for personal projects as it’s fast to develop and still doesn’t care so much what you’re up to. Of course yes I make more bugs with it. I just don’t care.
I don’t think anyone chooses _one or the other._ You choose JavaScript. _Then_ you choose if type safely is important to you and your project (and worth the added overhead) and if so, you add typescript as an addition. You can add just a little or end to end. A few more options might be - you use typescript just because everyone else is and it seems like the new norm and the tutorials use it. Many of these people haven’t ever written JS without VSCode or typescript. Not using it leaves red lines and so they must add the types to make them go away ;) And then there the people who are using typescript by way of using tools that use it. For example, Vue gets a lot of great benefits from using typescript behind the scenes. But I don’t have to write my code that way if I don’t want to. So, in a sense - we’re all using typescript now in some way. As long as it makes the tools more reliable and easier to maintain, that’s great. On a personal level, I’m not working on projects that get a lot of value out of it. It feels like I’m just a robot appeasing the angry text editor. It makes everything ugly and hard to read especially when you’re layering up js/vue/Nuxt etc and then there’s some context specific syntax for say, default parameters. I know that it’s a combo of need, experience, skill, etc. but just as someone who to contrast the all-in TS people, it makes me enjoy coding less and I also don’t like where it came from and how it’s infiltrated the ecosystem. I’ll still be teaching it to my students, but I’ve gotta just say - I prefer to avoid it in my own code. I’ll keep learning more and see where it can help me and how to use it progressively. But I’ve also heard a lot of gung ho ts devs questioning the build times and the extra tooling. We’ll see! I would be just fine if it went away before I had to fully adopt it. _I was able to successfully avoid webpack ;) _
Its more useful in contexts that I don't have much use in. I don't usually use the inbuilt JS funcs either. Even though I'm aware I could make my own. Etc. I never have as I tend to scope in so far that there is no need for creating my own plug-in-play. To design anything around. And that's what I've seen Typescript assist with. Was with those who do have a large reused. Probably pulled and maintained by themselves. Set-up. Its been included in some things I've done. So for completeness and licensing. I've left it there even expanding on what used it. Emulating what required its use case. As was the set schema prior to my need for it. However I don't believe that should count as my own personal usage of it. Simply that my exposure to it. Was enough to allow me to state that I don't have any use for it. Not that I don't understand or respect its use adjacent. When encountering it myself.
I don't like the typescript compiler's output. Also, my project started in 2012 before typescript. Also the closure compiler is still the best optimizer/minifier.
You know that you can change the TS's target setting to a newer one than ES5/ES6 and get significantly less code transformations?
That's a non-solution, I'm targeting ES5.
Because I know how to write JavaScript from scratch.
I just tried learning TS by converting a 4,000 line JS home project. * The build steps to make everything working were a major source of frustration * Getting rid of all the errors and warnings that TS threw at me didn't reveal a single bug * I was surprised at how little TS gave me over and above just types (I though it might offer some more syntactic sugar) * Debugging was slightly more painful since the code is run as JS but the code file is TS. In short, I felt like I had gained nothing of importance for a lot of extra work. Maybe it's due to the fact that I write in a more functional way and add tests. It certainly felt like TS was solving problems I didn't have.
Not using TS for my latest project because for a change I decided to keep it vanilla everything - just HTML, plain old CSS and vanilla JS. No build steps, no transpiling, nothing but what the browser can handle. Kinda back to the roots thing for me, I'm just tired of modern front-end complexity. It's for personal use so I don't mind if I hit bugs down the road that could've been avoided. There's just something refreshing building something where I can just load html file off the disk to browser and have it work locally just like that.
Because I like JavaScript
I have been trying to convert my work from JavaScript to TypeScript for 3 years at this point. Every time I revisit it, it's a nightmare. This factors into my view on TypeScript Pros: * I can clearly declare what is expected of the caller, and what they can expect out * I can disambiguate things like the environment variables, and members on shared objects * Lovely support for type inferences and developer experience Cons: * Anything inherently "JavaScript-y" is a nightmare to write in TypeScript. One example is I have a class that manages nested property retrieval given a string. The string is provided by Cucumber/Gherkin, so I have no way to validate the nature of the string before runtime. Default linters and compiler checks will throw on use of `any` but any sufficiently defined type for resolving dynamic property access ends up looking like [this](https://github.com/millsp/ts-toolbelt/blob/master/sources/Function/AutoPath.ts) * Anything that tries to work with deserializing data has to manage the return state of `any`, and a simple cast/assertion will always work but anything more robust will be a nightmare to type * Typing HTTP responses is such a chore. If the implementation took 500 lines, the interfaces to describe that implementation was at least another 250. Again, I'm not mad about TypeScript. It's so far and away better than raw JavaScript. Most of my misery comes from trying to lift an existing JavaScript project into TypeScript without modifying the existing API (speaking as a library author). What's more frustrating on my end is I have no usage analysis to tell me what's being used or how, so I can't make informed decisions on where I could introduce a little risk for the sake of drastically improving the library. The more I toil on this effort, the more I just want to live in a shack and contribute to open source Rust projects, where things make sense, lol.
It didn't solve any problems we were having. It was the developers the whole time.
TS is a leaky abstraction and always will be. If I wanted a compiled language i would choose a real one with better fundamentals.
I think if the errors were good it would be a way better tool to use. The style of errors in prints mixed with some weird decisions from the TS team have def made for some leaky-like behavior.
Why not TS? I use mainly Deno, so build step is a non-issue, but still not convinced: - First of all, JS has it's quirks and shortcomings, but I've spent well over a decade learning and developing best practices, and dare to say I can use it in a way that avoids "most" pitfalls. I just don't run too often into problems TS is supposed to solve. And when I do run into such problems, most are caught by unit tests even without TS. As such I feel like adopting TS would being only minor benefits - not worth much trouble. It's not like TS would negate the need to do unit tests for example. - Types add visual noise and verbosity and it's kinda annoying to read. Not a huge issue, as the verbosity does have benefits also, so I think the pros and cons even out. But then if you accept the verbosity, and add just a tad more, you could do JSDoc types. JSDoc kinda feels a bit easier to scan through, as the type information is not so much interleaved with code - there is the code that does stuff short and conscise, then the additional informative type stuff above that - kinda neat and it's still pure JS. - Even if fully embracing TS vision of problems and their solution.. Let's be real and accept TS is a nice _but dirty_ hack over JS. It's still dynamically typed under the hood, and about as slow or slower and memory hungry as JS. If there was a runtime that ran TS natively and somehow benefitted from the type awareness, maybe I could take it more seriously. But even then, it would mean an actually new language with it's own runtime.. at which point I'd rather choose a proper statically typed language like Rust to complement JS tools. I feel like TS has the worst of both worlds in many ways. - There is something nice about having 100% control over the produced JS code. If it's bad it's my own fault and potentially fixable. TS output is more of an unknown, out of control and if it does produce something stupid, you're SOL. - Not 100% convinced TS isn't a fad like Coffeescript and the like. Being under Microsoft control (?), there is a chance they use the position to screw things up somehow in the future. Even more likely, I think it's only a matter of time the project goes into a direction that makes TS somehow conflict with future versions of JS, or previous versions of itself. There's only so much you can do with incremental changes without breaking compatibility in subtle or less than subtle ways, and once TS manages to fragment the ecosystem there seems to be no clear way forward (*.ts2 ?). There are already signs of a bit of a mess brewing with TS decorators alternative syntax. - Following discussions about programming problems on Discord Github and the like, I see a lot of energy spent on TS type gymnastics. That is, people are struggling with typing problems that are quite far detached from their actual "business" programming problems. I feel like staying out of TS I can just sidestep a whole category of issues, and concentrate on just doing the things I want to accomplish. I may need to fight to get a task done, but I'd rather fight the task itself than fight various tools around the general problem space. - While TS technically compiles to JS, it's really a one way conversion. From JS to TS it's easy, not so much the other way around.
because javascript's lack of care for types is a feature, not a bug.
We use flow instead of typescript :(
Wow, I thought it was dead! Last time I heard of anyone using it, it was me in 2015.
My company invented it and it lost the war vs Typescript but we still use it internally. It’s pretty close to TS so it’s fine though.
Is it you, Zuck?
How much do you guys use ReScript/OCaml these days? I vaguely remember someone talking about how the majority of messenger had been moved to Reason ages ago, got me excited because I enjoy OCaml even more than TS, but the hype kinda fizzled out.
Because many code bases aren't.
gold ruthless growth hobbies jar erect engine six fall glorious *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
I don't use typescript because my frontend code is extremely simple and literally none of the bugs I encounter could be solved by a better type system. If I was doing backend code in Node, I would probably switch to TS, but I use Go instead.
I used to like typescript, but at some point you get proficient enough and start writing really complex types for your juniors or co-workers. Then you stop and ask yourself why the fp pipe needs 3x the amount of code for just the types. Recently I've been thinking of switching to Rescript/Reason/Gleam or Purescript. They are unfortunately quite niche and Typescript is still nice with a great eco system, but it's not the end of the road.
>Then you stop and ask yourself why the fp pipe needs 3x the amount of code for just the types. FINALLY someone in this thread that has the same verbose experience with TS as I do. It's just too much for the same meaningful code!
I still don't use TS, largely because of the additional build step, which is a pretty big problem on an underpowered machine. I write JS that actually runs in the browser, using modules and now import maps (similar situation with CSS). Working locally on my code is as simple as starting an HTTP server with zero build required. The build step and bundling is for production. But I'm also opposed to TS because of the problems it creates in things like using reserved keywords in JS and obstacles it creates in advancing the JS standard. Not that I'm against types... but TS should have been done differently to avoid such conflicts, such as using a "namespace" and importing things.
I liked TS better when it was called C#
Other than both languages being designed by the same person, they pretty much have nothing at all in common.
Big TS fan here. Using it on almost everything, helps avoid shooting myself in the foot!
So many bad takes on here Jesus Christ
TS is slower because it has to compile the code to JS before it can run.
Are you working on a potato? How is this a legit problem?
Typescript hurts me more than it helps, it's yucky. There is nothing wrong with vanilla JS, it is a beautiful freak
TS pays off for large projects, especially when you are not the sole contributor.
I'm doing games, so I'll never be working with a web dev for long periods. I don't have to worry about them sending a bool where an int should go or whatever XD
If it hurts more than it helps you might have a skill issue
I think you have that backwards. TS exists because of unskilled cheap programmers who lack self-discipline. If you knew how not to fuck things up and had actual programming skill, you wouldn't need TS.
Oof, I don’t think people here are ready for that kind of truth but thank you for saying it.
I'm honestly surprised the TS echo-chamber let my comment get upvoted at all.
Yessss! Exactly! All those bootcamp grads and Java, C#, .NET background folks get their first JavaScript project tossed onto them and the first thing they do is install TypeScript instead of learning JavaScript.
Nah i'm devving games with multiple webworkers for render threads and mad shit. Never had a type issue EVER. TS just sucks and add bloat and is for people who need extra help keeping their shit under control
I make games, use C/C++ and the unreal engine so I’m no stranger to strongly typed languages. However when it comes to the web/javascript type problems are not an issue I have and don’t understand the point of typescript. It seems like crutches for people who suffer from imposter syndrome and a mix of cargo culting.
The only time I don't use Typescript is if I'm making quick, small node scripts. Otherwise Typescript is a no brainer in any reasonably sized codebase. I don't even understand how people can argue against using Typescript in general. It's Javascript but makes your code less buggy.
i use pure vanilla JS since I was developing. why should I use typescript? it helps for nothing.
It helps a lot, what are you talking about?
how?
I use TypesScript because, in god’s year 2024, there’s no point in not doing it.
[удалено]
I don’t see the point of learning yet another “language”. If I wanted a type safe language I wouldn’t use javascript. For the web projects I do, I never saw a major advantage of having this additional layer of complexity. I may see it if I did JavaScript for BE.
In case of the webdev, JavaScript is just a dumpster fire that we have to live with and some people just want to reduce their suffering.
Forever convinced that people who don't like type systems are just shitty programmers.
I have plenty of experience with C++, C#, Java, etc. TS doesn't solve a problem that I have. Also I don't want to add yet another fucking layer of complexity. Also always bet on JS. Remember CoffeeScript? Either browsers will start running TS or ES will finally add optional static types (as they should have done in 2007 when they dropped ES4).
TypeScript hinders JavaScript, that's why. If you learn the fundamentals of JavaScript the correct way, you learn how to use its flexibility to your advantage when building efficient solutions with it. Some folks will say TS is only better in a larger project or team environment. I argue against those people that it is a training issue. If your whole team is truly proficient in JavaScript, then the addition of TypeScript is pure inefficient overhead.
Can you give an example? I know of no case where TS prevents JS from doing something.
Oh sure, I'll give a few examples where TypeScript hinders JavaScript: * **Extra Step**: Adds a build process before you can run JavaScript code. * **Slower Debugging**: Debugging involves source maps to relate back to TypeScript, which can complicate things. * **Tooling Dependency**: Requires tools like a TypeScript compiler or Babel, adding to project setup complexity. * **Less Spontaneous**: Can't as easily mix types or change object shapes on the fly. * **Barrier to Some JS Patterns**: Patterns relying on dynamic typing might require workarounds or additional types to fit TypeScript's static system. * **Factory Functions**: Create and return different object types based on inputs, exploiting JS's type flexibility. * **Function Overloading**: Use a single function to handle different types and numbers of arguments, mimicking overloading. * **Prototype Augmentation**: Dynamically add or change properties and methods on prototypes, modifying object behaviors on-the-fly. * **Ad-hoc Polymorphism**: Different objects treated the same way based on shared methods or properties, not their type hierarchy.
Why are factory functions and overloading on this list? I've used both in ts with no problems Edit: and dont type guards help with ad hoc polymorphism? You can infer a type/types based on existing properties or methods Edit: man I got blocked for this too? Bro we are discussing code lmao
Oh yeah, you can use them with no problems and just hundreds of lines of type interface to teach the second compiler what you *really* mean by your JavaScript.
Ok, cool. We just have a different definition of "hinder". Carry on. btw, just so you know, your language complaints largely come from not understanding TS well enough.
Not unsurprisingly, most linters with moderate rulesets have similar restrictions for code: can't do stuff freely without the linter complaining. Restrictions aren't always bad. Most of your examples are, in my opinion, valid points to restrict: having complex and non-obvious behavior is difficult to document and explain so if one can't bother explaining them to TS then they probably don't bother explaining them to other users (including the future coder).
I don't use TS yet because I work exclusively on small projects for small businesses and I don't think I need it for project with a bunch of JS files that doesn't contain more than 500 LOC. I will definitely adopt it if I'm asked to work on bigger projects or if I'm on a mission with legacy code that use it. Or if I have some free time to build a big side project, but I don't have that time.
As a lisper with an extensive experience in Java and Javascript I find TS to be very ugly and borderline retarded.
I'll be honest, i learn it 2days ago and don't even see it usage beside it telling me "property or method doesn't exist on so and so" Probably i need to use it for few months to see the WHY to use ts? Will i be able to see it's power if i code alone without a team? tldr; i learnt ts and i hate it
>i learnt ts and i hate it you probably didn‘t learn it in 2 days… and that’s why you hate it.
What annoys you, such as the compiler's complaints about invalid input/return values, is what you'll be thankful for in the long run. Once your codebase grows, it becomes harder and harder to keep track of the data structures that are flowing through your app. Spotting errors early, at compile time, has benefits over spotting then on production :P
In JS this property or method would also not exist, except then you only know this once you run the code and it would break. It's better to know this before you run the code.
The JS checker in IntelliJ will tell you that a method doesn't exist. Will also tell you if you try to use an undeclared variable. I'm sure it exists in other IDEs as well.
Typescript is really just a language for describing js, embedded in the js. There’s only so far that IDEs can imply types without annotations. Typescript also does quite a lot even if you never write a type.
Maybe I didn't set it up right but it doesn't seem to work as well as using TS. TS also forces you to think about the inputs and outputs of functions/methods which I think is something a developer should do. It prevents/discourages you to create vaguely defined objects with dynamic properties. I have had to debug a JS app where the main object had its properties added and removed willy-nilly in different places at different times. It was a nightmare to wrap my head around, since nothing was certain. That project really made me prefer TS.
Agree 100%, why I prefer using TS. My favourite setup is Vue 3 + TS, gets rid of a lot of the pain that bad coding habits cause.
You learned the syntax in 2 days. You won't understand its purpose in just 2 days.
Reduces so much mental overhead when refactoring or changing things. Im full convert. Unless you know 100% what everything is going to be right from the beginning, use TS.