I work on big projects, maybe not that complicated, but they bring hundreds of millions of dollars in sales every month. How often do I run into type safety problems? Very rarely. We have maybe one serious bug a year related to type safety? So for type safety reasons I don't think adding TS is necessary. It's just how you write your code and if you can trust the data you receive from various APIs. We write our own API services to integrate with 3rd party tools, so I know 100% what will I get from our API. It's gonna be either object or null, string or empty string, array of items or an empty array. What else is there? Anywhere in code review if we see weak types or type pollution it gets corrected right away. If something slips past reviewer and gets into the code base, it's like 99% probability it's gonna get caught by static code scanner in build pipeline and the merge will be rejected. Hence like one type bug a year. Usually very minor one, because all critical systems are constantly monitored, tested with automated tests, integration tests and manual tests. TS's type safety features are only type safety features like any other. Safety features won't work unless developers are aware what they should and shouldn't do. Even the state of the art alarm system in your house won't work if just keep leaving the back door open and ignore all the alerts.
TypeScript is like driving with a seatbelt. When it was first introduced, people used to the old way of things thought it was uncomfortable, but it's still extremely useful and most people can't imagine doing something as dangerous as not using it
I use TypeScript with extremely strict eslint rules enabled, and it's still not enough. Dumb bugs still make it into prod that would have been caught at compile time had I used Rust (which I now exclusively use for my backend). Yes TypeScript is necessary. Reading an untyped legacy codebase for the first time made that painfully clear to me.
Typescript is not enough, but is a HUGE jump from finding "Not found property x of undefined". I worked in big projects in Javascript. It was easy and fast, we hit production in 3 months and sales made stakeholders happy. Until we had to refactor for new features, and things started to break almost every day on almost every production release. I have never again coded in Javascript without TS in strict
@@erickmoya1401 Exactly. I think that people who argue that TS is not needed write only small personal projects that are never refactored. TS is preventing huge amount of small stupid mistakes
I converted my companies backend and front-end to Typescript a while back, and now I can't program anything without Typescript and I forced my team to learn it. It has helped with a lot of things in a lot of areas.
IMO, not worth it. Modern JS, testing, and a library like superstruct used correctly is far superior. Typescript adds a ton of boilerplate that is not necessary to make a good app. It basically removes all the flexibility JS has and in return you get something like Java or C#. The one thing that is nice is being able to specify types online instead of using jsdoc (but I hardly think this justifies all the rest of TS) Disclaimer: I've been programming JS for over 15 years, so might be a little biased - I've done a decent bit of debugging and only maybe 10 bugs I've dealt with in that time were type related.
I agree that for projects with maybe a handful of engineers working really close together, JS + good unit tests is fine. In a larger project with multiple teams though, TypeScript brings so much to the table - and maintaining TS is so, so much easier! JS doesn't really have much coercion from stopping engineers from applying a shit ton of hacky "quick fixes". Of course there is a time for hacky code when there is a need to get something done fast. Especially if it's in a small team setting where you can just ping everyone who has context of the system about the change being made. But, when entire components of a system are managed by one team, not having to cross reference every single place an object is used to know what the heck is being done to it is a huge win overall in development efficiency. All in all, both have their places, but I'd call it a stretch to place having to learn a patched-up version of JS using a library to do something TS has been built with from the ground up with that exact purpose in mind, "far superior". I'd firstly reach to TS before JS on a project I know will be handed off to another team or individual.
@@simponic TS is easy to abuse. Record can remove just about all of the type safety in TS, and it works even in the strictest setting. TS is also just a library, it isn't an actual language. Everything is still JS underneath, and if you are building something that you can't build in modern JS, then it probably shouldn't be built in TS either. But if you like typing out interfaces just to use generic objects one time, then more power to you.
As a beginner, I like Typescript since it makes me think more about the architecture and function of the code. A big mistake as a learner is to jump to quickly into coding without enough planning and design. And too often, I would not think enough about my functions, and I would code myself into a corner. So, it’s to not to bad for me to have to slow down and lay the types before actually coding my functionality.
This is exactly what happened to me. As a beginner, I tend to create personal projects without planning, and frequently I forget to plan before coding, but TypeScript taught me to be strict with my syntax. It saved me a lot of time fixing errors.
I've built apps with hundreds of thousands of line of code and I refuse to use typescript. I'm not saying it's bad, if it works for u then use it. But i would rather not waste my time fighting with the compiler to do something I know works while it's yelling at me that I'm doing something wrong. If ur regularly testing the code then it really just becomes redundant to have the extras to add types to js for safety. I feel like if u need a dynamic language to be written like c# or java, in that case then just use c# or java and stop forcing a round peg in a square hole.
Typescript makes it easier to mirror c#, like you said. It makes more sense to me as a mid level developer to compliment JavaScript and angular makes it more seamless to work with.
I'm a junior and always preferred strongly typed languages, most of my peers who do front-end don't like typescript but I would always prefer compile time to runtime errors, maybe they don't like angular and link ts to it since most non angular teams in my country don't use ts
The fact that a programmer with a bit of experience doesn't like TS blows my mind. It should be a red flag regarding the guy's skills. For a beginner I can understand, because it means a whole lot more stuff to master. But for an experienced programmer, I cannot understand.
@@johnsmith-ro2tw I’ve done plenty of projects over the years with and without TS, I can attest that it will catch potential errors but my personal preference and why I always loved JS over Java/C# or any typed language is because of its untyped nature it feels more free and anarchistic
I struggled a lot with JavaScript in the past just because I didn’t understand what function or property I was calling or needed to call in order to achieve the functionality I needed. With typescript this all changed, it basically filters and tells you exactly what you need to call in order to get that functionality working, so besides the type safety, my main reason for using typescript is to have a more cohesive experience when it comes to programming
It would be nice if you could go over how modern web development is less web development, and more application development for the web. We all start learning how to build websites and then somewhere along the line we’re expected to turn into software engineers instead of website developers. I truly believe that there should be a delineating line between web development and web application development. Otherwise, it becomes too complex and confusing for beginners, or for people who just want to build websites.
I can, while I do agree that there is a difference, it's just endless learning for all involved. Basically this video. ruclips.net/video/s48Yw4z-wDo/видео.html
Wow, the perfect video at the perfect time. I just started learning Typscript today. My first thoughts were, "Really? I'm going to forget that 'Frank' is a string?" I've been using JS for React for a while now and friends have said, "Oh man, you have to learn TS. You have to!" Perhaps on huge projects with a lot of devs working in the code I can see its value, but for smaller projects that I work on I just don't see any value in the added code. I've just not ran into the kinds of problems people are having using JS in which TS catches.
I was very sceptical at first. But I don't think I can go back to regular js for anything other than really simple stuff. Purely from the DX it is so nice to have first class IDE support for interfaces rather than having to dig into the implementations to figure out what something should be doing. Inference is pretty powerful too. Strict null checks are pretty nice too.
If I'm starting a backend project that needs to be statically typed, I would rather use C# or Java instead of Typescript. But converting a nodejs existing project to Typescript is definitely an improvement but it will bring a lot of headaches with it. The beauty of Javascript is that it is dynamically typed and very flexible to code with.
imaging eating or shitting... constantly validating if your every single step type is properly defined, it removes from you a common sense and literally intuition, it makes you conforming dumb....
For frontend apps, typescript inarguably brings some advantages : - better integration between the different components and layers of the app - code misconception prevention - self documentation, - autocompletion etc... It is a very powerful tool, that you should consider using, for frontend apps instead of pure js. On the other hand, for backend projets, with node js, and any other type of project where security issues matter, it is almost necessary to use a somehow strictly typed language such as typescript... Because, Without strict typing, you may inadvertantly write insecure code... Especially code that allows malicious data injection... Typescript becomes then almost a necessity.
As a freelance front end dev, I hated that I had to learn typescript, but I think once you understand everything about it, it's less of a headache. I'd still prefer to use JS because personally my code is never too convoluted and usually makes sense and is pretty hard to mess something up because of type errors. But alas, most teams I've come across use typescript :(.
I might sound like a boomer…but maybe someone can help me change my mindset. I primarily use JavaScript for backend (NodeJS) but I think this all stems from me using TypeScript when it was new…but I felt like I was struggling with the compiler always, getting errors I didn’t know how to fix, and always tempted to use “any” just to get the error to go away. I also felt like I was writing double the amount of code. My simple method that takes two objects needs interfaces now? Now my code base is cluttered with these and my large code base is even bigger now and harder to find stuff. As for debugging, idk the VSCode debugger works pretty darn well with JavaScript. Granted this is because of the modules I use support TypeScript lol And for the argument of “less bugs”, idk really? You’re still gonna get bugs and a good linter can find these on your JS project easily. Idk like i said, I might sound resistant to what’s new/popular, but eh, I don’t see a need for it. But yes it’s important still to read it and learn it, but would I use it? I don’t think so…maybe someone can help me change my mindset.
Just picked up TS a few days ago. I also came from JS and finding TS hard to learn. I’m looking for the next project to practice TS on. FYI JQuery is still widely used on websites in 2022, look at all the Wordpress sites out there.
Yes, it is, for creating a correct app and for easier implementation, it's amazing. That's why, if you were to attend to JS Conf in Budapest this year, you would have find out that they already started the project for implementing the TS in JS, so that they will be combined under the classic JS, but working like TS. This process might take 10-15-20 years, but you assist on the project launch so start learning TS :)
If a project is complex you definitely need typescript. Otherwise you don’t. Unless you use Angular then you have to kinda. It’s shitty to use in the beginning. Which is why I would suggest learning JavaScript first and then typescript. Never use typescript when still in a prototype phase though.
Summary: Chris talks about whether or not learning Typescript is worth it. He admits that when he first started learning it, he didn't think it was necessary. However, he has since changed his mind and now believes that it is a valuable tool, especially for larger projects. He recommends that beginners learn Typescript, as it will make debugging and other aspects of development much easier.
It you know JS you can write TS. I dislike hearing people say they're learning another language when they're not because it's not another language -- it's only extra syntax basically added to JS.
TypeScript gives you a safeguard against regressions caused by programmer error for when your program gets very large. As a Ruby developer, one of the biggest problems I run into is making a small change somewhere and that affects the variables being passed into a method somewhere else in the program. Good test coverage helps catch that in Ruby, but it would be nice if there was a way to automatically preempt those types (no pun intended) of errors. TypeScript makes complex JS programs much more manageable.
A type checker is always necessary for any serious software. Be that TypeScript or any other compiler. The compiler alone is also not enough. The programmer has to craft the program in a way that enforces correctness at compile time using design patterns and software principles.
Indeed, the making of websites was a fun until all the jobless less talented C/Java programmers started looking for a new job... they came here and fucked up everything with theirs OOP thinking, types, interfaces, components and impossible level of complexity to do the same simple thing...
I just started to use TypeScrypt after many years hoping it was going to be another way to have strongly typed JS. Although, It took me a little bit to figure it out how to implement it with Express and Sequelize, it is worth. I am thinking that it will really pay off when developing the front-end using the same models.
I'm self-taught and although I have a law position at work, I do some programming. I came from python and worked on my first project recently using refine.dev. after doing a 8hr course on typescript I had a blast using it. At first I didnt like it but it started grow on me. I made debugging SO MUCH easier and richer. It kind feels it's like flying by wire, where the computer won't let you make stupid mistakes. Some stuff still needs to be addressed though, IMHO, such as mouse events.
I work in R&D. Mostly automation and creating POC’s. Our code bases are relatively small, so I prefer JS. Though I have been using typescript with Sveltekit projects. It’s alright… it just feels extra.
The thing that bites me is when the server sends back data with the wrong shape (like sending back "true" instead of true). Typescript doesn't help you in this case. You need to add a schema/validator to your frontend code but this is time consuming. I always start my projects with TS, and write all my files as `.ts` or `.tsx` but I pretty much opt out of all the enforcement of TS. I will add an ***interface*** when I want to document a more complex object (like a user's document/record, a context object, or options object). I try to avoid `any` but have a rule that "if I can't figure it out in 2 minutes, put any" I use `as` a lot to help typescript understand the data being passed in
Use tRPC or generate types from your API, provided that it follows standard practices (REST OpenAPI/Swagger or GraphQL). tRPC is better because it will _always_ be in sync since the Router type is directly imported from the server-side. Generation still require a manual process, even if you generate when pulling changes (i.e. a git hook). Rely more on inference rather than manually typing your API as it's error-prone. For the most part there's no need to type return values or interfaces other than for input arguments. Make TypeScript help you, not you helping TypeScript. Use type annotations instead of type assertions. Type assertions overrides the compatibility rules and you are more likely to introduce bugs since you're effectively telling the compiler "I know what I'm doing", similar to using `any`. Although it can catch _some_ type incompatibilities for statically defined types, but it doesn't catch conditional types. Sometimes there's no way around it, if the API you're using isn't TypeScript-oriented, but for the most part you should not rely on type assertions.
The only reason Typescript exists is because JavaScript was the only language available in the browser. Once the Web IDL comes to WASM allowing interoperability with browser APIs, JavaScript and Typescript will slowly die off. We’re already seeing everybody on Microsoft stacks migrating to Blazor.
Yeah its really essential for large code bases. Before I switched to ts soooo much time was wasted on xxx is undefined or is null error s sooo much time.. Battling the compiler is great because you know it works and probably will keep working. Also how it forces you to make a parser function with unknown is a good thing.
I find Typescript to be very redundant and kinda a time waste if you're already doing testing, but it is something I'm learning on the side because of the growing demand from teams. I'd never use it on a personal project though. What is your thought on the Typescript team proposing "Types as Comments" to native JavaScript to lessen the need of Typescript?
As a learning beginner, I suppose Typescript gets interesting when the code base variables and inputs are becoming massive. I used it for tic-tac-toe, then the todo app, when I created it using imperative programming and didn'T touch react. I think the latter reached over 1500 lines simply because I wanted to scale it up so much. Now learning react with js by building a cv-generator to understand the nature of things and then add TS to see how it behaves within react
Nope, the beauty of JavaScript is that it's quick. I've programmed in several low level languages, from Haskell to C, and using a language that doesn't bug you every second about it's types, is refreshing. At the end of the day, a type issue is really the result of on not knowing what building blocks go where. Paradigms like simple functional programming vastly alleviate this issue by eliminating side effects that would make it confusing to know what the output may be. I mean if you're relying on an entire type system to prevent you from fucking up your code, then the code is the not the problem 🤷🏻♂️
I have worked with JS for 10 years now and I don't think TS is necessary. It's been just a couple of months I started using it so maybe I will change my mind, but I have worked in small and large, typed and not typed codebases and the type checking itself is far from being the most important thing on keeping scalability and readability. Also I usually see more value and feel more confident refactoring code that has high unit test coverage. I think in the end it's a good thing to have TS and personally I would opt for TS for any long term project, but if you are having a hard time understanding the codebase, data flow, state management and you feel you can't refactor or fix anything without breaking something else, the reason is most likely not a lack of type checking IMO
I mostly do game development and learning webdev. I just dont like dynamic types, its just a recipe for errors imo. Its the Reason I'm learning Angular.
typescript really helps code document itself. Sure you need a doc sooner or later, but no more writing jsdocs, because its pretty easy to see what a function does when you have in/output-types
Ever sense I found a type script command that auto generates a TS file for exported JS functions, I no longer see a need to actually "write" typescript.
adjusting to typescript is not as difficult than jumping to a framework..but things like nestjs is easy to adjust with and trpc makes writing api a thing of the past.. strongly typed part where most of the advantage is though you can have things such as class-validator
If you work in large projects that requires people to understand your code, it is necessary. As a Java developer (and I think C# developer think the same) Typescript feels natural.
I thought you were going to answer this question, not literally ask it. I haven't used TypeScript, so I couldn't say much. What I do know is what problem I would want solved that I cannot do in JavaScript. I have a runtime parameter typehinting routine that uses the instanceof operator, making heavy use of the "well-known" Symbol.hasInstance property to create "types." The advantage is that I can get MUCH more complicated types than anything that TypeScript appears capable of doing by abusing the Symbol.hasInstance method, and I can reuse those same types as standalone checks for external inputs. The first disadvantage is that this is a non-zero overhead added to each function call, but in most programs, this is negligible. In any cases where it's not, I can simply remove the hinting function, which is normally applied to the "arguments" for a function with a list of types. The second, which would be something TypeScript would help with, is that until the function is called, I can't tell that it's going to be called incorrectly. So it requires full execution, possibly across all edge and corner cases, to find those types of errors. But even that isn't usually a problem. While I will occasionally get a runtime for a bad parameter in a function call being caught by the typehinting routine, I'm far more likely to be halted for using an undeclared variable. JavaScript can't notify me of these errors at JIT compilation because of the multiple scopes and nonlinear nature of closures. It doesn't know that by the time I call a function that it won't have that variable name somewhere within its scope. For all it knows, I'm going to stuff that property into the global scope. Hoisting and strict mode probably prevent bare insertion of a variable name into any intermediate scopes, but even strict mode accepts that I might change the properties of globalThis by the time the function is called. If TypeScript solves THAT problem, then it's worth the trouble, and I'll work on integrating it into my code. The compiler would have to assume that nothing will be added to globalThis, and it would have to know in which environment I'll be running so it knows what to expect in that local globalThis. So I couldn't have a completely agnostic compiler to find this error, but the code I write largely IS agnostic and designed to work in Node, a standard browser environment, worker threads, WebExtension background and content scripts, Electron, and possibly other environments in the future such as Deno or Bun. If the only benefit I'd get is diagnosing function calls a little sooner than the runtime check could, then I'd have to weigh it against the much more specific checks I can do at runtime via the Symbol.hasInstance method. It would only be useful in low-frequency late-called functions that take a wide range of inputs, such as any string or any number, instead of being able to require valid filenames or integers between 1 and 65535, for example.
I think it's an overkill for most front end stuff but I would probably use a type safe language for most server side code but I would use a proper type safe language instead of some hacked together tool (Typescript).
Worked in new & legacy codebases at startups, Google and beyond that were 1) super strongly typed; 2) wannabe strongly typed; 3) not at all type safe. What I see happen is folks get stuck in 2 and start hating the additional work when they feel they aren't seeing the added benefit. My conclusion: The need for type safety increases proportionally with the complexity of the codebase and the # of devs interacting with it. Personal website? Fuck no I will not be using types. Large infrastructure that will be owned by my predecessor? Of course it needs types to make the code self explanatory.
If they are working API related stuff yes since typescript has good documentation and support for OpenAPI. Anything else it will be it depends and i priotrise on the team size as complexity as well.
It removed a lot of the need for unit testing. At first I hated it, but once I saw it showed me I needed to make changes in other files off one change, it loved it. There are still a few things I don't like about it(for example can't do object.hasOwnProperty(key)). But overall I would rather use typescript. I generally follow a rule... if the same type or interface is defined by more than 1 file, I will put it in a types folder and import it. Otherwise I put the type and interface definitions at the bottom of the JavaScript file so I don't have to scroll through them while working on my code.
I don't think that TypeScript is necessary for big projects, just compiling safety is not really a good thing, I just like TypeScript only for code suggestions and nothing else.
Im a new dev using ts now and Im wondering why tho? Am I jsut working on too simple projects or what? Can you tell me a case when you were like "Thank god this is in typescript!" ?
Yes. The answer is yes! A resounding yes! It is definitely necessary. It is almost a guarantee that you'll make a typo or access something that doesn't exist. What I don't like about Typescript though is that you have to do some type gymnastics before you write anything meaningful but the payoff is well worth it
I wouldn't say its necessary, but its useful although it has issues. The issues aren't really related to Typescript and the langauge but more over to the libraries that attempt to support it, and yeah DefinitelyTyped helps, sometimes it doesn't cut it and you spend an hour adding a module to your defenitions of a project. Another problem I see is that not everyone uses the same backend and frontend environments and that means you spend a lot of time at the beginning making schemas/types... And if your prototyping things, it can be a nightmare! My general rule is use JS to prototype (maybe ill use TSDoc in the future prototypes in JS), then use typescript for bigger and complex applications/codebases.
It's not just type safety. It also streamlines the JavaScript experience. Importing libraries and JSON files is a lot easier. I also like that I can do things like map all the built JavaScript to a sub directory, or even a single file. Finally, I like that the JavaScript it generates is more robust, and remains legible.
I love typescript. I am java developer and variable A is integer and you can assign the string to and will not give error at compile time and direct at runtime (which can be production) is just too bad for me. I became Frontend developer because of TS and Angular because it's easy for Java developer
I'm a senior dev. Been programming for forty years now. The hardest thing I did was give up oop paradigms and embrace true functional programming. I consider TS a huge leap backwards. It cannot do runtime type checking. It's a joke. I really don't want to go back to the BS of interfaces, methods (the worse crime), dependancy injection. Yuck yuck yuck. Am I too much a higher-order function snob? Also I hate Microsoft with a passion. So probably bias here.
Yep, it takes time to of experience to understand stupidity of "modern" times. I literally have nothing to say... maybe this story: "A certain society believed that the reason humans could walk was because of a certain "stick" they had invented. Everyone in this society owned one of these sticks, and babies were presented with them shortly after birth. It was unthinkable and even heretical to question the importance and essential nature of these walking sticks. One day, a rebel decided to demonstrate that humans could walk without the stick. But, given that he himself had never tried walking without the support of the stick, he fell down when he attempted to walk stick-free. Thus, the society concluded once again that it was the stick that allowed humans to walk."
Type safety is great, For example now I like to program in Crystal more than Ruby (both for Crystal's static typing and its speed), I really like the ability to specify what type each variable is, That's crazy to build software projects without it, Maybe for scripting and "calculator languages" (Julia, Python, Octave) it is fine but not for general application development.
typescript is a blis. its nice to read and its so clean and you don't need to compile them to js.. ts can run by using ts-node so its so clean. ngl when I see angular js.. i hate how messy it looks like lol xD then they have ts I kinda love it like I'm in the era where angular 2 comes out long long time ago. .that's where I started to use typescript because of angular ts.
For me was the learning curve tbh it's a bit steeper there's a lot to learn on compilation options and stuff that's happening in the code, I followed their docs and lemme tell ya I had a good time with it loved how Microsoft is taking initiative on teaching and stuff but idk seems like didn't made my mind up yet on learning typescript or I'm taking a wrong approach
Honestly? It's a lot of boiler plate for simple typing, and something that had already been solved without TS before. But because all the "cool" programmers say it's the best thing since sliced bread, I guess I will too.
I think strict typing becomes increasingly important the more the code base grows. It also helps with readability and intellisense in IDE’s. That’s part of the reason I’ve always preferred strictly typed languages. I like that Angular uses Typescript by default. The only thing I don’t understand about Angular is why Observables are used by default when JavaScript already offers promises. It seems like reinventing the wheel and just adding extra features to the wheel. Or a better analogy would be forcing every manufacturer to put race tires on all of their cars. Most cars don’t need the amount of grip race tires give you. What observables offer seem to be unneeded in 90% of cases.
Is TypeScript necessary? I think the answer to that is "no" because there are plenty of projects out there that just use regular JavaScript. But it does have benefits and drawbacks. It seems easy at first, until you encounter something in the type system that you have no idea why it's behaving a certain way. You find more and more of those instances, and you research them and find out why. And it's usually because you didn't understand the compiler and wrote bad code. So you rewrite it correctly and there you go. But this happens for awhile as you learn more nuance. So it can feel like you're fighting the language and compiler and it might be tempting to just go back to JS. But if you stick with it, you'll learn how to properly take advantage of the compiler, and use type inference to pull off some really clever types to provide elegant APIs. And the result is not only convenient for the developer, you can insure that parts of your code are called in very specific ways, with specific data if you so desire. If you like duck typing in JS, then you should really love TS. Because you can create types to represent any kind of duck that you want. Or a type that can represent one of a set of ducks. Or a duck and a cat. Or whatever. The point is, you are telling the compiler how your code works so that it can stop you from using it incorrectly. When used correctly, an entire category of bugs are simply impossible because the compiler will catch them.
why have type script if you have tests? Personally I think typescript is a pointless safety blanket for programmers who don't know how to handle chaos.
@@darkquaesar2460 Then you're probably using wrong, sorry. As much as I don't like the guy, watch Theo Browne's video "You might be using typescript wrong" - then you'll understand. If you add every type again and again instead of letting TS infer as much as possible it will be annoying. If you let TS help you it will boost your productivity 10x. Few years ago I was telling the same, that TS is annoying and will slow you down, but working on large complex app (not personal side projects) where everything has good types changed my mind.
@@bartoszkrawczyk4976 it creates more text to read, it makes my brain fucked up when I want to build quickly things I still trying to figure it out why compiler does not like my console.log or sees 3 arguments in the function when there are literally 4. And you know what... at the end it is compiled to... javascript - insane!
I've only been programming for about 18 months, but it's obvious to me that TS lets you work faster and safer. I wouldn't take a job with a large vanilla JS codebase.
Love typescript, may even be using it too much as a crutch...I actually gotta dive deeper into javascript and learn that inside out but its hard to go back
I don't look at it as a headache I look at it as a very good tool that provides very useful intellisense and fils a bit The Gap that I'm missing from C sharp
I do find ts to be painful but most of the time I blame framework and library authors more than I blame ts. Most developers blame ts and I know it's not perfect. But framework and library authors should try to understand ts more and even the web so that types can be made in better ways
Typescript is dumb. Why people think it's bad to use the javascript type system directly, or they can't do it and need a preprocessor to do it I don't get. It's not like type errors are they only bug. For any kind of error it's your responsibility to understand what language feature exists rather than having something else do it for you.
I agree that there are still a ton of runtime bugs possible with typescript code. That said, I'm sure it catches a lot. Is it worth it? I'm not sure, sometimes crazy types give me a headache
@@realchrishawkes yeah, I dunno. I think javascript's type system is pretty well defined. Maybe people think types are a bigger deal because of typescript itself.
If you are solo developer making small projects that last two weeks, then sure, you don't need it. For complex production apps you need it, you just don't know it yet.
Typescript is awesome but it's EXTREMELY slow. Of course, not the compiled stuff but the compiler is asinine and it's plugin support is meh.. it's really slow for web development when I have to wait for vue-tsc (plugin for typescript compiler) I don't mind it. I do like types, makes it easier to not click all the "view source" which I did often in JS.. however, I can't get over the slowness of the compiler
I work on big projects, maybe not that complicated, but they bring hundreds of millions of dollars in sales every month.
How often do I run into type safety problems? Very rarely. We have maybe one serious bug a year related to type safety? So for type safety reasons I don't think adding TS is necessary. It's just how you write your code and if you can trust the data you receive from various APIs. We write our own API services to integrate with 3rd party tools, so I know 100% what will I get from our API. It's gonna be either object or null, string or empty string, array of items or an empty array. What else is there? Anywhere in code review if we see weak types or type pollution it gets corrected right away. If something slips past reviewer and gets into the code base, it's like 99% probability it's gonna get caught by static code scanner in build pipeline and the merge will be rejected.
Hence like one type bug a year. Usually very minor one, because all critical systems are constantly monitored, tested with automated tests, integration tests and manual tests.
TS's type safety features are only type safety features like any other. Safety features won't work unless developers are aware what they should and shouldn't do. Even the state of the art alarm system in your house won't work if just keep leaving the back door open and ignore all the alerts.
TypeScript prevents so many bugs, it has nice IDE integration and many other things.
TypeScript is like driving with a seatbelt. When it was first introduced, people used to the old way of things thought it was uncomfortable, but it's still extremely useful and most people can't imagine doing something as dangerous as not using it
I use TypeScript with extremely strict eslint rules enabled, and it's still not enough. Dumb bugs still make it into prod that would have been caught at compile time had I used Rust (which I now exclusively use for my backend). Yes TypeScript is necessary. Reading an untyped legacy codebase for the first time made that painfully clear to me.
See you on r/programmingcirclejerk lmao
Typescript is not enough, but is a HUGE jump from finding "Not found property x of undefined". I worked in big projects in Javascript. It was easy and fast, we hit production in 3 months and sales made stakeholders happy. Until we had to refactor for new features, and things started to break almost every day on almost every production release. I have never again coded in Javascript without TS in strict
@@erickmoya1401 Exactly. I think that people who argue that TS is not needed write only small personal projects that are never refactored. TS is preventing huge amount of small stupid mistakes
I converted my companies backend and front-end to Typescript a while back, and now I can't program anything without Typescript and I forced my team to learn it. It has helped with a lot of things in a lot of areas.
@@erickmoya1401 exactly
IMO, not worth it. Modern JS, testing, and a library like superstruct used correctly is far superior. Typescript adds a ton of boilerplate that is not necessary to make a good app. It basically removes all the flexibility JS has and in return you get something like Java or C#. The one thing that is nice is being able to specify types online instead of using jsdoc (but I hardly think this justifies all the rest of TS) Disclaimer: I've been programming JS for over 15 years, so might be a little biased - I've done a decent bit of debugging and only maybe 10 bugs I've dealt with in that time were type related.
I agree that for projects with maybe a handful of engineers working really close together, JS + good unit tests is fine. In a larger project with multiple teams though, TypeScript brings so much to the table - and maintaining TS is so, so much easier! JS doesn't really have much coercion from stopping engineers from applying a shit ton of hacky "quick fixes". Of course there is a time for hacky code when there is a need to get something done fast. Especially if it's in a small team setting where you can just ping everyone who has context of the system about the change being made.
But, when entire components of a system are managed by one team, not having to cross reference every single place an object is used to know what the heck is being done to it is a huge win overall in development efficiency.
All in all, both have their places, but I'd call it a stretch to place having to learn a patched-up version of JS using a library to do something TS has been built with from the ground up with that exact purpose in mind, "far superior". I'd firstly reach to TS before JS on a project I know will be handed off to another team or individual.
@@simponic TS is easy to abuse. Record can remove just about all of the type safety in TS, and it works even in the strictest setting. TS is also just a library, it isn't an actual language. Everything is still JS underneath, and if you are building something that you can't build in modern JS, then it probably shouldn't be built in TS either. But if you like typing out interfaces just to use generic objects one time, then more power to you.
It’s essential for larger codebases
its absolutely not.....its essential for C# programmers who don't want to learn JS.
As a beginner, I like Typescript since it makes me think more about the architecture and function of the code. A big mistake as a learner is to jump to quickly into coding without enough planning and design. And too often, I would not think enough about my functions, and I would code myself into a corner. So, it’s to not to bad for me to have to slow down and lay the types before actually coding my functionality.
This is exactly what happened to me. As a beginner, I tend to create personal projects without planning, and frequently I forget to plan before coding, but TypeScript taught me to be strict with my syntax. It saved me a lot of time fixing errors.
@@DevRSC do we need to learn full JS before going into TS
I've built apps with hundreds of thousands of line of code and I refuse to use typescript. I'm not saying it's bad, if it works for u then use it. But i would rather not waste my time fighting with the compiler to do something I know works while it's yelling at me that I'm doing something wrong. If ur regularly testing the code then it really just becomes redundant to have the extras to add types to js for safety. I feel like if u need a dynamic language to be written like c# or java, in that case then just use c# or java and stop forcing a round peg in a square hole.
Personally I really just like the self documenting aspect of it and knowing what my subscribers and consumers use and produce
Typescript makes it easier to mirror c#, like you said. It makes more sense to me as a mid level developer to compliment JavaScript and angular makes it more seamless to work with.
I really cant understand how anyone is able to work with dynamic languages. I need my type system 😅
completly necessary, I'm working in a complex app as a newcomer and it is a pain to work on without typing.
Not that it is anywhere near as good as TypeScript, but do you use jsdocs?
@@trappedcat3615 it isn't in the project :(
I'm a junior and always preferred strongly typed languages, most of my peers who do front-end don't like typescript but I would always prefer compile time to runtime errors, maybe they don't like angular and link ts to it since most non angular teams in my country don't use ts
The fact that a programmer with a bit of experience doesn't like TS blows my mind. It should be a red flag regarding the guy's skills. For a beginner I can understand, because it means a whole lot more stuff to master. But for an experienced programmer, I cannot understand.
@@johnsmith-ro2tw I’ve done plenty of projects over the years with and without TS, I can attest that it will catch potential errors but my personal preference and why I always loved JS over Java/C# or any typed language is because of its untyped nature it feels more free and anarchistic
noone likes angular...
I struggled a lot with JavaScript in the past just because I didn’t understand what function or property I was calling or needed to call in order to achieve the functionality I needed. With typescript this all changed, it basically filters and tells you exactly what you need to call in order to get that functionality working, so besides the type safety, my main reason for using typescript is to have a more cohesive experience when it comes to programming
It would be nice if you could go over how modern web development is less web development, and more application development for the web. We all start learning how to build websites and then somewhere along the line we’re expected to turn into software engineers instead of website developers. I truly believe that there should be a delineating line between web development and web application development. Otherwise, it becomes too complex and confusing for beginners, or for people who just want to build websites.
I can, while I do agree that there is a difference, it's just endless learning for all involved. Basically this video. ruclips.net/video/s48Yw4z-wDo/видео.html
Wow, the perfect video at the perfect time. I just started learning Typscript today. My first thoughts were, "Really? I'm going to forget that 'Frank' is a string?" I've been using JS for React for a while now and friends have said, "Oh man, you have to learn TS. You have to!" Perhaps on huge projects with a lot of devs working in the code I can see its value, but for smaller projects that I work on I just don't see any value in the added code. I've just not ran into the kinds of problems people are having using JS in which TS catches.
Strict null checks are awesome. Yes they are more work. Yes they prevent a lot of bugs.
Hell yeah, they force you to actually cover the null cases rather than just the happy path!
I was very sceptical at first. But I don't think I can go back to regular js for anything other than really simple stuff. Purely from the DX it is so nice to have first class IDE support for interfaces rather than having to dig into the implementations to figure out what something should be doing. Inference is pretty powerful too. Strict null checks are pretty nice too.
If I'm starting a backend project that needs to be statically typed, I would rather use C# or Java instead of Typescript. But converting a nodejs existing project to Typescript is definitely an improvement but it will bring a lot of headaches with it. The beauty of Javascript is that it is dynamically typed and very flexible to code with.
The thing I love about typescript is having to click through a variable 7 levels deep to figure out what it references. That's efficiency.
imaging eating or shitting... constantly validating if your every single step type is properly defined, it removes from you a common sense and literally intuition, it makes you conforming dumb....
JavaScript lack of type safety and type clarity made it unsuitable for large applications.
For frontend apps, typescript inarguably brings some advantages :
- better integration between the different components and layers of the app
- code misconception prevention
- self documentation,
- autocompletion etc...
It is a very powerful tool, that you should consider using, for frontend apps instead of pure js.
On the other hand, for backend projets, with node js, and any other type of project where security issues matter, it is almost necessary to use a somehow strictly typed language such as typescript... Because, Without strict typing, you may inadvertantly write insecure code... Especially code that allows malicious data injection... Typescript becomes then almost a necessity.
Sometimes JS Docs is all you need! Even when you are doing just vanilla JS JS Docs can be helpful.
Absolutely 100% recommended for writing any codebase bigger than 1000 lines of code which is pretty much every project you'll work on.
I cannot return to plain Javascript, hehe. I simply can't.
As a freelance front end dev, I hated that I had to learn typescript, but I think once you understand everything about it, it's less of a headache. I'd still prefer to use JS because personally my code is never too convoluted and usually makes sense and is pretty hard to mess something up because of type errors. But alas, most teams I've come across use typescript :(.
I might sound like a boomer…but maybe someone can help me change my mindset.
I primarily use JavaScript for backend (NodeJS) but I think this all stems from me using TypeScript when it was new…but I felt like I was struggling with the compiler always, getting errors I didn’t know how to fix, and always tempted to use “any” just to get the error to go away.
I also felt like I was writing double the amount of code. My simple method that takes two objects needs interfaces now? Now my code base is cluttered with these and my large code base is even bigger now and harder to find stuff.
As for debugging, idk the VSCode debugger works pretty darn well with JavaScript. Granted this is because of the modules I use support TypeScript lol
And for the argument of “less bugs”, idk really? You’re still gonna get bugs and a good linter can find these on your JS project easily.
Idk like i said, I might sound resistant to what’s new/popular, but eh, I don’t see a need for it. But yes it’s important still to read it and learn it, but would I use it? I don’t think so…maybe someone can help me change my mindset.
Just picked up TS a few days ago. I also came from JS and finding TS hard to learn. I’m looking for the next project to practice TS on. FYI JQuery is still widely used on websites in 2022, look at all the Wordpress sites out there.
Yes, it is, for creating a correct app and for easier implementation, it's amazing. That's why, if you were to attend to JS Conf in Budapest this year, you would have find out that they already started the project for implementing the TS in JS, so that they will be combined under the classic JS, but working like TS. This process might take 10-15-20 years, but you assist on the project launch so start learning TS :)
If a project is complex you definitely need typescript. Otherwise you don’t. Unless you use Angular then you have to kinda. It’s shitty to use in the beginning. Which is why I would suggest learning JavaScript first and then typescript. Never use typescript when still in a prototype phase though.
Summary:
Chris talks about whether or not learning Typescript is worth it. He admits that when he first started learning it, he didn't think it was necessary. However, he has since changed his mind and now believes that it is a valuable tool, especially for larger projects. He recommends that beginners learn Typescript, as it will make debugging and other aspects of development much easier.
thanks mate. you are the hero.
It you know JS you can write TS. I dislike hearing people say they're learning another language when they're not because it's not another language -- it's only extra syntax basically added to JS.
TypeScript gives you a safeguard against regressions caused by programmer error for when your program gets very large. As a Ruby developer, one of the biggest problems I run into is making a small change somewhere and that affects the variables being passed into a method somewhere else in the program. Good test coverage helps catch that in Ruby, but it would be nice if there was a way to automatically preempt those types (no pun intended) of errors. TypeScript makes complex JS programs much more manageable.
A type checker is always necessary for any serious software. Be that TypeScript or any other compiler. The compiler alone is also not enough. The programmer has to craft the program in a way that enforces correctness at compile time using design patterns and software principles.
we've been invaded by java devs. fuck my life. I hate it
Indeed, the making of websites was a fun until all the jobless less talented C/Java programmers started looking for a new job... they came here and fucked up everything with theirs OOP thinking, types, interfaces, components and impossible level of complexity to do the same simple thing...
If you use something like trpc you can actually develop faster than with javascript, because of type inference.
I just started to use TypeScrypt after many years hoping it was going to be another way to have strongly typed JS.
Although, It took me a little bit to figure it out how to implement it with Express and Sequelize, it is worth.
I am thinking that it will really pay off when developing the front-end using the same models.
I agree, it’s worth it in the end
I'm self-taught and although I have a law position at work, I do some programming. I came from python and worked on my first project recently using refine.dev. after doing a 8hr course on typescript I had a blast using it. At first I didnt like it but it started grow on me. I made debugging SO MUCH easier and richer. It kind feels it's like flying by wire, where the computer won't let you make stupid mistakes. Some stuff still needs to be addressed though, IMHO, such as mouse events.
Stick to law
I work in R&D. Mostly automation and creating POC’s. Our code bases are relatively small, so I prefer JS.
Though I have been using typescript with Sveltekit projects. It’s alright… it just feels extra.
I always love the throw away intros, "HeyEvryBudiWutAhp" 😂
The thing that bites me is when the server sends back data with the wrong shape (like sending back "true" instead of true). Typescript doesn't help you in this case. You need to add a schema/validator to your frontend code but this is time consuming.
I always start my projects with TS, and write all my files as `.ts` or `.tsx` but I pretty much opt out of all the enforcement of TS. I will add an ***interface*** when I want to document a more complex object (like a user's document/record, a context object, or options object).
I try to avoid `any` but have a rule that "if I can't figure it out in 2 minutes, put any"
I use `as` a lot to help typescript understand the data being passed in
Use tRPC or generate types from your API, provided that it follows standard practices (REST OpenAPI/Swagger or GraphQL). tRPC is better because it will _always_ be in sync since the Router type is directly imported from the server-side. Generation still require a manual process, even if you generate when pulling changes (i.e. a git hook).
Rely more on inference rather than manually typing your API as it's error-prone. For the most part there's no need to type return values or interfaces other than for input arguments. Make TypeScript help you, not you helping TypeScript.
Use type annotations instead of type assertions. Type assertions overrides the compatibility rules and you are more likely to introduce bugs since you're effectively telling the compiler "I know what I'm doing", similar to using `any`. Although it can catch _some_ type incompatibilities for statically defined types, but it doesn't catch conditional types. Sometimes there's no way around it, if the API you're using isn't TypeScript-oriented, but for the most part you should not rely on type assertions.
The only reason Typescript exists is because JavaScript was the only language available in the browser. Once the Web IDL comes to WASM allowing interoperability with browser APIs, JavaScript and Typescript will slowly die off. We’re already seeing everybody on Microsoft stacks migrating to Blazor.
Which was precisely why Microsoft made TS to begin with.
Yeah its really essential for large code bases. Before I switched to ts soooo much time was wasted on xxx is undefined or is null error s sooo much time.. Battling the compiler is great because you know it works and probably will keep working.
Also how it forces you to make a parser function with unknown is a good thing.
I just love it when I'm writing JS (I don't do that very often) and it says something very enlightening like "undefined is undefined"
was refactoring a crud api application and wasted like a day to find out how to type Error handlers
I find Typescript to be very redundant and kinda a time waste if you're already doing testing, but it is something I'm learning on the side because of the growing demand from teams. I'd never use it on a personal project though.
What is your thought on the Typescript team proposing "Types as Comments" to native JavaScript to lessen the need of Typescript?
I like it as language, but I don't like the fact that we need to compile it to JavaScript. All of that battle with the compiler 😁
As a learning beginner, I suppose Typescript gets interesting when the code base variables and inputs are becoming massive.
I used it for tic-tac-toe, then the todo app, when I created it using imperative programming and didn'T touch react.
I think the latter reached over 1500 lines simply because I wanted to scale it up so much.
Now learning react with js by building a cv-generator to understand the nature of things and then add TS to see how it behaves within react
Once I went TypeScript I never wanted to go back. It's absolutely necessary they should make TypeScript by default in browser.
Nope, the beauty of JavaScript is that it's quick. I've programmed in several low level languages, from Haskell to C, and using a language that doesn't bug you every second about it's types, is refreshing. At the end of the day, a type issue is really the result of on not knowing what building blocks go where. Paradigms like simple functional programming vastly alleviate this issue by eliminating side effects that would make it confusing to know what the output may be. I mean if you're relying on an entire type system to prevent you from fucking up your code, then the code is the not the problem 🤷🏻♂️
I have worked with JS for 10 years now and I don't think TS is necessary. It's been just a couple of months I started using it so maybe I will change my mind, but I have worked in small and large, typed and not typed codebases and the type checking itself is far from being the most important thing on keeping scalability and readability. Also I usually see more value and feel more confident refactoring code that has high unit test coverage. I think in the end it's a good thing to have TS and personally I would opt for TS for any long term project, but if you are having a hard time understanding the codebase, data flow, state management and you feel you can't refactor or fix anything without breaking something else, the reason is most likely not a lack of type checking IMO
I mostly do game development and learning webdev. I just dont like dynamic types, its just a recipe for errors imo. Its the Reason I'm learning Angular.
typescript really helps code document itself. Sure you need a doc sooner or later, but no more writing jsdocs, because its pretty easy to see what a function does when you have in/output-types
Ever sense I found a type script command that auto generates a TS file for exported JS functions, I no longer see a need to actually "write" typescript.
It surprises me that so many devs are still thinking TypeScript is optional.
adjusting to typescript is not as difficult than jumping to a framework..but things like nestjs is easy to adjust with and trpc makes writing api a thing of the past.. strongly typed part where most of the advantage is though you can have things such as class-validator
If you work in large projects that requires people to understand your code, it is necessary. As a Java developer (and I think C# developer think the same) Typescript feels natural.
I thought you were going to answer this question, not literally ask it. I haven't used TypeScript, so I couldn't say much.
What I do know is what problem I would want solved that I cannot do in JavaScript. I have a runtime parameter typehinting routine that uses the instanceof operator, making heavy use of the "well-known" Symbol.hasInstance property to create "types." The advantage is that I can get MUCH more complicated types than anything that TypeScript appears capable of doing by abusing the Symbol.hasInstance method, and I can reuse those same types as standalone checks for external inputs. The first disadvantage is that this is a non-zero overhead added to each function call, but in most programs, this is negligible. In any cases where it's not, I can simply remove the hinting function, which is normally applied to the "arguments" for a function with a list of types. The second, which would be something TypeScript would help with, is that until the function is called, I can't tell that it's going to be called incorrectly. So it requires full execution, possibly across all edge and corner cases, to find those types of errors.
But even that isn't usually a problem. While I will occasionally get a runtime for a bad parameter in a function call being caught by the typehinting routine, I'm far more likely to be halted for using an undeclared variable. JavaScript can't notify me of these errors at JIT compilation because of the multiple scopes and nonlinear nature of closures. It doesn't know that by the time I call a function that it won't have that variable name somewhere within its scope. For all it knows, I'm going to stuff that property into the global scope. Hoisting and strict mode probably prevent bare insertion of a variable name into any intermediate scopes, but even strict mode accepts that I might change the properties of globalThis by the time the function is called.
If TypeScript solves THAT problem, then it's worth the trouble, and I'll work on integrating it into my code. The compiler would have to assume that nothing will be added to globalThis, and it would have to know in which environment I'll be running so it knows what to expect in that local globalThis. So I couldn't have a completely agnostic compiler to find this error, but the code I write largely IS agnostic and designed to work in Node, a standard browser environment, worker threads, WebExtension background and content scripts, Electron, and possibly other environments in the future such as Deno or Bun.
If the only benefit I'd get is diagnosing function calls a little sooner than the runtime check could, then I'd have to weigh it against the much more specific checks I can do at runtime via the Symbol.hasInstance method. It would only be useful in low-frequency late-called functions that take a wide range of inputs, such as any string or any number, instead of being able to require valid filenames or integers between 1 and 65535, for example.
When you need to learn about a new codebase you will be blessed if they use Typescript specially if is a big codebase
I think it's an overkill for most front end stuff but I would probably use a type safe language for most server side code but I would use a proper type safe language instead of some hacked together tool (Typescript).
Worked in new & legacy codebases at startups, Google and beyond that were 1) super strongly typed; 2) wannabe strongly typed; 3) not at all type safe.
What I see happen is folks get stuck in 2 and start hating the additional work when they feel they aren't seeing the added benefit.
My conclusion: The need for type safety increases proportionally with the complexity of the codebase and the # of devs interacting with it. Personal website? Fuck no I will not be using types. Large infrastructure that will be owned by my predecessor? Of course it needs types to make the code self explanatory.
it just adds another layer of dependency in my opinion.
yes it is!.. when u start u cant really go back. it prevent headache for you in the long run
If they are working API related stuff yes since typescript has good documentation and support for OpenAPI. Anything else it will be it depends and i priotrise on the team size as complexity as well.
It removed a lot of the need for unit testing. At first I hated it, but once I saw it showed me I needed to make changes in other files off one change, it loved it. There are still a few things I don't like about it(for example can't do object.hasOwnProperty(key)).
But overall I would rather use typescript. I generally follow a rule... if the same type or interface is defined by more than 1 file, I will put it in a types folder and import it. Otherwise I put the type and interface definitions at the bottom of the JavaScript file so I don't have to scroll through them while working on my code.
No. Would I use types if they were a native js feature? Yes.
I don't think that TypeScript is necessary for big projects, just compiling safety is not really a good thing, I just like TypeScript only for code suggestions and nothing else.
Im a new dev using ts now and Im wondering why tho? Am I jsut working on too simple projects or what? Can you tell me a case when you were like "Thank god this is in typescript!" ?
Yes. The answer is yes! A resounding yes! It is definitely necessary. It is almost a guarantee that you'll make a typo or access something that doesn't exist.
What I don't like about Typescript though is that you have to do some type gymnastics before you write anything meaningful but the payoff is well worth it
I wouldn't say its necessary, but its useful although it has issues. The issues aren't really related to Typescript and the langauge but more over to the libraries that attempt to support it, and yeah DefinitelyTyped helps, sometimes it doesn't cut it and you spend an hour adding a module to your defenitions of a project. Another problem I see is that not everyone uses the same backend and frontend environments and that means you spend a lot of time at the beginning making schemas/types... And if your prototyping things, it can be a nightmare!
My general rule is use JS to prototype (maybe ill use TSDoc in the future prototypes in JS), then use typescript for bigger and complex applications/codebases.
Strong typing is very nice for large and complicated projects
It's not just type safety. It also streamlines the JavaScript experience. Importing libraries and JSON files is a lot easier. I also like that I can do things like map all the built JavaScript to a sub directory, or even a single file. Finally, I like that the JavaScript it generates is more robust, and remains legible.
type safety is good. whats horrible i see is younger devs tends to create more layers bcoz they are making it behave like type language
I'd say yes, since I started using TS, coding in JS is not an option anymore. It's frustrating at first, but it's very much worth it.
I love typescript.
I am java developer and variable A is integer and you can assign the string to and will not give error at compile time and direct at runtime (which can be production) is just too bad for me.
I became Frontend developer because of TS and Angular because it's easy for Java developer
Couldn't you just make a VSCODE extension to typecheck javascript?
I'm a senior dev. Been programming for forty years now. The hardest thing I did was give up oop paradigms and embrace true functional programming. I consider TS a huge leap backwards. It cannot do runtime type checking. It's a joke. I really don't want to go back to the BS of interfaces, methods (the worse crime), dependancy injection. Yuck yuck yuck.
Am I too much a higher-order function snob?
Also I hate Microsoft with a passion. So probably bias here.
Yep, it takes time to of experience to understand stupidity of "modern" times. I literally have nothing to say... maybe this story: "A certain society believed that the reason humans could walk was because of a certain "stick" they had invented. Everyone in this society owned one of these sticks, and babies were presented with them shortly after birth. It was unthinkable and even heretical to question the importance and essential nature of these walking sticks.
One day, a rebel decided to demonstrate that humans could walk without the stick. But, given that he himself had never tried walking without the support of the stick, he fell down when he attempted to walk stick-free. Thus, the society concluded once again that it was the stick that allowed humans to walk."
It's super necessary
Type safety is great, For example now I like to program in Crystal more than Ruby (both for Crystal's static typing and its speed), I really like the ability to specify what type each variable is, That's crazy to build software projects without it, Maybe for scripting and "calculator languages" (Julia, Python, Octave) it is fine but not for general application development.
Yes
For personal projects? Nope. For big projects? Maybe! It seems to just add different problems to javascript lol
typescript is a blis. its nice to read and its so clean and you don't need to compile them to js.. ts can run by using ts-node so its so clean. ngl when I see angular js.. i hate how messy it looks like lol xD then they have ts I kinda love it like I'm in the era where angular 2 comes out long long time ago. .that's where I started to use typescript because of angular ts.
For me was the learning curve tbh it's a bit steeper there's a lot to learn on compilation options and stuff that's happening in the code, I followed their docs and lemme tell ya I had a good time with it loved how Microsoft is taking initiative on teaching and stuff but idk seems like didn't made my mind up yet on learning typescript or I'm taking a wrong approach
Honestly? It's a lot of boiler plate for simple typing, and something that had already been solved without TS before. But because all the "cool" programmers say it's the best thing since sliced bread, I guess I will too.
Don't like writing typescript, but like libraries that are written in typescript
Until you are fairly fluent with it it can be a battle!!!
I think strict typing becomes increasingly important the more the code base grows. It also helps with readability and intellisense in IDE’s. That’s part of the reason I’ve always preferred strictly typed languages.
I like that Angular uses Typescript by default. The only thing I don’t understand about Angular is why Observables are used by default when JavaScript already offers promises. It seems like reinventing the wheel and just adding extra features to the wheel. Or a better analogy would be forcing every manufacturer to put race tires on all of their cars. Most cars don’t need the amount of grip race tires give you. What observables offer seem to be unneeded in 90% of cases.
not necessary, but handy.
Is TypeScript necessary? I think the answer to that is "no" because there are plenty of projects out there that just use regular JavaScript. But it does have benefits and drawbacks.
It seems easy at first, until you encounter something in the type system that you have no idea why it's behaving a certain way. You find more and more of those instances, and you research them and find out why. And it's usually because you didn't understand the compiler and wrote bad code. So you rewrite it correctly and there you go. But this happens for awhile as you learn more nuance. So it can feel like you're fighting the language and compiler and it might be tempting to just go back to JS.
But if you stick with it, you'll learn how to properly take advantage of the compiler, and use type inference to pull off some really clever types to provide elegant APIs. And the result is not only convenient for the developer, you can insure that parts of your code are called in very specific ways, with specific data if you so desire.
If you like duck typing in JS, then you should really love TS. Because you can create types to represent any kind of duck that you want. Or a type that can represent one of a set of ducks. Or a duck and a cat. Or whatever. The point is, you are telling the compiler how your code works so that it can stop you from using it incorrectly. When used correctly, an entire category of bugs are simply impossible because the compiler will catch them.
why have type script if you have tests? Personally I think typescript is a pointless safety blanket for programmers who don't know how to handle chaos.
TS will prevent making chaos in the first place when used properly.
@@bartoszkrawczyk4976 No it doesn't. All i does is slow down productivity and actually can cause some of the most annoying bugs compared to vanilla.
@@darkquaesar2460 Then you're probably using wrong, sorry. As much as I don't like the guy, watch Theo Browne's video "You might be using typescript wrong" - then you'll understand. If you add every type again and again instead of letting TS infer as much as possible it will be annoying. If you let TS help you it will boost your productivity 10x. Few years ago I was telling the same, that TS is annoying and will slow you down, but working on large complex app (not personal side projects) where everything has good types changed my mind.
@@bartoszkrawczyk4976 it creates more text to read, it makes my brain fucked up when I want to build quickly things I still trying to figure it out why compiler does not like my console.log or sees 3 arguments in the function when there are literally 4. And you know what... at the end it is compiled to... javascript - insane!
I've only been programming for about 18 months, but it's obvious to me that TS lets you work faster and safer. I wouldn't take a job with a large vanilla JS codebase.
I can't think without types
when you speak your native language, do you use grammar to create sentences? Do you need to think to think?
Love typescript, may even be using it too much as a crutch...I actually gotta dive deeper into javascript and learn that inside out but its hard to go back
Ofc, YES!
if a better editor can check for error for me then it is less convincing to learn something more complicated.
I don't look at it as a headache I look at it as a very good tool that provides very useful intellisense and fils a bit The Gap that I'm missing from C sharp
I do find ts to be painful but most of the time I blame framework and library authors more than I blame ts. Most developers blame ts and I know it's not perfect. But framework and library authors should try to understand ts more and even the web so that types can be made in better ways
Typescript is dumb. Why people think it's bad to use the javascript type system directly, or they can't do it and need a preprocessor to do it I don't get. It's not like type errors are they only bug. For any kind of error it's your responsibility to understand what language feature exists rather than having something else do it for you.
I agree that there are still a ton of runtime bugs possible with typescript code. That said, I'm sure it catches a lot. Is it worth it? I'm not sure, sometimes crazy types give me a headache
@@realchrishawkes yeah, I dunno. I think javascript's type system is pretty well defined. Maybe people think types are a bigger deal because of typescript itself.
It gets in the way lol. Which isn't always a bad thing I guess but making Javascript strongly typed seems to defeat the purpose of javascript.
no i don't think it is necessary , if you want use go or rust
I don't use TS... it's another step I feel i don't need in my projects.
Web development is just so deep and complex now, that if I don’t feel like I need it, then I won’t learn it.
@@codybishop7526 Well, maybe then you should measure it. Measure how much bugs you get with vs without it.
If you are solo developer making small projects that last two weeks, then sure, you don't need it. For complex production apps you need it, you just don't know it yet.
Typescript is awesome but it's EXTREMELY slow. Of course, not the compiled stuff but the compiler is asinine and it's plugin support is meh.. it's really slow for web development when I have to wait for vue-tsc (plugin for typescript compiler) I don't mind it. I do like types, makes it easier to not click all the "view source" which I did often in JS.. however, I can't get over the slowness of the compiler